From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luca Ellero Date: Fri, 15 Nov 2013 15:29:21 +0100 Subject: [U-Boot] u-boot gerrit server In-Reply-To: <52862BCB.2050504@schinagl.nl> References: <20131112192618.8B670380610@gemini.denx.de> <20131114195422.GB420@bill-the-cat> <20131114211759.GE420@bill-the-cat> <528627EC.7080008@gmail.com> <52862BCB.2050504@schinagl.nl> Message-ID: <52862FC1.10004@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 Il 15/11/2013 15:12, Oliver Schinagl ha scritto: > 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? OpenOCD > 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 >>> >>> >> > > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot