On Thu, Nov 14, 2013 at 07:00:09PM -0200, Otavio Salvador wrote:
On Thu, Nov 14, 2013 at 6:58 PM, Tom Rini trini@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@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@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.
True. But can we also setup levels of CI? Make everything pass the 1 ARM 1 PowerPC, 1 MIPS, x86, sandbox build-test, optionally make others (the merge request equivalents) have to build all ARM, all PowerPC, all MIPS, etc, etc.