Next Release Planning

[Ryan Harper]

* Dave Neary <dneary at redhat.com> [2012-08-23 04:11]:
> Hi,
> 
> On 08/23/2012 10:59 AM, Yaniv Kaul wrote:
> >On 08/23/2012 09:05 AM, Livnat Peer wrote:
> >>+1, I suggest that instead of stabilizing what we have now, we'll send a
> >>release date and a feature freeze (FF) date to the dev lists, and see if
> >>there are any comments about the plan, maybe postponing FF by a week or
> >>so can give us more features etc.
> >>On the agreed FF date we'll create the 3.2 branch and ask all
> >>stabilization patches to be cherry picked to the 3.2 branch.
> >
> >I may be a bit biased because I'm from QE, but I do suggest a different
> >path - remain stable at all times.
> >The huge delay in releasing 3.1 due to quality issues supports this.
> >It means development may be a bit slower, but it'll pay off in release
> >time and quality.
> 
> The major issue I see with the current way of doing things is that
> it makes it harder for developers to test their work. You have 2
> active branches where work is getting done almost all the time, with
> the result that you need to keep 2 complete environments around to
> test both versions, it takes extra effort to be conscientious and
> back-port fixes from the devel branch to the pre-release branch,
> etc.
> 
> I suggested on IRC that features be developed entirely on branches
> until they're done and tested. That adds overhead to the developers
> too, and new features will still need some integration work when
> merged. But this would definitely get us closer to Yaniv's goal of
> an always-releasable branch.

I very much like the idea of working a feature out-of-mainline tree.  In
QEMU (and other git projects) a new feature is developed separately, and
the maintainer of the feature pulls in changes/fixes and rebases as
needed before submitting (or requesting a pull from the maintainer).  

Only features that are ready (passed some testing, review, etc) are
merged into the tree.

With gerrit in place, this still can happen, it just happens within the
main repository under branches.  It appears more difficult to me to use
the same git repo than separate where it's easy to point to a seperate
repo where the feature is being developed to test/review etc.

But, that's an implementation detail for the developers.

> 
> When it comes down to it, I think it's useful to have everyone
> working in the same place for as long as possible - I much prefer
> having everyone working towards getting a release out the door, or
> everyone working on new features, rather than having people split
> their attention between both, and as a result neither gets done as
> well as they could be.

Yes, I think it's much easier to focus the whole teams effort around the
current release/branch and getting it ready for the next release.



> 
> Cheers,
> Dave.
> 
> -- 
> Dave Neary
> Community Action and Impact
> Open Source and Standards, Red Hat
> Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
> 
> 
> _______________________________________________
> Board mailing list
> Board at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/board

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh at us.ibm.com