[U-Boot] u-boot gerrit server

[Vadim Bendebury (вб)]

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