* Livnat Peer <[email protected]> [2012-08-22 01:22]: > On 21/08/12 22:00, Ryan Harper wrote: > > * Livnat Peer <[email protected]> [2012-08-21 13:23]: > >> On 21/08/12 17:01, Ryan Harper wrote: > >>> * Dave Neary <[email protected]> [2012-08-21 08:42]: > >>>>> I am not sure we must have new features in each release, a release of > >>>>> bug fixes seems also reasonable to me. Why not keep it only time-based > >>>>> release regardless of commitments for new features for the release. > >>>> > >>>> I like giving people good reasons to upgrade, but also good reasons > >>>> to install the current version - and in terms of communication, if > >>>> we say that 3.2 will be "3.1, with lots of bug fixes", and that it > >>>> will be along in 3 months, why would anyone install 3.1? We've just > >>>> said it's a buggy release that will soon be obsoleted anyway. > >>>> > >>>> IMHO, it's better to say "here's what 3.1 does well, here's what 3.2 > >>>> will be able to do that 3.1 doesn't". I'm not suggesting a > >>>> revolution with every release, but one thing which is identifiable > >>>> as "new in 3.2" doesn't seem like a lot to ask. > >>> > >>> Definitely agree with this approach. We always want something new for > >>> the next release. > >> > >> I agree we want something new, the question is what is the release > >> criteria. > >> If I understand the above suggestion correctly If there are not enough > >> new features we won't release in 3 months? > >> I think this is a mistake because there are hundreds of bug fixes pushed > >> into the repository and releasing a more stable version IMO has great > >> value. > > > > This is what a stable release stream is for. QEMU maintains a stable > > release until the next version is available. We could produce a 3.1.1 > > release and keep that going until 3.2 comes out. > > > > And if we don't have new features in 3 months, then it's probably too > > short of a release cycle. The last thing we want to do is introduce > > *more* churn into engine deployments. If we have a stable release, this > > would make a longer cycle, like 6 months, more reasonable. > > > > I'm perfectly fine with releasing in November a 3.1.1 as a stable > release. As long as we don't postpone releasing 'something' further than > November.
Certainly, we're still discussing what a stable branch/release for oVirt means; I don't think this discussion should hold up reasonable plans. > > The only issue that comes to mind when we start discussing z-stream is > the churn we'll have (as developers): > > - We'll need to cherry pick instead of rebasing, which means sending > patches twice, testing it twice, rewriting parts if needed etc. It would > have been ok if we didn't have to cherry pick a few dozens patches in > networking alone. > > - We'll need to take care of upgrades more carefully, which always makes > our work more interesting but also more complicated (do we require > upgrading to 3.1.z before upgrading to 3.2? testing the upgrade process > etc.) This may be part of our stable patch requirements. It should be bug fixes only and shouldn't introduce anything that would require updating before upgrading; though one can imagine a case where upgrading fails without one of the stable fixes. > > I think that going forward we'll do better if we can create the next > z-stream branch as soon as we release so we can cherry pick as we go, > now we have a gap of about 8 weeks (? - not sure actually) since last > rebase, that's a lot of work. Yeah, normally the stable branch is opened as soon as the release goes out, and patches that affect the current release are pushed into the stable branch. > > I suggest that the release in November will still be 3.2 and hopefully > we can get enough features to make it attractive, and then we'll create > the z-stream branch, so we can release 3.2.z as needed (instead of doing > 3.3 with not enough meaningful content). > -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx [email protected] _______________________________________________ Board mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/board
