On Fri, Mar 22, 2013 at 02:50:22PM +0100, Michal Privoznik wrote:
> On 22.03.2013 14:36, Daniel Veillard wrote:
> > The 1.0.3 release was on the 5th March, and right now we have
> > accumulated 'only' 150 commits since the release. Based on this I
> > would suggest to wait a couple of weeks before to enter a freeze
> > for the following release. This mean we drift from the usual end
> > of month, but the ratio of freeze/devel will remain more or less
> > constant as well as the expected size of change in the new release.
> > So if this is fine I would suggest to enter freeze for 1.0.4
> > on the 5th of April for a release around the 12. Unless there is
> > a reason to push a release earlier,
> >
> > Opinions ?
> >
> > Daniel
> >
>
> Given how hard & long we had tried to make the most recent release
> stable should we prolong the freeze? Or is it something what can be
> decided operatively once we see how much is upstream broken?
In general the 5 days is the 'expected freeze duration assuming
the shape is correct' so if we hit something nasty we continue the
freeze until problems are fixed. That's actually what happened end
of February. Let's say the 5 days is the optimistic version :-)
There had been suggestion in the past to branch in git at the freeze
time to not penalize continued development, and pull the fixes only
in the stable branch for the release. This sounds nice in theory, but
this has 2 drawbacks:
- a small one which is that the release is no more available on
the git master branch
- a fairly large one which is that if people keep their focuse on
upstream who will spend the time to do the necessary cleanups,
and the few who will do will be alone, and it will take more time
for them and it is not fun to just do cleanups
IMHO cleanup for release really ought to be a wide community effort
and that's why I'm still on the side of freezing in master git branch
(and anybody can use a local branch to work on their stuff, but
community forcus is the freeze at that time).
Daniel
--
Daniel Veillard | Open Source and Standards, Red Hat
veillard@xxxxxxxxxx | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list