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 :)
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:
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.
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.
[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.
_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel
