Next Release Planning

[Ryan Harper]

* Livnat Peer <lpeer at redhat.com> [2012-08-22 01:22]:
> On 21/08/12 22:00, Ryan Harper wrote:
> > * Livnat Peer <lpeer at redhat.com> [2012-08-21 13:23]:
> >> On 21/08/12 17:01, Ryan Harper wrote:
> >>> * Dave Neary <dneary at redhat.com> [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
ryanh at us.ibm.com