[U-Boot] u-boot gerrit server

[Otavio Salvador]

On Thu, Nov 14, 2013 at 6:58 PM, Tom Rini <trini at ti.com> wrote:
> On Thu, Nov 14, 2013 at 06:30:00PM -0200, Otavio Salvador wrote:
>> On Thu, Nov 14, 2013 at 6:17 PM, Tom Rini <trini at ti.com> wrote:
>> > On Thu, Nov 14, 2013 at 06:06:49PM -0200, Otavio Salvador wrote:
>> >> On Thu, Nov 14, 2013 at 5:27 PM, Tom Rini <trini at ti.com> wrote:
>> >> > On Tue, Nov 12, 2013 at 03:14:13PM -0200, Otavio Salvador wrote:
>> >> > [snip]
>> >> >
>> >> >> What I think it'd be possible to get working would be:
>> >> >>
>> >> >> Custodians would have Submit rights
>> >> >> Custodians would have +2 review rights
>> >> >> "Normal" people would have +1 review rights
>> >> >> CI system could have the +1 for verified
>> >> >> Single tree
>> >> >>
>> >> >> So essentially custodians could be assigned using some keyword, file
>> >> >> matching and other clever heuristics, but it'd give freedom for them
>> >> >> to 'drop' their review need or add someone else. Once they submit a
>> >> >> change it goes straight to 'master' branch.
>> >> >>
>> >> >> This easy the merging of stuff but this ends with the sub-trees.
>> >> >
>> >> > This sounds like a first good step to me.  It's important that things
>> >> > get reviewed and everyone seems to be able to see the difference between
>> >> > "this is a small change to $subsystem driver for $soc, $soc custodian
>> >> > can just push it" and "this is a big change, $subsystem custodian should
>> >> > speak up too".  But I still want a final say on when things are able to
>> >> > be merged into master
>> >>
>> >> In this case, you could be the only one with 'submit' rights. So
>> >> everything would be just 'awaiting' for submit.
>> >
>> > And custodian should still be able to easily pull together a list of
>> > stuff they're happy with, change sets I guess?
>>
>> You can pull the 'patchsets' but the workflow I often see is that when
>> the changes are approved they go  to 'master' right away.
>>
>> The main drawback I see is that the 'custodian' gets the power to
>> merge stuff direct in master. At same time, we get a more 'complete'
>> master and this avoids subsystems being tested late in the release
>> cycle.
>>
>> I think it radically change the workflow but I've been using it for a
>> while in internal projects, customers and partners and it works quite
>> well.
>
> So long as we can plug a reasonable mount of CI in, this might not be
> too bad, honestly.  The big problems I find with custodian PRs are "oh,
> when I threw this through the everything-matrix, $board broke that you
> didn't try".

In fact I think every commit could be 'forced' to have the 'Verified'
vote set by the CI. So we couldn't push anything which fail.

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