We’ve seen quite a lot of good work going on since the last release! It feels like it is about the right time to cut and announce the 0.3.0 release.
In order to get the release process rolling, I’d like to propose a few milestones over the course of the next week:
* All ACK-ed patches for conductor land in the next branch by Wednesday (July 20) * Ensure conductor v0.3.0 tag is created in git by Wednesday (July 20) * Create a 0.3.x branch to track any maintenance fixes for conductor (July 20) * imagefactory, oz and iwhd tarballs available by Wednesday (July 20) * Finalize aeolus-configure for 0.3.0 release by Wednesday (July 20) * Build Fedora 14 RPMs of all components & promote to: http://repos.fedorapeople.org/repos/aeolus/conductor/0.3.0
Does the plan work for the various maintainers? Are there any changes that we should be trying to get into 0.3.0 that won’t be ready for Wednesday?
Thanks, Mike
Hey Mike,
On Mon, 2011-07-18 at 12:31 -0400, Mike Orazi wrote:
We’ve seen quite a lot of good work going on since the last release! It feels like it is about the right time to cut and announce the 0.3.0 release.
In order to get the release process rolling, I’d like to propose a few milestones over the course of the next week:
- All ACK-ed patches for conductor land in the next branch by Wednesday
(July 20)
- Ensure conductor v0.3.0 tag is created in git by Wednesday (July 20)
- Create a 0.3.x branch to track any maintenance fixes for conductor
(July 20)
- imagefactory, oz and iwhd tarballs available by Wednesday (July 20)
- Finalize aeolus-configure for 0.3.0 release by Wednesday (July 20)
- Build Fedora 14 RPMs of all components & promote to:
Oh, yes - we also need to prepare release notes. The recent thread should be a basis for what new features to promote:
https://fedorahosted.org/pipermail/aeolus-devel/2011-July/thread.html#3096
Does the plan work for the various maintainers? Are there any changes that we should be trying to get into 0.3.0 that won’t be ready for Wednesday?
Some of the other things we also discussed:
- How to handle aeolus-image living in the conductor repo but using a different version number to conductor (e.g. do we also tag the v0.3.0 conductor commit with aeolus-image-0.0.1?). I'm proposing aeolus-image moves out on its own.
- This image_factory/Oz bug looked like something we want might to wait to be fixed:
https://bugzilla.redhat.com/722805
but Ian has already fixed it
- Whether there are features in deltacloud-core since the 0.3.0 release that we need for our 0.3.0 release. And whether there's any chance of a deltacloud 0.4.0 release in time for our release.
Since deltacloud is an external dependency, I think we should avoid depending on anything not in an official deltacloud release. For example, if we do this when Aeolus is in Fedora, we wouldn't be able to push a new Aeolus into Fedora until a new deltacloud release has been pushed.
Cheers, Mark.
On 07/19/2011 05:33 AM, Mark McLoughlin wrote:
Hey Mike,
On Mon, 2011-07-18 at 12:31 -0400, Mike Orazi wrote:
We’ve seen quite a lot of good work going on since the last release! It feels like it is about the right time to cut and announce the 0.3.0 release.
In order to get the release process rolling, I’d like to propose a few milestones over the course of the next week:
- All ACK-ed patches for conductor land in the next branch by Wednesday
(July 20)
- Ensure conductor v0.3.0 tag is created in git by Wednesday (July 20)
- Create a 0.3.x branch to track any maintenance fixes for conductor
(July 20)
- imagefactory, oz and iwhd tarballs available by Wednesday (July 20)
- Finalize aeolus-configure for 0.3.0 release by Wednesday (July 20)
- Build Fedora 14 RPMs of all components& promote to:
Oh, yes - we also need to prepare release notes. The recent thread should be a basis for what new features to promote:
https://fedorahosted.org/pipermail/aeolus-devel/2011-July/thread.html#3096
Agreed. Justin has been kind enough to handle a lot of the more formal release announcements recently. I'm happy to put something together, but he tends to do a pretty darn good job with it so as long as he's game, they are all his!
Does the plan work for the various maintainers? Are there any changes that we should be trying to get into 0.3.0 that won’t be ready for Wednesday?
Some of the other things we also discussed:
- How to handle aeolus-image living in the conductor repo but using a different version number to conductor (e.g. do we also tag the v0.3.0 conductor commit with aeolus-image-0.0.1?). I'm proposing aeolus-image moves out on its own.
Personally, I'm not sure that I have a strong opinion on the right thing to do here. I believe I've seen some chatter on this between you, clalance, and jayg but that there isn't a final decision on the best way to proceed. Either way, in theory it should be fairly minor tweaking here and there so my guess is we just reach a decision today and go with it.
This image_factory/Oz bug looked like something we want might to wait to be fixed:
https://bugzilla.redhat.com/722805
but Ian has already fixed it
Yea, we should be in reasonable shape. We can all keep an eye on the imagefactory & Oz to make sure the correct functionality lands as expected, but it seems like we are in pretty good shape.
- Whether there are features in deltacloud-core since the 0.3.0 release that we need for our 0.3.0 release. And whether there's any chance of a deltacloud 0.4.0 release in time for our release.
The only bits that we really need are related to getting IP address from vmware guests & the user data insertion bits. These are currently in the source tree and slotted for release.
Since deltacloud is an external dependency, I think we should avoid depending on anything not in an official deltacloud release. For example, if we do this when Aeolus is in Fedora, we wouldn't be able to push a new Aeolus into Fedora until a new deltacloud release has been pushed.Cheers, Mark.
Agree (going forward). It appears that we miscalculated on this one, as the community release likely won't hit fedora for approximately a week. Because we do have the ability to temporarily carry one, I'd like to suggest we try to get our hands on a release candidate and temporarily host it knowing that what eventually lands in fedora will have a larger version and should get picked up.
Going forward, as a project I think we need to work a bit on improving our predictions on what we functionality we think we'll need from each project involved in making Aeolus come together. As you point out, this will become critical when Aeolus as a whole is in Fedora. My hope is that we are improving in our public planning efforts (I already see quite a bit of good discussion for 0.4.0 planning so I'm very encouraged!)
Thanks for the comments & feedback.
Mike
On Wed, 2011-07-20 at 07:30 -0400, Mike Orazi wrote:
Some of the other things we also discussed:
- How to handle aeolus-image living in the conductor repo but using a different version number to conductor (e.g. do we also tag the v0.3.0 conductor commit with aeolus-image-0.0.1?). I'm proposing aeolus-image moves out on its own.
Personally, I'm not sure that I have a strong opinion on the right thing to do here. I believe I've seen some chatter on this between you, clalance, and jayg but that there isn't a final decision on the best way to proceed. Either way, in theory it should be fairly minor tweaking here and there so my guess is we just reach a decision today and go with it.
This is done now. It just means we need to tag a version in both of those repos, publish the gems and build RPMs from those.
Cheers, Mark.
On 07/20/2011 11:22 AM, Mark McLoughlin wrote:
On Wed, 2011-07-20 at 07:30 -0400, Mike Orazi wrote:
Some of the other things we also discussed:
- How to handle aeolus-image living in the conductor repo but using a different version number to conductor (e.g. do we also tag the v0.3.0 conductor commit with aeolus-image-0.0.1?). I'm proposing aeolus-image moves out on its own.Personally, I'm not sure that I have a strong opinion on the right thing to do here. I believe I've seen some chatter on this between you, clalance, and jayg but that there isn't a final decision on the best way to proceed. Either way, in theory it should be fairly minor tweaking here and there so my guess is we just reach a decision today and go with it.
This is done now. It just means we need to tag a version in both of those repos, publish the gems and build RPMs from those.
Cheers, Mark.
aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
Mark,
Thanks for knocking this out. I'm fairly certain that Steve is pulling stuff in from the new repos on github but I doubt anyone has tagged the git repo. Would you mind taking care of the tagging?
Thanks, Mike
On Wed, 2011-07-20 at 21:28 -0400, Mike Orazi wrote:
On 07/20/2011 11:22 AM, Mark McLoughlin wrote:
On Wed, 2011-07-20 at 07:30 -0400, Mike Orazi wrote:
Some of the other things we also discussed:
- How to handle aeolus-image living in the conductor repo but using a different version number to conductor (e.g. do we also tag the v0.3.0 conductor commit with aeolus-image-0.0.1?). I'm proposing aeolus-image moves out on its own.Personally, I'm not sure that I have a strong opinion on the right thing to do here. I believe I've seen some chatter on this between you, clalance, and jayg but that there isn't a final decision on the best way to proceed. Either way, in theory it should be fairly minor tweaking here and there so my guess is we just reach a decision today and go with it.
This is done now. It just means we need to tag a version in both of those repos, publish the gems and build RPMs from those.
Cheers, Mark.
...
Mark,
Thanks for knocking this out. I'm fairly certain that Steve is pulling stuff in from the new repos on github but I doubt anyone has tagged the git repo. Would you mind taking care of the tagging?
Okay, in imagefactory-console, I've created the v0.4.0 tag and 0.4.x branch and bumped the version to 0.5.0. In aeolus-image, I've created the v0.0.1 tag and 0.0.x branch and bumped the version to 0.1.0.
Cheers, Mark.
Hey,
I know we've discussed master vs next before, but I can't seem to find it in the aeolus-devel archives
On Mon, 2011-07-18 at 12:31 -0400, Mike Orazi wrote:
- Create a 0.3.x branch to track any maintenance fixes for conductor
If we have a '0.3.x' branch, do we still need the 'next' branch?
i.e. rather than 'master' being the stable branch and 'next' being the development branch, make 'master' the development branch, '0.3.x' the stable branch and delete the 'next' branch?
Pretty please? :)
Cheers, Mark.
On Tue, Jul 19, 2011 at 10:39:57AM +0100, Mark McLoughlin wrote:
Hey,
I know we've discussed master vs next before, but I can't seem to find it in the aeolus-devel archives
On Mon, 2011-07-18 at 12:31 -0400, Mike Orazi wrote:
- Create a 0.3.x branch to track any maintenance fixes for conductor
If we have a '0.3.x' branch, do we still need the 'next' branch?
i.e. rather than 'master' being the stable branch and 'next' being the development branch, make 'master' the development branch, '0.3.x' the stable branch and delete the 'next' branch?
Pretty please? :)
I do believe everyone in the Conductor community has long been in favor of abandoning the "next" branch -- it seems to cause more pain than it saves. This seems like the right moment to do it. Does anyone object to doing this with the 0.3.x release?
--Hugh
On Tue, 2011-07-19 at 09:11 -0400, Hugh Brock wrote:
On Tue, Jul 19, 2011 at 10:39:57AM +0100, Mark McLoughlin wrote:
Hey,
I know we've discussed master vs next before, but I can't seem to find it in the aeolus-devel archives
On Mon, 2011-07-18 at 12:31 -0400, Mike Orazi wrote:
- Create a 0.3.x branch to track any maintenance fixes for conductor
If we have a '0.3.x' branch, do we still need the 'next' branch?
i.e. rather than 'master' being the stable branch and 'next' being the development branch, make 'master' the development branch, '0.3.x' the stable branch and delete the 'next' branch?
Pretty please? :)
I do believe everyone in the Conductor community has long been in favor of abandoning the "next" branch -- it seems to cause more pain than it saves. This seems like the right moment to do it. Does anyone object to doing this with the 0.3.x release?
--Hugh
+1. Just talked to Mike Orazi, and I think we have discussed this long enough, it is time to just get it over with. I propose we merge whatever we have in next into master asap, then branch off the 0.3 release/maint branch from that point on master. Any bugs should be pushed to master and then can be cherry-picked onto the maint branch by $maintainer as needed. Anyone violently disgaree?
-j
On 07/19/11 - 10:44:03AM, Jason Guiditta wrote:
On Tue, 2011-07-19 at 09:11 -0400, Hugh Brock wrote:
On Tue, Jul 19, 2011 at 10:39:57AM +0100, Mark McLoughlin wrote:
Hey,
I know we've discussed master vs next before, but I can't seem to find it in the aeolus-devel archives
On Mon, 2011-07-18 at 12:31 -0400, Mike Orazi wrote:
- Create a 0.3.x branch to track any maintenance fixes for conductor
If we have a '0.3.x' branch, do we still need the 'next' branch?
i.e. rather than 'master' being the stable branch and 'next' being the development branch, make 'master' the development branch, '0.3.x' the stable branch and delete the 'next' branch?
Pretty please? :)
I do believe everyone in the Conductor community has long been in favor of abandoning the "next" branch -- it seems to cause more pain than it saves. This seems like the right moment to do it. Does anyone object to doing this with the 0.3.x release?
--Hugh
+1. Just talked to Mike Orazi, and I think we have discussed this long enough, it is time to just get it over with. I propose we merge whatever we have in next into master asap, then branch off the 0.3 release/maint branch from that point on master. Any bugs should be pushed to master and then can be cherry-picked onto the maint branch by $maintainer as needed. Anyone violently disgaree?
Yep, totally agree. We should also talk to the fedorahosted admins and mark the 'next' branch as read-only going forward, so nobody pushes there by accident.
If someone lets me know when we do this branching, I can talk to the right people.
On Tue, Jul 19, 2011 at 10:44:03AM -0400, Jason Guiditta wrote:
+1. Just talked to Mike Orazi, and I think we have discussed this long enough, it is time to just get it over with. I propose we merge whatever we have in next into master asap, then branch off the 0.3 release/maint branch from that point on master. Any bugs should be pushed to master and then can be cherry-picked onto the maint branch by $maintainer as needed. Anyone violently disgaree?
This sounds good, but could I humbly propose that this might be best to do at the end of this sprint in a few days? It seems like it may be less-disruptive, and we'd presumably want to merge next into master at that time anyway.
Of course, I don't have any patches in the air, so it doesn't impact me much either way.
-- Matt
On Tue, 2011-07-19 at 13:02 -0400, Matt Wagner wrote:
On Tue, Jul 19, 2011 at 10:44:03AM -0400, Jason Guiditta wrote:
+1. Just talked to Mike Orazi, and I think we have discussed this long enough, it is time to just get it over with. I propose we merge whatever we have in next into master asap, then branch off the 0.3 release/maint branch from that point on master. Any bugs should be pushed to master and then can be cherry-picked onto the maint branch by $maintainer as needed. Anyone violently disgaree?
This sounds good, but could I humbly propose that this might be best to do at the end of this sprint in a few days? It seems like it may be less-disruptive, and we'd presumably want to merge next into master at that time anyway.
The idea is to do it after the 0.3.0 conductor release has been tagged, which seems like the perfect time IMHO
Cheers, Mark.
On 07/19/2011 03:11 PM, Hugh Brock wrote:
On Tue, Jul 19, 2011 at 10:39:57AM +0100, Mark McLoughlin wrote:
Hey,
I know we've discussed master vs next before, but I can't seem to find it in the aeolus-devel archives
On Mon, 2011-07-18 at 12:31 -0400, Mike Orazi wrote:
- Create a 0.3.x branch to track any maintenance fixes for conductor
If we have a '0.3.x' branch, do we still need the 'next' branch?
i.e. rather than 'master' being the stable branch and 'next' being the development branch, make 'master' the development branch, '0.3.x' the stable branch and delete the 'next' branch?
Pretty please? :)
I do believe everyone in the Conductor community has long been in favor of abandoning the "next" branch -- it seems to cause more pain than it saves. This seems like the right moment to do it. Does anyone object to doing this with the 0.3.x release?
--Hugh
Here http://nvie.com/posts/a-successful-git-branching-model/ is a quite good sketch/article of the branching model, that could help us. What do you think about it?
-- Jozef
Hi Jozef,
On Tue, 2011-07-19 at 16:51 +0200, Jozef Zigmund wrote:
On 07/19/2011 03:11 PM, Hugh Brock wrote:
On Tue, Jul 19, 2011 at 10:39:57AM +0100, Mark McLoughlin wrote:
Hey,
I know we've discussed master vs next before, but I can't seem to find it in the aeolus-devel archives
On Mon, 2011-07-18 at 12:31 -0400, Mike Orazi wrote:
- Create a 0.3.x branch to track any maintenance fixes for conductor
If we have a '0.3.x' branch, do we still need the 'next' branch?
i.e. rather than 'master' being the stable branch and 'next' being the development branch, make 'master' the development branch, '0.3.x' the stable branch and delete the 'next' branch?
Pretty please? :)
I do believe everyone in the Conductor community has long been in favor of abandoning the "next" branch -- it seems to cause more pain than it saves. This seems like the right moment to do it. Does anyone object to doing this with the 0.3.x release?
--Hugh
Here http://nvie.com/posts/a-successful-git-branching-model/ is a quite good sketch/article of the branching model, that could help us. What do you think about it?
I've seen it mentioned in a few different places and it always strikes me as a bad idea.
I have enough trouble remembering that we do development on 'next'. That branching structure would be a disaster for me, at least :-)
Seriously, is there something we need other than doing development on master and having stable branches for each release that we want to provide updates for?
Ah, I think I get it now!
It looks to me like this comes from an unhealthy obsession with avoiding any cherry-picking or re-basing - i.e. we would usually commit to master and cherry-pick into the stable branch, giving different commit IDs on each branch. At the expense of frying peoples' brains :-)
Cheers, Mark.
On 07/19/11 - 04:51:44PM, Jozef Zigmund wrote:
On 07/19/2011 03:11 PM, Hugh Brock wrote:
On Tue, Jul 19, 2011 at 10:39:57AM +0100, Mark McLoughlin wrote:
Hey,
I know we've discussed master vs next before, but I can't seem to find it in the aeolus-devel archives
On Mon, 2011-07-18 at 12:31 -0400, Mike Orazi wrote:
- Create a 0.3.x branch to track any maintenance fixes for conductor
If we have a '0.3.x' branch, do we still need the 'next' branch?
i.e. rather than 'master' being the stable branch and 'next' being the development branch, make 'master' the development branch, '0.3.x' the stable branch and delete the 'next' branch?
Pretty please? :)
I do believe everyone in the Conductor community has long been in favor of abandoning the "next" branch -- it seems to cause more pain than it saves. This seems like the right moment to do it. Does anyone object to doing this with the 0.3.x release?
--Hugh
Here http://nvie.com/posts/a-successful-git-branching-model/ is a quite good sketch/article of the branching model, that could help us. What do you think about it?
Like Mark, I just think it is too complicated. From past experience with this master/next split, and with packages, it usually ends up like this:
- Developers only ever look at next - People who want something stable use the packages
That means that there is no target audience for master. Therefore, the current proposal is to basically rename next to master, and kill off next. Then you are addressing the two target groups above, with less confusion.
It gets just a tad more complicated with a long-term maintenance branch, but really very little. You branch off from master at the 0.3.0 tag, continue to develop on master, and only cherry-pick the stuff you want onto the 0.3 branch. When 0.4 comes around, you do the same thing. That way you have a tree with master as the trunk, and only one level of branches hanging off of it, which is pretty easy to understand.
On 07/18/11 - 12:31:36PM, Mike Orazi wrote:
We’ve seen quite a lot of good work going on since the last release! It feels like it is about the right time to cut and announce the 0.3.0 release.
In order to get the release process rolling, I’d like to propose a few milestones over the course of the next week:
- All ACK-ed patches for conductor land in the next branch by Wednesday
(July 20)
- Ensure conductor v0.3.0 tag is created in git by Wednesday (July 20)
- Create a 0.3.x branch to track any maintenance fixes for conductor
(July 20)
- imagefactory, oz and iwhd tarballs available by Wednesday (July 20)
I don't have any outstanding oz bugs that I know about (since imcleod fixed BZ 722805), so this works for me.
Both projects have been tagged and branched for the upcoming community release.
Conductor next has been merged into master. Next should no longer be used and will shortly be place into read-only mode.
For Conductor, the release tag is v0.3.0_RC_1. The release branch is 0.3.0_RC_1.
For Configure, the release tag is v2.0.1_RC_1. The release branch is 2.0.1_RC_1.
Additional patches going into this release should be pushed to both the master and the release branch.
Thanks,
Richard
On 07/20/2011 08:47 PM, Richard Su wrote:
Both projects have been tagged and branched for the upcoming community release.
Conductor next has been merged into master. Next should no longer be used and will shortly be place into read-only mode.
For Conductor, the release tag is v0.3.0_RC_1. The release branch is 0.3.0_RC_1.
For Configure, the release tag is v2.0.1_RC_1. The release branch is 2.0.1_RC_1.
Richard,
Thanks for taking care of tagging and branching!
Additional patches going into this release should be pushed to both the master and the release branch.
Thanks,
Richard
aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
I wanted to add to the last point.
If in doubt regarding whether a commit should land in the release branch feel free to only push to master and ask either on freenode or via the list and someone will be happy to help with determining whether the patch belongs in beta and with the process of cherry-picking the commit onto the branch.
The most useful information that will help folks determine how to proceed is the git hash of the commit on master and the bugzilla that you aren't sure about.
Thanks, Mike
aeolus-devel@lists.fedorahosted.org
-
Chris Lalancette -
Hugh O. Brock -
Jason Guiditta -
jzigmund＠redhat.com -
Mark McLoughlin -
Matt Wagner -
Mike Orazi -
Richard Su