The Emails: Overall I think they're too verbose. "Change in asterisk[master]: bridge.c: NULL app causes crash during attended transfer" might be better as "bridge.c: NULL app causes crash during attended transfer (asterisk[master])" It's not a lot shorter but it has the most valuable info at the front.
Also, the mail generated by "ReplacePatchSet" which gets sent on a rebase, doesn't tell you why you're getting the message but it does have the entire original commit message which doesn't really help. I'd remove the commit message and add the text of the last change. I.E. "Foo Bar: Patch Set 8: Patch Set 7 was rebased". That'll at least tell reviewers not to worry about it. Removing "(Code Review)" from the sender would be good as well. Cherry-picking: I think there are some issues we still need to figure out about the process and the system. Process first... While having all the reviews up at the same time is a good thing, I think we need to always start with the lowest branch the patch is expected to apply to and merge up towards master. I think the wiki says merge down for features and merge up for bugs. It should be up always. You don't want to start a feature in master only to discover that it can't go into 13 because some other feature is only in master. Same for review process. Start in the lowest branch and work up. This will hopefully minimize where different people are starting from different directions. It's hard to follow feedback and ensure you've got all the comments covered like that. Something I've noticed though is that dependencies get messed up when cherry-picking a series of dependent patches. Look at my patches 46, 47, 48 for master. If I cherry-pick 48 to my local repo, I get all 3 which is good because I can't test any without all 3. BUT now look at 43, 44, 45 for 13. When I check out 45, I get only 45 which is an issue. Maybe this is just an artifact of this being the first time with this scenario but it's something to look out for. Other things: There's a rebase button on reviews which need it but if you click it, you lose you're votes. :( We probably need a policy around rebasing reviews. I've noticed a couple of times where doing a 'git review' regenerated the Change ID and I can't figure out why. I've resorted to running 'git review -n' to see the commands and just running the 'git push' part. I'm still investigating. If you move between major releases you'll find various orphaned files and directories that are part of one release but not antother. Use 'git clean -fd' to clean them up. BEWARE: this will remove all files/directories that aren't part of the current branch or in the .gitignore files. If you have local scripts or other stuff you want to keep between checkouts, add them to .git/info/exclude. If you're a Google Apps/Gmail user use the filter "list:"gerrit.asterisk.org" to filter all messages regardless of repo. If you're switching between branches with the same major version a lot, install ccache! You're compiles will go a lot faster. When doing a 'git review' to update a review, you don't have to specify the topic branch again but you DO have to specify the target branch if it's not master. We could still use the links to the specific git/gerrit wiki pages on the gerrit menu. I think that's it for now.
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
