[U-Boot] u-boot gerrit server

[James Chargin <jimccrown@gmail.com>]

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 <trini@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@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
>
>

-- 
Jim Chargin
AJA Video Systems                       jimc at aja.com
(530) 271-3334                          http://www.aja.com