On Thu, Feb 20, 2014 at 11:29:43AM -0500, Chris Evich wrote: > On 02/19/2014 05:21 PM, Paolo Bonzini wrote: > > Il 19/02/2014 22:41, Chris Evich ha scritto: > > > The point of continuous integration is to have a good quality master > > branch at all times, and an integration branch like linux-next helps a > > lot for that. > > We found this not to be the case and maintaining next placed extra > burden on lmr. In order for CI to be meaningful to core and test > developers, we need to run large collection of tests that requires a lot > more time/resources that we have available. Those that would benefit > from knowing about some failure, would (on average) have to wait half of > "a long time" for results. In our case, half is still "a long time". > So it's more practical to just have master, and "do the best we can" > about keeping it mostly stable (we're human).
Let me try to summarize the discussion so far and what I have in mind as the ideal scenario: 1. master is where development happens. If a patch is declared READY by whatever process we have (see (2)), it should be merged there by a maintainer. Developers should use it, but end users should know there's a risk it may not be as stable as a release branch. The ultimate goal is to have a very stable master, without need for releases. 2. We should have some CI system in place to *automatically* run whatever tests and checks we can on all patches *proposed*. This should happen *before* a human reviews the patch. 2a. check-patch.py is a start, but it depends on both the submitter and the reviewer running it manually. 2b. github_checker.py is a good step in the right direction. 3. Reviewer/sub-maintainer should review and merge the patches that pass the checks from (2). Merging patches that skip or bypass it should be a rare exception. 4. There should be a bot (VM with autotest jobs) continuously running tests/checks on master. If something breaks, a maintainer should fix it ASAP, either by reverting the patch that broke it, or by committing a fix. > > > If you cannot achieve good quality for the master branch, to me this is > > a huge warning sign that you need more screening of what goes into > > master, before it gets there. > > I agree here too, and this is the reason for $SUBJECT and the work lmr > is doing on check_patch.py. Yes, it does place a lot of the burden onto > the reviewers. > That burden should be removed with automation. Patches horribly broken or that don't pass check_patch.py should be rejected automatically by 'the system'. Thanks. - Ademar > > It's a vicious circle, and the negative feedback can be pretty violent > > too. If master quality goes down too much, people will stop using it > > for development, and the quality of tagged releases will go down. > > No disagreement from me here either, we need to keep a real careful eye > on this, you're right. > > -- > Chris Evich, RHCA, RHCE, RHCDS, RHCSS > Quality Assurance Engineer > e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214 > > _______________________________________________ > Virt-test-devel mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/virt-test-devel -- Ademar de Souza Reis Jr. Red Hat ^[:wq! _______________________________________________ Virt-test-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/virt-test-devel
