[U-Boot] u-boot gerrit server

[Otavio Salvador]

On Thu, Nov 14, 2013 at 7: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 think this is something one of 'known' developers will end doing and
applying it to Gerrit.

>> > 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?
>
>> >> >> 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.
>
>> >  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?
>
>> > [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.
>
> 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).
> But shifting to everyone must have notifiations and alerts or whatever
> setup to find out about new changes they might care about, will suck.

Agreed.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750