Dear Frank, did you encountered any Gerrit (or GerritHub) specific issues / bugs that created difficulties for you as release manager? Can we help / support you any way?
--- GerritForge Support http://www.gerritforge.com supp...@gerritforge.com Fax: +44 (0) 203 318-3620 UK: +44-(0) 208 144-9448 US: +1-(650) 741-1436 AU: +61-(0)280 911448 Skype: gerrit.support > On 24 Apr 2015, at 22:59, Frank Filz <ffilz...@mindspring.com> wrote: > > 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 ------------------------------------------------------------------------------ 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
