Re: [libvirt] Schedule for the next release suggestions
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? Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Schedule for the next release suggestions
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. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Schedule for the next release suggestions
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 veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Schedule for the next release suggestions
On Fri, Mar 22, 2013 at 02:07:05PM +, 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. We could try to freeze on the 29 to try to ship on the 5th April one month after the 1.0.3, Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Schedule for the next release suggestions
On Fri, Mar 22, 2013 at 10:17:07PM +0800, Daniel Veillard wrote: On Fri, Mar 22, 2013 at 02:07:05PM +, 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. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Schedule for the next release suggestions
On Fri, Mar 22, 2013 at 02:23:34PM +, 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 +, 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 -- Daniel Veillard | Open Source and Standards, Red Hat veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Schedule for the next release suggestions
On 22.03.2013 15:38, Daniel Veillard wrote: On Fri, Mar 22, 2013 at 02:23:34PM +, 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 +, 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 That effectively cuts a day for us, leaving us with only four days of freeze since on 1st April it's Easter Monday = public holiday in most countries (at least I've taken look at UK and Czech Republic). But I can live with that since the current status of the HEAD looks good. Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
