From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Thu, 14 Nov 2013 16:20:52 -0500 Subject: [U-Boot] u-boot gerrit server In-Reply-To: References: <20131114192754.GZ420@bill-the-cat> <20131114201750.GC420@bill-the-cat> <20131114205847.GD420@bill-the-cat> Message-ID: <20131114212052.GF420@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Thu, Nov 14, 2013 at 07:00:09PM -0200, Otavio Salvador wrote: > On Thu, Nov 14, 2013 at 6:58 PM, Tom Rini 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 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 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. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: