[U-Boot] u-boot gerrit server

Fri Nov 15 15:12:27 CET 2013

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 <trini at ti.com> 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 <trini at ti.com> 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
>>
>>
>