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

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,

On Fri, Mar 22, 2013 at 02:07:05PM +0000, Daniel P. Berrange wrote: > On Fri, Mar 22, 2013 at 09:36:03PM +0800, 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, > > I would prefer it if we just stuck to a release on/near April 1st > regardless of how many changes have accumulated. IMHO a predictable > release date once a month on/near 1st of the month is more important > than the amount of code that has been changed. to release on the 1st we would have to freeze this Monday meaning only 2.5 weeks of development after a freeze for 1.3 which took 1.5 weeks. I was considering the ratio of freeze time vs. open time too.

On Fri, Mar 22, 2013 at 02:23:34PM +0000, Daniel P. Berrange wrote: > On Fri, Mar 22, 2013 at 10:17:07PM +0800, Daniel Veillard wrote: >> On Fri, Mar 22, 2013 at 02:07:05PM +0000, Daniel P. Berrange wrote: >>> On Fri, Mar 22, 2013 at 09:36:03PM +0800, 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, >>> >>> I would prefer it if we just stuck to a release on/near April 1st >>> regardless of how many changes have accumulated. IMHO a predictable >>> release date once a month on/near 1st of the month is more important >>> than the amount of code that has been changed. >> >> to release on the 1st we would have to freeze this Monday meaning >> only 2.5 weeks of development after a freeze for 1.3 which took 1.5 >> weeks. I was considering the ratio of freeze time vs. open time too. > > I don't really think that's a problem myself, it is just to be > expected due to the longer than usual 1.3 freeze. People have > had just as much time to /write/ their code, all that changed > was the time available to /merge/ their code into upstream. > > I'd like to see is be much stricter about following a monthly > release schedule in general. It makes it easier for distro > maintainers to accurately plan ahead for when libvirt releases > will sync up with their schedules, if they can reliably know > that we'll always release on the nearest weekday that follows > the 1st of the month. So that mean freezing on monday, I can do that ! Daniel