> Dear Matt, > please see below some additional background on Gerrit that you might find > useful. > > > On 28 Apr 2015, at 16:09, Matt W. Benjamin <m...@cohortfs.com> wrote: > > > > Hi, > > > > As I mentioned in an IRC discussion, my recollection from when OpenAFS > > implemented gerrit (also their own installation, but not to my > > knowledge customized), it was basically mandated that developers > > submit "one patch per change." > > > >> From what I can tell, Frank finds problematic > > > > 1) a lack in gerrit of a "changeset" concept, plus, apparently > > It actually exists and is called “topic”. It will be very soon possible as > well to > merge a whole topic atomically with one click.
Looking at this, this may well be our solution. I have some questions: 1. Will it let you one click merge with the "cherry pick" merge style? If so, that will be awesome, one click and I get all the review and verify signoffs into the commit messages. 2. In a subsequent e-mail, I think you were offering us a staging version of gerrithub? If so, is the topic stuff stable enough that we could play with it? In the meantime, I see enough potential here, and I see that gerrithub review process has enough positives to it that I feel like we can use it for review, and I can do merges by pulling patch sets from gerrithub (apparently git-review can do this, or it's not too hard to do with the "download" options from gerrithub). Frank > > 2) some missing automation to propagate review information into > > git's history/commit msg > > It is actually in beta and will be released very soon: it is called “NoteDB”. > It is > basically the archive of all review history (including ratings and comments) > as > Git objects. > > > > > I think both are potentially legitimate considerations, with a claim > > to be related to best practices (so potentially on a par with the > > motivations to update the review process). > > > > In large corporate development environments I've worked in, the > > aspiration to get the 20% lacking in the off-the-shelf tool would be > > solved by some internal development. In other cases, someone said, > > "no discussion, we're using VSS." > > > > I don't have a very strong opinion, but I do somewhat feel that > > however much gerrit helps with some review beset practices, just doing > > what gerrithub appears to support oob probably brings arbitrary > > processes, not just best practices. > > > > At the same time, I think the objection to "one patch per change" > > (which appears to be, "this well-formed, logical change which touches > > many files is too big for me t review") may be overblown. > > > > If we could do one patch per-change, objection #1 might be overcome. > > To overcome objection #2 seems to require some minimal tooling--I'm > > unclear whether it is compatible with gerrithub; If for some reason > > not, is there an organization volunteering to host and > > maintain/co-maintain aprivate gerrit installation? > > > > Matt > > > > ----- "DENIEL Philippe" <philippe.den...@cea.fr> wrote: > > > >> Hi Frank, > >> > >> reply is in the message body. I cut some pieces of your original > >> message to avoid a too long message where information would be > >> diluted. > >> > >> On 04/24/15 23:59, Frank Filz wrote: > >>> 1. Abandon gerrithub, revert to using github branches for review and > >> merge. > >>> This has a few problems. > >> The issue with github-based reviews are known. Avoiding solving a > >> current issue by stepping back to formerly known problems may seem > >> comfortable, but this is no evolution, it's clearly a regression. > >> > >>> 2a. One solution here is use an e-mail review system (like the > >> kernel > >>> process). > >> This is prehistory... Kernel community works like this because they > >> have this habit since the (Linux) world was new and nothing else > >> existed. > >> Can > >> someone seriously say it would be user-friendly ? OK, mail are > >> archived, but not indexed. Looking for a review will be like > >> lookingfora needle > >> > >> ina haystack. Once hundreds of mail will have been sent and received > >> and re-re-re-re-replied finding useful information will become > >> impossible. > >> > >> Please don't bring us back to Stone Age. > >> > >>> 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. > >> It seems like a much better idea. People in my team are developing in > >> > >> the Lustre code. The Lustre community works with a private gerrit > >> since the beginning. They have their best practices and their > >> workflow. > >> In particular, they have "Patch windows" : when the window is opened, > >> > >> people can submit patchsets. As it closed, people review it, fix > >> stuff, rebase code, and the branch is released. No new patchset comes > >> at this > >> > >> time. Then the window opens again and a new cycle starts. One > >> important point : the "master repo" is the git inside gerrit and no > >> other. This > >> > >> means that contributors would only fetch gerrithub to rebase their > >> work, github will then become a simple mirror. > >> Clearly, the "merge/fix/rebase" process is longer than a week. We > >> could work this way by simply abandon the one-week cycle we are > >> accustomed to. > >> It's just a matter of using new, more adapted, rules and best > >> practises. > >> > >>> 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. > >> Again, I believe that the one-week cycle is the real issue and it's > >> such a constraint for release management. You should open/close the > >> submission window at your will. It would ease your work a lot, > >> wouldn't it ? Remember that gerrit was designed to help the release > >> manager, it's not designed to be that painful. We may just use the > >> tool the wrong way. > >> > >>> 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. > >> People can rebase their patchset, even when submitted to gerrit and I > >> > >> think they should keep the same changeid. Remember that changeid is > >> nothing but a mark on a commit to allow gerrit to keep patchset > >> history. > >> It's not a commit id. > >> > >>> > >>> If we proceed with gerrit, Malahal and Vincent will need to > >> re-submit their > >>> patches with new changeids > >> From my point of view, changing the changeids would clearly be a > >> misuse of gerrit. > >> > >>> 1. We need more participation in review and verification on a timely > >> basis. > >> Yes. But the timeline can be refine. > >> > >>> 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). > >> Gerrit can trigger automated tests (as it does with checkpatch.pl). > >> Github does not (and so do not emails....) > >> > >> > >>> 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. > >> Yes. > >> > >>> 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. > >> The question of timeline comes back again. That's clearly part of the > >> issue. > >> > >> I am, and I always was, a partisan for using gerrit. I will go and > >> talk with my Lustre developers and will be back with a summary of the > >> workflow use for Lustre with their private gerrit. This may be bring > >> a > >> > >> new set of information to the current discussion. > >> > >> Regards > >> > >> Philippe > >> > >> --------------------------------------------------------------------- > >> --------- 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 > > > > -- > > Matt Benjamin > > CohortFS, LLC. > > 315 West Huron Street, Suite 140A > > Ann Arbor, Michigan 48103 > > > > http://cohortfs.com > > > > tel. 734-761-4689 > > fax. 734-769-8938 > > cel. 734-216-5309 > > > > ---------------------------------------------------------------------- > > -------- 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 > > > Should you have any further questions, please do not hesitate to come back > us. > > Kind Regards. > --- > 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 > > > ------------------------------------------------------------------------------ > 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
