From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oliver Schinagl Date: Fri, 15 Nov 2013 15:12:27 +0100 Subject: [U-Boot] u-boot gerrit server In-Reply-To: <528627EC.7080008@gmail.com> References: <20131112192618.8B670380610@gemini.denx.de> <20131114195422.GB420@bill-the-cat> <20131114211759.GE420@bill-the-cat> <528627EC.7080008@gmail.com> Message-ID: <52862BCB.2050504@schinagl.nl> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 15-11-13 14:55, James Chargin wrote: > 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? Coreboot? oliver > > 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 >> >> >