Since our release process has become easier of late, I would like to try to do a minor release (0.3.1) of the aeolus packages at the end of the current sprint (Tuesday, 23 August).
For that to work, it would be ideal to have all patches tested and pushed by Friday, 19 August. That's the RFC part of this message: do we think it would be possible to make that deadline?
Ideally, in order to do releases at the end of each sprint, we should have a few days built in for packaging and testing. How do you see our chances for doing that this sprint?
TIA for your input, Steve|eggs
On Wed, Aug 17, 2011 at 08:32:50AM -0500, Steve Linabery wrote:
Since our release process has become easier of late, I would like to try to do a minor release (0.3.1) of the aeolus packages at the end of the current sprint (Tuesday, 23 August).
For that to work, it would be ideal to have all patches tested and pushed by Friday, 19 August. That's the RFC part of this message: do we think it would be possible to make that deadline?
Ideally, in order to do releases at the end of each sprint, we should have a few days built in for packaging and testing. How do you see our chances for doing that this sprint?
I think wrapping up a couple of days ahead of time, to permit a greater focus on testing and to allow time to for packaging, is an excellent idea, if not something we're already doing. It does, however, have the effect of basically shrinking our sprints by a day or two.
However, speaking only for myself, I'm not terribly optimistic that we're going to have everything in the present sprint done, or even be most of the way there, in the next couple of days. (But I'd love to find out I was wrong!)
-- Matt
On Wed, Aug 17, 2011 at 09:37:13AM -0400, Matt Wagner wrote:
I think wrapping up a couple of days ahead of time, to permit a greater focus on testing and to allow time to for packaging, is an excellent idea, if not something we're already doing. It does, however, have the
Oops, that was intended to read "if not something we're already *supposed to be* doing."
-- Matt
On 17/08/2011, at 11:32 PM, Steve Linabery wrote:
Since our release process has become easier of late, I would like to try to do a minor release (0.3.1) of the aeolus packages at the end of the current sprint (Tuesday, 23 August).
For that to work, it would be ideal to have all patches tested and pushed by Friday, 19 August. That's the RFC part of this message: do we think it would be possible to make that deadline?
Ideally, in order to do releases at the end of each sprint, we should have a few days built in for packaging and testing. How do you see our chances for doing that this sprint?
Worth aiming for. :)
Something I haven't checked, is whether aeolus-configure now disables deltacloud-core when it runs.
That should go into 0.3.1, but I'm not sure if it was turned into a Redmine task and given an owner. (?)
Regards and best wishes,
Justin Clift
-- Aeolus Community Manager http://www.aeolusproject.org
On 08/17/11 - 08:32:50AM, Steve Linabery wrote:
Since our release process has become easier of late, I would like to try to do a minor release (0.3.1) of the aeolus packages at the end of the current sprint (Tuesday, 23 August).
For that to work, it would be ideal to have all patches tested and pushed by Friday, 19 August. That's the RFC part of this message: do we think it would be possible to make that deadline?
Ideally, in order to do releases at the end of each sprint, we should have a few days built in for packaging and testing. How do you see our chances for doing that this sprint?
The thing I would suggest here is that we *not* do feature-based releases. Almost all successful open-source projects that I know of do time-based releases; if a particular feature makes a release, great, and if not, it just gets punted to the next one. This makes sure that you don't have interminably long release cycles waiting for a particular feature to get in that you promised. I would suggest we do the same; say "the next version is coming out on *this* date", and then just stick to it.
Additionally, I think we probably want to do a different numbering scheme. 0.3.1 sounds like a maintenance release for 0.3 series, and in point of fact I think we may want to do that eventually. It does not sound like the development release heading towards a new version. I would suggest something like 0.4.0-m1 (for milestone 1), or similar. That way we will work towards a final 0.4.0. The one snafu here would be RPM versioning, as 0.4.0-m1 might be "bigger" than 0.4.0, but we can probably figure something out.
On Wed, 2011-08-17 at 09:52 -0400, Chris Lalancette wrote:
On 08/17/11 - 08:32:50AM, Steve Linabery wrote:
Since our release process has become easier of late, I would like to try to do a minor release (0.3.1) of the aeolus packages at the end of the current sprint (Tuesday, 23 August).
For that to work, it would be ideal to have all patches tested and pushed by Friday, 19 August. That's the RFC part of this message: do we think it would be possible to make that deadline?
Ideally, in order to do releases at the end of each sprint, we should have a few days built in for packaging and testing. How do you see our chances for doing that this sprint?
The thing I would suggest here is that we *not* do feature-based releases. Almost all successful open-source projects that I know of do time-based releases; if a particular feature makes a release, great, and if not, it just gets punted to the next one. This makes sure that you don't have interminably long release cycles waiting for a particular feature to get in that you promised. I would suggest we do the same; say "the next version is coming out on *this* date", and then just stick to it.
Definitely. And well said.
<aside>
Havoc Pennington's original proposal for GNOME to adopt time-based releases is still worth a read:
http://mail.gnome.org/archives/gnome-hackers/2002-June/msg00041.html
Funnily enough, this was written not long after the Agile Manifesto, but I don't think it was influenced by Agile. Reading it now, though, you can see a lot of overlap with Agile Principles - e.g. it's all about "continuous delivery of valuable software".
</aside>
Additionally, I think we probably want to do a different numbering scheme. 0.3.1 sounds like a maintenance release for 0.3 series, and in point of fact I think we may want to do that eventually. It does not sound like the development release heading towards a new version. I would suggest something like 0.4.0-m1 (for milestone 1), or similar. That way we will work towards a final 0.4.0. The one snafu here would be RPM versioning, as 0.4.0-m1 might be "bigger" than 0.4.0, but we can probably figure something out.
Just call it 0.4.0 IMHO.
Cheers, Mark.
On 08/17/2011 10:12 AM, Mark McLoughlin wrote:
On Wed, 2011-08-17 at 09:52 -0400, Chris Lalancette wrote:
On 08/17/11 - 08:32:50AM, Steve Linabery wrote:
Since our release process has become easier of late, I would like to try to do a minor release (0.3.1) of the aeolus packages at the end of the current sprint (Tuesday, 23 August).
For that to work, it would be ideal to have all patches tested and pushed by Friday, 19 August. That's the RFC part of this message: do we think it would be possible to make that deadline?
Ideally, in order to do releases at the end of each sprint, we should have a few days built in for packaging and testing. How do you see our chances for doing that this sprint?
The thing I would suggest here is that we *not* do feature-based releases. Almost all successful open-source projects that I know of do time-based releases; if a particular feature makes a release, great, and if not, it just gets punted to the next one. This makes sure that you don't have interminably long release cycles waiting for a particular feature to get in that you promised. I would suggest we do the same; say "the next version is coming out on *this* date", and then just stick to it.
Definitely. And well said.
<aside>
Havoc Pennington's original proposal for GNOME to adopt time-based releases is still worth a read:
http://mail.gnome.org/archives/gnome-hackers/2002-June/msg00041.html
Funnily enough, this was written not long after the Agile Manifesto, but I don't think it was influenced by Agile. Reading it now, though, you can see a lot of overlap with Agile Principles - e.g. it's all about "continuous delivery of valuable software".
</aside>
Additionally, I think we probably want to do a different numbering scheme. 0.3.1 sounds like a maintenance release for 0.3 series, and in point of fact I think we may want to do that eventually. It does not sound like the development release heading towards a new version. I would suggest something like 0.4.0-m1 (for milestone 1), or similar. That way we will work towards a final 0.4.0. The one snafu here would be RPM versioning, as 0.4.0-m1 might be "bigger" than 0.4.0, but we can probably figure something out.
Just call it 0.4.0 IMHO.
Although if we call it 0.4.0 then we need to stop calling the current iteration 0.4.0 (i.e. the 3-month one). Maybe that's 0.4.1 (if we do 0.4.0.1, etc for minor releases). It's still confusing to me though, since 0.3.0 was an "iteration"-level release, 0.4.0 sounds like a similar level
Maybe it should be 0.3.1 and maintenance on 0.3.0 should be 0.3.0.1 ?
Scott
Cheers, Mark.
aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
On 18/08/2011, at 12:12 AM, Mark McLoughlin wrote: <snip>
0.3.1 should be a "bug fix" release for 0.3.0. That's actually what I'd actually thought was meant. ;) (didn't properly grok the "with the new packages from this sprint" bit).
<snip>
Just call it 0.4.0 IMHO.
Yeah, I'd go with 0.4.0 as well. Subsequent minor ones will be 0.4.1, 0.4.2, etc. The major release when we're wrapping up this iteration could be whichever 0.4.x is next in line, or maybe 0.5.0? Not that fussed.
For time based releases. At this early stage of Aeolus life, yeah. Definitely better to get stuff "out there" I reckon.
When we've been around ~20 years (ie PostgreSQL), then long stability periods with feature based releases is probably ok. :)
Regards and best wishes,
Justin Clift
-- Aeolus Community Manager http://www.aeolusproject.org
On 08/17/2011 10:12 AM, Mark McLoughlin wrote:
On Wed, 2011-08-17 at 09:52 -0400, Chris Lalancette wrote:
On 08/17/11 - 08:32:50AM, Steve Linabery wrote:
Since our release process has become easier of late, I would like to try to do a minor release (0.3.1) of the aeolus packages at the end of the current sprint (Tuesday, 23 August).
For that to work, it would be ideal to have all patches tested and pushed by Friday, 19 August. That's the RFC part of this message: do we think it would be possible to make that deadline?
Ideally, in order to do releases at the end of each sprint, we should have a few days built in for packaging and testing. How do you see our chances for doing that this sprint?
The thing I would suggest here is that we *not* do feature-based releases. Almost all successful open-source projects that I know of do time-based releases; if a particular feature makes a release, great, and if not, it just gets punted to the next one. This makes sure that you don't have interminably long release cycles waiting for a particular feature to get in that you promised. I would suggest we do the same; say "the next version is coming out on *this* date", and then just stick to it.
Definitely. And well said.
<aside>
Havoc Pennington's original proposal for GNOME to adopt time-based releases is still worth a read:
http://mail.gnome.org/archives/gnome-hackers/2002-June/msg00041.html
Funnily enough, this was written not long after the Agile Manifesto, but I don't think it was influenced by Agile. Reading it now, though, you can see a lot of overlap with Agile Principles - e.g. it's all about "continuous delivery of valuable software".
</aside>
Additionally, I think we probably want to do a different numbering scheme. 0.3.1 sounds like a maintenance release for 0.3 series, and in point of fact I think we may want to do that eventually. It does not sound like the development release heading towards a new version. I would suggest something like 0.4.0-m1 (for milestone 1), or similar. That way we will work towards a final 0.4.0. The one snafu here would be RPM versioning, as 0.4.0-m1 might be "bigger" than 0.4.0, but we can probably figure something out.
Just call it 0.4.0 IMHO.
Cheers, Mark.
aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
Mark,
Awesome reminder that we aren't exactly treading new ground here. Great find!
A number of us really like the time-based release approach but I suspect we've not done a really good job at building consensus within the community around using a time based approach.
On version number, I fear that I led Steve astray in an earlier conversation and agree something 0.4.0ish is the right thing and that we ought to reserve 0.3.1 for maintenance release purposes.
With regards to rpm versioning, we could consider keeping the git hash in the rpm release for the milestone builds. I don't have super strong reasons to keep it other than the fact that it means we don't have to worry about incrementing the spec quite so frequently.
Thanks, Mike
On Thu, Aug 18, 2011 at 11:58:43PM -0400, Mike Orazi wrote:
On 08/17/2011 10:12 AM, Mark McLoughlin wrote:
On Wed, 2011-08-17 at 09:52 -0400, Chris Lalancette wrote:
On 08/17/11 - 08:32:50AM, Steve Linabery wrote:
Since our release process has become easier of late, I would like to try to do a minor release (0.3.1) of the aeolus packages at the end of the current sprint (Tuesday, 23 August).
For that to work, it would be ideal to have all patches tested and pushed by Friday, 19 August. That's the RFC part of this message: do we think it would be possible to make that deadline?
Ideally, in order to do releases at the end of each sprint, we should have a few days built in for packaging and testing. How do you see our chances for doing that this sprint?
The thing I would suggest here is that we *not* do feature-based releases. Almost all successful open-source projects that I know of do time-based releases; if a particular feature makes a release, great, and if not, it just gets punted to the next one. This makes sure that you don't have interminably long release cycles waiting for a particular feature to get in that you promised. I would suggest we do the same; say "the next version is coming out on *this* date", and then just stick to it.
Definitely. And well said.
<aside>
Havoc Pennington's original proposal for GNOME to adopt time-based releases is still worth a read:
http://mail.gnome.org/archives/gnome-hackers/2002-June/msg00041.html
Funnily enough, this was written not long after the Agile Manifesto, but I don't think it was influenced by Agile. Reading it now, though, you can see a lot of overlap with Agile Principles - e.g. it's all about "continuous delivery of valuable software".
</aside>
Additionally, I think we probably want to do a different numbering scheme. 0.3.1 sounds like a maintenance release for 0.3 series, and in point of fact I think we may want to do that eventually. It does not sound like the development release heading towards a new version. I would suggest something like 0.4.0-m1 (for milestone 1), or similar. That way we will work towards a final 0.4.0. The one snafu here would be RPM versioning, as 0.4.0-m1 might be "bigger" than 0.4.0, but we can probably figure something out.
Just call it 0.4.0 IMHO.
Cheers, Mark.
aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
Mark,
Awesome reminder that we aren't exactly treading new ground here. Great find!
A number of us really like the time-based release approach but I suspect we've not done a really good job at building consensus within the community around using a time based approach.
On version number, I fear that I led Steve astray in an earlier conversation and agree something 0.4.0ish is the right thing and that we ought to reserve 0.3.1 for maintenance release purposes.
With regards to rpm versioning, we could consider keeping the git hash in the rpm release for the milestone builds. I don't have super strong reasons to keep it other than the fact that it means we don't have to worry about incrementing the spec quite so frequently.
Thanks, Mike _______________________________________________ aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
At this point with the ongoing issues around bundler it's not clear to me that we are stable enough to cut a release. Based on conversations with jayg iiuc install is only working some of the time.
I am adding a 0.4.x branch to conductor git repo at current tip of master, but I'm not confident we're ready to tag that as an 0.4.0 release.
Comments/suggestions welcome!
s|e
On Wed, 2011-08-24 at 12:00 -0500, Steve Linabery wrote:
On Thu, Aug 18, 2011 at 11:58:43PM -0400, Mike Orazi wrote:
On 08/17/2011 10:12 AM, Mark McLoughlin wrote:
On Wed, 2011-08-17 at 09:52 -0400, Chris Lalancette wrote:
On 08/17/11 - 08:32:50AM, Steve Linabery wrote:
<snip
At this point with the ongoing issues around bundler it's not clear to me that we are stable enough to cut a release. Based on conversations with jayg iiuc install is only working some of the time.
I am adding a 0.4.x branch to conductor git repo at current tip of master, but I'm not confident we're ready to tag that as an 0.4.0 release.
Comments/suggestions welcome!
s|e
I know I am late to this discussion, but I am wondering if we should really be having 'official' releases per sprint, as things tend to be rather unstable at that time. My proposal instead is this:
* Keep the current testing repo at or very close to 'bleeding edge' (could be 1 build per day or something). IOW, this should be pretty close to whatever is on master, and is what people can try out without having to build from source. As with building from source, this means there are going to be times when things do not work 100% as expected.
* At the end of each _Iteration_, do an official release, which we have spent $days/weeks testing and fixing bugs on w/o adding features. QE has tested this with a given set of dependencies (version of factory, iwhd, etc), and given it the green light.
I think this allows us the best of both strategies we have tried in the past. It both gives us a regular release schedule for official releases (with very frequent unofficial releases to testing), and also lets us make sure our official releases are not horribly broken (ie, they have actually been tested properly).
I suspect this will raise the ire of some, but its my idea and I sticking to it :)
Oh, and while I am ticking people off - why not have a 'stable-updates' or similar repo that always points to the latest official release? This would allow us to always point new users at the same url on our site (maybe less of an issue once f16 is out, but I think still valid, as we may have a new release that doesn't go into f16 or whatever fedora is current at that time). Seems like that would be an awful lot easier for a user to do an update than having to grab a whole new .repo file.
Ok, commence flame war!
-j
aeolus-devel@lists.fedorahosted.org