From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Chargin Date: Fri, 15 Nov 2013 05:55:56 -0800 Subject: [U-Boot] u-boot gerrit server In-Reply-To: References: <20131112192618.8B670380610@gemini.denx.de> <20131114195422.GB420@bill-the-cat> <20131114211759.GE420@bill-the-cat> Message-ID: <528627EC.7080008@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Is there an existing mailing list for some other open source project that uses a gerrit server in something like what would be a model for the way U-Boot would use it? It might be instructive to watch that list to see how the interaction with the developers goes. Thanks, Jim On 11/14/2013 03:43 PM, Vadim Bendebury (??) wrote: > On Thu, Nov 14, 2013 at 1:17 PM, Tom Rini wrote: >> On Thu, Nov 14, 2013 at 12:59:05PM -0800, Vadim Bendebury (????) wrote: >>> On Thu, Nov 14, 2013 at 11:54 AM, Tom Rini wrote: >>>> On Tue, Nov 12, 2013 at 11:46:35AM -0800, Vadim Bendebury (????) wrote: >>>> >>>>> Hello Wolfgang, >>>> [snip] >>>>>> Can you not pick up the patches directly from the mailing list? I >>>>>> mean, we know of the problems patchwork has (like silently dropping >>>>>> certain base64 / utf8 encoded messages), so we should rather try and >>>>>> get a more reliable feed for the patches? >>>>>> >>>>> >>>>> this is the thing: picking up patches from patchwork is not something >>>>> you'd do regularly - this is just my way of populating the review site >>>>> from a single test account. >>>>> >>>>> If this workflow were adopted, each user would push their patch to the >>>>> gerrit server, creating a new review branch for that particular patch. >>>>> In general, gerrit view of the branch matches the submitter's view of >>>>> the branch - if the submitter has several patches in one branch, they >>>>> will all be uploaded by gerrit to the same separate branch, >>>>> maintaining the relationship between the patches. >>>> >>>> This is my biggest concern. On the one-off to infrequent contribution >>>> side (and we do have some of that), I worry about the infrastucture >>>> hurdle here. >>>> >>> >>> Sorry, I am not sure i understand what the biggest concern is: that >>> the users would push their own patches? Why is this a problem - the >>> patches would go into their own branches until reviewed and merged. Or >>> did you mean something else? >> >> I mean, it's a higher hurdle to clear. Looking at other non-Android >> projects, I know some folks have said "bah, not worth the effort" to >> push trivial things, if it must come via gerrit. So some way to scrape >> the ML for things that don't come in via gerrit to start with would be >> handy. >> > > I guess if the submitters are still expected to do both, ML and > gerrit, then yes, but the idea is that gerrit is the way to go, > mailing list is whatever gerrit generates. This way sending an email > to the mailing list or running 'git push' require pretty much similar > efforts > > and BTW, I should have mentioned this earlier, there is a linux > command line based utility to manipulate patch states on the gerrit > server, I put its help output here: http://pastie.org/8481244 > > >>>> On the other side, what is the gerrit equivalent of 'git send-email >>>> --compose ...', and I'm focusing on the compose side here. Or is it >>>> just another mental switch the project makes, from that to push to >>>> gerrit / compose email saying "hey, look at this" >>>> >>> >>> This is how we usually do this: >>> >>> - upload all patches to gerrit >>> - go to the web interface of the first patch in the series (by this >>> time gerrit would have a stack of patches showing their dependencies), >>> click on "review" - at this point gerrit would open a form to type the >>> cover message in >>> - once you finish composing the message you click on "publish >>> comments" and it gets sent to everybody who was picked as the >>> reviewer, and to default addresses, if any are configured (which of >>> course could be u-boot at lists.denx.de, for instance) >> >> Right, and at that point we've mixed discussion of a concept with >> discussion of a particular change, and we're in web-only for writes. I >> guess (pending see below) one could just write the 0/N email separate, >> or in-reply-to 1/N, so that the concept discussion stays on the list and >> in the archives and so on. >> >>> Once thing I have to mention: gerrit is notorious for sending tons of >>> email, while this is being worked on, in the meantime some more >>> rigorous email filtering might be very useful. >> >> Just how hard is it likely to be to filter things so that only: >> 1) new patches >> 2) reviews >> get sent to the ML? >> > > It is not hard, it's just a pain that it has to be done by every > recipient (as opposed to cutting the emails on the server). We are > working with gerrit community on that, but it goes quite slow. > >>>>>>> Any one can upload patches to this server after creating an account on >>>>>>> it. Any Google account will do, or if you don't want to have a Google >>>>>>> based email you can create the account using your existing email. >>>>>>> Follow the prompts after clicking on 'Sign in' link on the top right. >>>>>> >>>>>> Is my understanding correct that I have to use or create a google >>>>>> account in any case to participate in this type of work? What if I am >>>>>> not willing to accept Google's Terms of Service, or to register an >>>>>> account with google for other reasons? >>>>>> >>>>> >>>>> This is correct, if you decide to use the google infrastructure based >>>>> server. But you don't have to, gerrit is a stand alone application >>>>> which can be easily installed on the same server or on a different >>>>> server in the same location where the master u-boot git server is, >>>>> with you (denx.de) having full control over it. >>>>> >>>>> Google hosting has advantages of providing extremely high bandwidth >>>>> and reliability, but google's version of gerrit (distributed and >>>>> replicated) is not a requirement, as i said, gerrit could be hosted on >>>>> a linux machine. >>>> >>>> Well, how much help and tweaking can we get, if we go with Google >>>> hosting? My views are perhaps biased based on using gerrit earlier in >>>> Android's life, but, I can't imagine us having the time to deal with >>>> admining and upgrading a server later on. >>> >>> Well, if you use google hosteg gerrit, you won't have a problem with >>> upgrading or managing the server. Some one would need to get admin >>> rights and set it up properly (create branches per custodian, set up >>> user groups and group permissions, etc.). I am not going to be able to >>> do this, but I sure could help pushing issues through the >>> Gerrit-On-Google folks, they are pretty accommodating and responsive. >> >> Right, I'm saying the Google doing back-end management is a plus to >> using Gerrit, and possibly a requirement of us using gerrit. >> Self-hosted seems likely to be resource intensive. >> > > Agreed. But using google services would involve creating google > accounts (even when using existing email addresses). > >>>> And of course, given ${insert >>>> ones favorite now defunct google service} what might happen down the >>>> line if the Google hosting goes away? >>> >>> This is a very valid concern and there is no guarantees. But if push >>> comes to shove, gerrit is an open source product and it can be >>> installed on a stand alone server (which of course would be a pain). >> >> And can data be extracted? >> > > The merged patches are in their appropriate branches, presumably there > is a master git server somewhere which periodically syncs up with > gerrit server, and it is the trusted source. > > The emails with comments would have been emailed at review time, lost > would be patches in flight and abandoned or modified patches from > earlier reviews, is this acceptable. > >>>> [snip] >>>>>>> This server is not configured yet, but in general gerrit allows for >>>>>>> three levels of reviewers - those who can just comment, those who can >>>>>>> assign a +1 rating to the change (an equivalent of an acked by) and >>>>>>> those who can assign a +2 rating or push the change (the custodians). >>>>>>> There is no point in setting these up on a mirror, but if so desired, >>>>>>> it could be done. >>>>>> >>>>>> How can we arrange to keep the mailing list in sync? >>>>>> >>>>> >>>>> This is a big question for which there is no good answer. Gerrit will >>>>> send submitted patches in emails (limited to a configurable max patch >>>>> size), but it will not accept email based reviews. So, this would >>>>> involve a change in the way things done, I am just suggesting this as >>>>> an alternative for consideration. >>>> >>>> Can we at least get all reviews sent to the ML? >>> >>> The problem with this is that when reviews are sent to the mailing >>> list, they are for different custodians, trees, etc. It looks like >>> appx. half of them applies cleanly to the master branch, the rest do >>> not. Is there a way to tell what branch the patch is detined to by >>> looking at the email? >>> >>> A much more robust approach is to have users push patches directly, >>> and set up branches/projects on the server, as required. >> >> Right. But the biggest concern with this approach is that you limit >> reviews to everyone who knows to be interested in $foo, rather than >> everyone who is subscribed seeing (a hopefully useful subject in the) >> patch that changes $foo, and deciding to take a peek. This is why it's >> vital to have some way to keep the ML apprised of when new patches come >> in. >> > > But the gerrit server will be sending all patches out, one of the > destinations would be the group mailing list - is this not good > enough? > >> Pushing patches won't be hard to adapt to. Doing the reviews on a web >> page might noe be too hard to adapt to (I don't like that "all unified" >> spits out N tabs, rather than a single page with all unified diffs, but >> I adapted to reading one source file changes at a time pretty quick). > > What I usually do when I need to review a chain of related patches on > gerrit is go to the top patch in the chain, and then clock on the > 'pull' tab in the download box. This generates a command line which, > if run locally, would bring the entire chain of patches to your git > repository. Than one can examine all patches together locally and > comment on gerrit. > > >> But shifting to everyone must have notifiations and alerts or whatever >> setup to find out about new changes they might care about, will suck. >> > > again, the notifications with patch descriptions and diffs (to a > certain extent) would be sent to the list, this should be enough, > right? > > --vb > >> -- >> Tom > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > > -- Jim Chargin AJA Video Systems jimc at aja.com (530) 271-3334 http://www.aja.com