[libvirt] Back and suggested release schedule
Hello all, as some of you may have noticed, I'm back online, just in a very different timezone now ! I'm still behind on reading the list emails but a lot of the changes in the last month have been refactoring and cleanups, and maybe we ought to make a new release at the end of the month to try to catch possible regressions introduced as early as possible. What do people think of a new release for the new year, which would mean entering freeze over the week-end. My own testing will probably be limited as most of my machines are in boxes in a container somewhere, but I should be able to make a release :-) Also on the release name, should we go 0.9.0 considering the refactorings (i.e. indicating future patches will be harder to apply to earlier branches) or stick to 0.8.7 (considering that there isn't major feature improvement ... unless I missed them !), Opinions ? Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 22/12/2010, at 10:30 PM, Daniel Veillard wrote:
Also on the release name, should we go 0.9.0 considering the refactorings (i.e. indicating future patches will be harder to apply to earlier branches) or stick to 0.8.7 (considering that there isn't major feature improvement ... unless I missed them !),
My initial thinking is 0.8.7, but I don't feel strongly about it. :) With the "freeze", what's a good process to put in place while frozen to make sure only bugs and doc improvements go in? There has been tentative discussion on list about possibly doing some kind of branching and/or "candidate" tarball, but we didn't get reach a solid conclusion. ?
On Wed, Dec 22, 2010 at 11:31:14PM +1100, Justin Clift wrote:
On 22/12/2010, at 10:30 PM, Daniel Veillard wrote:
Also on the release name, should we go 0.9.0 considering the refactorings (i.e. indicating future patches will be harder to apply to earlier branches) or stick to 0.8.7 (considering that there isn't major feature improvement ... unless I missed them !),
My initial thinking is 0.8.7, but I don't feel strongly about it. :)
With the "freeze", what's a good process to put in place while frozen to make sure only bugs and doc improvements go in?
Well that should be part of the review process and people who have commit rights are supposed to know the rules ;-)
There has been tentative discussion on list about possibly doing some kind of branching and/or "candidate" tarball, but we didn't get reach a solid conclusion.
Well ... there are tarballs [1] generated every hours on libvirt.org out of git. The unfortunate point is that few people test git on the strange configurations which generally break things, and those get caught *after* release precisely because the code end up reaching a larger audience. So I'm not sure that making a candidate tarball helps that much, just fetch the git tarball sometime during the freeze, the adantage is that as we go alog the freeze week, more bugs should get fixed. Also we often introduce bugs in the process of trying to chase another one, and the candidate/final split doesn't catch that ... unless you do more candidate release (and one per hour is the extreme case :-) Daniel [1] ftp://libvirt.org/libvirt/libvirt-git-snapshot.tar.gz -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 23/12/2010, at 12:11 AM, Daniel Veillard wrote:
On Wed, Dec 22, 2010 at 11:31:14PM +1100, Justin Clift wrote:
On 22/12/2010, at 10:30 PM, Daniel Veillard wrote:
Also on the release name, should we go 0.9.0 considering the refactorings (i.e. indicating future patches will be harder to apply to earlier branches) or stick to 0.8.7 (considering that there isn't major feature improvement ... unless I missed them !),
My initial thinking is 0.8.7, but I don't feel strongly about it. :)
With the "freeze", what's a good process to put in place while frozen to make sure only bugs and doc improvements go in?
Well that should be part of the review process and people who have commit rights are supposed to know the rules ;-)
Heh, sure. Is that approach really working in reality though (recently anyway)? :) I'm thinking... not so much.
Il giorno mer, 22/12/2010 alle 19.30 +0800, Daniel Veillard ha scritto:
maybe we ought to make a new release at the end of the month to try to catch possible regressions introduced as early as possible.
I'd suggest making a release candidate, rather than a release for now. As per the version, I'd go for 0.8.7 myself, after all the version should be intended more for users than developers, and there is no requirement to change, e.g. configuration files. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
On Wed, Dec 22, 2010 at 01:32:55PM +0100, Diego Elio Pettenò wrote:
Il giorno mer, 22/12/2010 alle 19.30 +0800, Daniel Veillard ha scritto:
maybe we ought to make a new release at the end of the month to try to catch possible regressions introduced as early as possible.
I'd suggest making a release candidate, rather than a release for now. As per the version, I'd go for 0.8.7 myself, after all the version should be intended more for users than developers, and there is no requirement to change, e.g. configuration files.
Okay for version 0.8.7 makes more sense. But I don't see what a release candidate brings that is not available from ftp://libvirt.org/libvirt/libvirt-git-snapshot.tar.gz Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 23/12/2010, at 12:12 AM, Daniel Veillard wrote:
On Wed, Dec 22, 2010 at 01:32:55PM +0100, Diego Elio Pettenò wrote:
Il giorno mer, 22/12/2010 alle 19.30 +0800, Daniel Veillard ha scritto:
maybe we ought to make a new release at the end of the month to try to catch possible regressions introduced as early as possible.
I'd suggest making a release candidate, rather than a release for now. As per the version, I'd go for 0.8.7 myself, after all the version should be intended more for users than developers, and there is no requirement to change, e.g. configuration files.
Okay for version 0.8.7 makes more sense. But I don't see what a release candidate brings that is not available from ftp://libvirt.org/libvirt/libvirt-git-snapshot.tar.gz
Yeah, I can definitely see your point with that. I think the "missing piece" here is some way of letting people know that "ok, now you need to start testing the XYZ tarball, as we're preparing for a release." That's probably solvable with an "official" email to the users and dev mailing lists at "freeze" time. Something saying "We've now entered source code freeze period. Please test the XYZ tarball to make sure it works for you, and report any bugs you find so they get fixed for the release." On a related note, we should probably set up a libvirt-announce@redhat.com mailing list, used for release/important announcements and similar. Not everyone that wants to know of the releases wants to receive user and/or developer mailing list traffic.
On Thu, Dec 23, 2010 at 12:21:31AM +1100, Justin Clift wrote:
On 23/12/2010, at 12:12 AM, Daniel Veillard wrote:
But I don't see what a release candidate brings that is not available from ftp://libvirt.org/libvirt/libvirt-git-snapshot.tar.gz
Yeah, I can definitely see your point with that.
I think the "missing piece" here is some way of letting people know that "ok, now you need to start testing the XYZ tarball, as we're preparing for a release."
yes, that's a messaging problem, not a technical problem. I need to be more vocal about entering the freeze (a single mail won't make it) and should probably point to the snapshots.
On a related note, we should probably set up a libvirt-announce@redhat.com mailing list, used for release/important announcements and similar. Not everyone that wants to know of the releases wants to receive user and/or developer mailing list traffic.
We had that debate a couple of years ago, at the time the size of the followers were small enough it wasn't considered useful (-users too) but at this point, yes, that's something to do, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 23/12/2010, at 10:47 AM, Daniel Veillard wrote:
On a related note, we should probably set up a libvirt-announce@redhat.com mailing list, used for release/important announcements and similar. Not everyone that wants to know of the releases wants to receive user and/or developer mailing list traffic.
We had that debate a couple of years ago, at the time the size of the followers were small enough it wasn't considered useful (-users too) but at this point, yes, that's something to do,
No worries. Just did an online submission here to get it created. Nominated yourself as list admin. :)
Il giorno mer, 22/12/2010 alle 21.12 +0800, Daniel Veillard ha scritto:
But I don't see what a release candidate brings that is not available from ftp://libvirt.org/libvirt/libvirt-git-snapshot.tar.gz
A stable checksum, to begin with, and a make dist-created package. Missing files for instance cannot be found by using either a git checkout or a git snapshot, and can only be found when using the output of make dist. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
On 23/12/2010, at 12:25 AM, Diego Elio Pettenò wrote:
Il giorno mer, 22/12/2010 alle 21.12 +0800, Daniel Veillard ha scritto:
But I don't see what a release candidate brings that is not available from ftp://libvirt.org/libvirt/libvirt-git-snapshot.tar.gz
A stable checksum, to begin with, and a make dist-created package. Missing files for instance cannot be found by using either a git checkout or a git snapshot, and can only be found when using the output of make dist.
As a thought, I'm pretty sure the hourly git snapshot does get created with make dist. It was part of the problem we were having a while ago on OSX, requiring autotools on the libvirt.org server be updated to resolve it.
On Thu, Dec 23, 2010 at 05:07:15AM +1100, Justin Clift wrote:
On 23/12/2010, at 12:25 AM, Diego Elio Pettenò wrote:
Il giorno mer, 22/12/2010 alle 21.12 +0800, Daniel Veillard ha scritto:
But I don't see what a release candidate brings that is not available from ftp://libvirt.org/libvirt/libvirt-git-snapshot.tar.gz
A stable checksum, to begin with, and a make dist-created package. Missing files for instance cannot be found by using either a git checkout or a git snapshot, and can only be found when using the output of make dist.
As a thought, I'm pretty sure the hourly git snapshot does get created with make dist.
Confirmed. And unless something goes really wrong the checkout it's built upon should be 1/ clean and 2/ up to date. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Wed, Dec 22, 2010 at 09:12:30PM +0800, Daniel Veillard wrote:
On Wed, Dec 22, 2010 at 01:32:55PM +0100, Diego Elio Pettenò wrote:
Il giorno mer, 22/12/2010 alle 19.30 +0800, Daniel Veillard ha scritto:
maybe we ought to make a new release at the end of the month to try to catch possible regressions introduced as early as possible.
I'd suggest making a release candidate, rather than a release for now. As per the version, I'd go for 0.8.7 myself, after all the version should be intended more for users than developers, and there is no requirement to change, e.g. configuration files.
Okay for version 0.8.7 makes more sense. But I don't see what a release candidate brings that is not available from ftp://libvirt.org/libvirt/libvirt-git-snapshot.tar.gz
I think a release candidate tarball would help get the message out that we are about to release. The existence of the RC tarball is itself notice that things are not expected to change, so everybody should try to test it. The snapshots always exist with the same name, so one can't just keep an eye out for a new candidate. Dave
于 2010年12月22日 19:30, Daniel Veillard 写道:
Hello all,
as some of you may have noticed, I'm back online, just in a very different timezone now ! I'm still behind on reading the list emails but a lot of the changes in the last month have been refactoring and cleanups, and maybe we ought to make a new release at the end of the month to try to catch possible regressions introduced as early as possible. What do people think of a new release for the new year, which would mean entering freeze over the week-end. My own testing will probably be limited as most of my machines are in boxes in a container somewhere, but I should be able to make a release :-) Also on the release name, should we go 0.9.0 considering the refactorings (i.e. indicating future patches will be harder to apply to earlier branches) or stick to 0.8.7 (considering that there isn't major feature improvement ... unless I missed them !),
Opinions ?
Vote for 0.8.7, as no major feature improvement indeed.
Daniel
On 12/23/2010 07:09 AM, Osier Yang wrote:
于 2010年12月22日 19:30, Daniel Veillard 写道:
Hello all,
as some of you may have noticed, I'm back online, just in a very different timezone now ! I'm still behind on reading the list emails but a lot of the changes in the last month have been refactoring and cleanups, and maybe we ought to make a new release at the end of the month to try to catch possible regressions introduced as early as possible. What do people think of a new release for the new year, which would mean entering freeze over the week-end. My own testing will probably be limited as most of my machines are in boxes in a container somewhere, but I should be able to make a release :-) Also on the release name, should we go 0.9.0 considering the refactorings (i.e. indicating future patches will be harder to apply to earlier branches) or stick to 0.8.7 (considering that there isn't major feature improvement ... unless I missed them !),
Opinions ?
Vote for 0.8.7, as no major feature improvement indeed.
So the addition of the new vmware workstation backend is not major? :) I don't have much of a preference, 0.8.7 works for me. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Thu, Dec 23, 2010 at 10:00:37AM -0700, Eric Blake wrote:
On 12/23/2010 07:09 AM, Osier Yang wrote:
Vote for 0.8.7, as no major feature improvement indeed.
So the addition of the new vmware workstation backend is not major? :)
Ah, I missed that :-)
I don't have much of a preference, 0.8.7 works for me.
Sounds like some kind of consensus, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
于 2010年12月24日 01:00, Eric Blake 写道:
On 12/23/2010 07:09 AM, Osier Yang wrote:
于 2010年12月22日 19:30, Daniel Veillard 写道:
Hello all,
as some of you may have noticed, I'm back online, just in a very different timezone now ! I'm still behind on reading the list emails but a lot of the changes in the last month have been refactoring and cleanups, and maybe we ought to make a new release at the end of the month to try to catch possible regressions introduced as early as possible. What do people think of a new release for the new year, which would mean entering freeze over the week-end. My own testing will probably be limited as most of my machines are in boxes in a container somewhere, but I should be able to make a release :-) Also on the release name, should we go 0.9.0 considering the refactorings (i.e. indicating future patches will be harder to apply to earlier branches) or stick to 0.8.7 (considering that there isn't major feature improvement ... unless I missed them !),
Opinions ?
Vote for 0.8.7, as no major feature improvement indeed.
So the addition of the new vmware workstation backend is not major? :)
oh, indeed, forgot it, :-)
I don't have much of a preference, 0.8.7 works for me.
participants (6)
-
Daniel Veillard -
Dave Allan -
Diego Elio Pettenò -
Eric Blake -
Justin Clift -
Osier Yang