[U-Boot] u-boot gerrit server

[Luca Ellero]

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 <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
>>>
>>>
>>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot