On Thu, Feb 27, 2014 at 01:35:43AM -0300, Lucas Meneghel Rodrigues wrote: > On 02/19/2014 07:21 PM, Paolo Bonzini wrote: > >Il 19/02/2014 22:41, Chris Evich ha scritto: > >>On 02/19/2014 07:02 AM, Paolo Bonzini wrote: > >>>Il 19/02/2014 09:17, Lukáš Doktor ha scritto: > >>>>Well no script can guarantee that. > >>> > >>>No, but it can lay the grounds for continuous integration. > >> > >>To re-emphacize what Lukáš said, we've replaced 'next' with master and > >>(mostly) weekly (or bi-weekly) tagged-versions. The concept of a > >>'stable' HEAD master is almost completely gone (though we try). > > > >Which isn't a good thing, especially since you don't have > >stabilization/freeze periods (apart from exceptional cases like the TP > >repository split). > > > >In particular it makes automated bisection much much harder. > > Sorry for resuscitating this thread, but I agree with Paolo. I was > defeated in all arguments about having a integration branch (that I > used to call 'next'), and people told me that 'next' was not the > standard for open source projects, etc, etc. At least now I have > someone that agrees with me :)
I think we're talking about different concepts here. I was probably the most vocal against the old next concept, but that's because it was basically a development branch with a lot of push -f on it. master received a series of commits only on release-day after the next branch was declared stable. I don't regret the change we made to a standard master branch at all. > > Without a integration branch and testing, so we can weed out obvious > problems, it is hard to keep bisectability of the stable branch. I > must say I liked the old master/next schema a lot better than having > a wild west master branch and having to do reverts of mistakes on > that stable branch. Based in the comments so far, a good system > would look like the following: Having a standard master branch doesn't mean we don't need a CI system to check which patches are good or bad to be integrated, they're different concepts. The master branch should never ever be considered a "wild west" branch. > > Projects have integration branch [1], generated by some github hook > that runs syntax and style checkers, and if these very basic tests > don't pass, the PR is not good for merge. A possible place to put > those tests would be > > https://travis-ci.org/ > > Every night we'd have integration to have merged all the PRs that > did pass first travis CI. Some additional functional tests would > then be made in the internal CI grid, since I *believe* we can't do > the whole thing in travis. So far so good, this is basically the same as what I've proposed in the other e-mail. > > Master would only be updated when a given state of the branch is > approved in all instances. We should be allowed to simply yank > commits that were found to break the test suite. Not sure I get what you mean. I don't think master and 'next' (or 'integration') have to be in sync. If what you want is to stabilize the next branch before you even touch the master branch, you're again moving the development to the next branch, which I particularly don't like (but hey, I'm not a developer, I'm just trying to contribute with the experience from my past life as a release manager, integrator and developer). > > [1] Possibly named 'integration'. I like 'next' obviously, but the > former is probably more clear as to what the branch is about. > > >>Stability is the goal of the tagged releases, and it doesn't make a lot > >>of sense to run big CI test jobs on the (often broken in some way) HEAD > >>master. As long as we stick to rapid, regular tagged releases, this > >>should be mostly "ok" for test development* > > > >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. > > > >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. > > > >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. > > I could not agree more. Thank you. > I believe we're all in sync here with the goals. What we're not in sync is how to implement it in practice (and I don't see anything in the message from Paolo that makes me believe he wants the old next concept back). Thanks. - Ademar -- Ademar de Souza Reis Jr. Red Hat ^[:wq! _______________________________________________ Virt-test-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/virt-test-devel
