So I tried to merge using gerrithub today. The procedure I had intended to follow will not be sustainable as just an extension of the workflow we have used in the past.
As a result of this, I did some merges with gerrithub, and then have force-updated the branch to revert it to V2.3-dev-0 (Sorry Bill, I really didn't want to have to do that after just messing you up...). There will not be a V2.3-dev-1 this week. At this point, I see a variety of options for proceeding: 0. Suck it up. Release manager may go insane the first time he has to merge a submission with 20 or 30 or more patches. 1. Abandon gerrithub, revert to using github branches for review and merge. This has a few problems. The biggest is that review history is hard to find when a patch is updated for any reason. Other problems in the past were folks using github pull requests (which are trickier to find the right thing to pull into my local git repo) and posting just the patch SHA1, leaving me to have to scrounge through their branches to find the branch that has the patch(es). Also, folks don't tend to clean up their old branches so pulling in someone's remote can pull down a huge number of branches (which can mostly be ignored - except when they use a new branch when they update the patch). 2. Abandon gerrithub, but find some other way to do code review where we don't lose accessibility to review comments when folks update their patches. 2a. One solution here is use an e-mail review system (like the kernel process). This could be e-mail exclusively (I would then have to set up e-mail on my Linux VM in order to be able to merge patches via e-mail). I'm not fond of this process, but it would be workable. 3. Change our workflow to work with gerrithub better (stop using the incremental patch process). One loss here would be the ability to bisect and hone in on a small set of changes that caused a bug. 3a. The most extreme option would be to abandon incremental patches. If you have a body of work for submission in a given week, you submit one patch for that work. This is not appealing from a code review standpoint. It might not be so bad as in the past since we hopefully won't have major style re-writes that make it impossible to review changes when combined with functional changes, we still do see some interface changes that require many trivial changes. When these are combined in the same patch as a significant functional change, it can still be hard to find the functional change and properly review it. 3b. A less extreme possibility would be to encourage folks to package submissions tighter. Keep style changes to a separate patch. Keep those massive interface modifications to a separate path. Combine ALL the functionality of a new patch into one patch (or if it really is too big, maybe two or three patches). Make sure the patch titles make it clear what sequence they should be applied (like "Stage interface changes for Feature A", "Implement Feature A", "Enhance debugability and documentation for Feature A"). 3c. A process implied by a post Matt found: Perform code review with incremental patches. Once submission is ready, squash the submission into a single patch and get final signoffs on that. Then the single patch is merged. If we proceed with gerrit, Malahal and Vincent will need to re-submit their patches with new changeids (Vincent technically need only introduce new changeids for the two patches I merged). Sorry - there is no way I can re-open those changeids. Some additional thoughts no matter what we do: 1. We need more participation in review and verification on a timely basis. 2. We should make sure each patch that has significant impact in areas the author may not be able to test is verified by someone who is able to test that area, and then make sure we document that verification in the review history (here is where gerrit COULD shine). 3. It would be helpful to be able to identify one or two critical reviewers for each patch, and then make sure those people are able to review the patch. For those patches that may need more than a couple people to review, we need to stage them at least a week ahead of when we expect them to be merged, and then somehow flag those patches as high priority for all required reviewers to actually review. Thanks Frank ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
