Proposal: Reorganization of the Project Management
After having coordinated the 3.2 release with questionable success, I have some thoughts on the ways to do this better going forward. I brought this up on the meeting last week, and was supposed to follow up quickly on list with the proposal, so here it is. 1. We need to have a group of stakeholders from each of the projects/components in the our release that will make up the release committee. 2. Members of that group should be available on the weekly meeting or have someone else on the team fill in for them 3. There should be someone that is in charge of this group of stakeholders with a preference for someone that is not tied to any one sub-project.[1] 4. The person who leads the committee should run the weekly meeting 5. The person who leads the committee should track docs, publicity, marketing, etc I've already sent out a request for people from each of the sub-projects for the 3.3 release. I will continue to run the weekly meeting until we find someone to take on that role, but I feel that I'm not the right person to do this long term. If you have thoughts on who could fill the leadership role or wish to volunteer yourself, please reply to this email. Thanks Mike [1] If there isn't someone from the community who is not tied to a sub-project, then elect someone from group on a per-release basis.
Hi Mike, On 03/06/2013 12:54 PM, Mike Burns wrote:
After having coordinated the 3.2 release with questionable success, I have some thoughts on the ways to do this better going forward. I brought this up on the meeting last week, and was supposed to follow up quickly on list with the proposal, so here it is.
I also have some thoughts on general release process and improving it, and have discussed this a little bit with Moran already.
1. We need to have a group of stakeholders from each of the projects/components in the our release that will make up the release committee. 2. Members of that group should be available on the weekly meeting or have someone else on the team fill in for them 3. There should be someone that is in charge of this group of stakeholders with a preference for someone that is not tied to any one sub-project.[1] 4. The person who leads the committee should run the weekly meeting 5. The person who leads the committee should track docs, publicity, marketing, etc
My fear with this type of scheme is that the weekly meetings will continue to be a focal point, to the detriment of getting engagement from the community to get a release out the door (with everything that entails, including docs, release notes, marketing and promotion, packaging, translations...).
If you have thoughts on who could fill the leadership role or wish to volunteer yourself, please reply to this email.
Perhaps more important than the person is that we agree on the process for getting releases, and that we get buy-in into that process. I have previously mentioned GNOME as a good example for a release process: GNOME release process: https://live.gnome.org/ReleasePlanning This process talks only about time - if you want to release on date X, you need a code freeze at X-4 days, a string freeze at X-3 weeks, etc. It does not describe the frenzy of release-related activity that happens after these freezes, or the branching policy that most projects have. For example, after the string freeze, translators and documentation people kick into high gear. After the UI freeze, we start taking screenshots for release notes and doing screencasts. After the feature freeze, the release team starts hammering home the release blocker bugs for the release, and we increase the emphasis on integration testing. Another nice GNOME feature is the feature proposal period, when features are proposed and discussed on the developer mailing list, and then prioritised by the release team. I think we could mix and match this nicely with a roadmap process like the one I proposed previously here: http://blogs.gnome.org/bolsh/2011/02/07/drawing-up-a-roadmap/ In fact, I don't think GNOME's branching policy is terribly good - development happens on trunk through to the release, and then a release branch is made. I would prefer to see release branches made when the code freezes (or even feature freeze) comes in, to allow people to continue committing complete but too-late-for-release features to trunk. Max Kanat-Alexander from Bugzilla wrote about the value of doing things like this, even though it makes life harder for the core team: http://www.codesimplicity.com/post/open-source-community-simplified/ There's an extended mailing list thread on the subject: https://groups.google.com/d/topic/mozilla.dev.apps.bugzilla/Ug9aoykXpRc/disc... In brief: when you freeze, you lose non-professional developers who just stop working on the project until after the release. So it's worthwhile keeping the trunk open, and doing your feature & code freezes on a release branch. Here's a link on the value of timeboxed feature planning and having a hard go/no go for features that get in or don't (especially the advice close to the end): http://www.joelonsoftware.com/items/2007/10/26.html In short, you prioritise features, and start working on the most important ones, and then the ones that are not ready to ship by feature freeze get deferred to the next feature prioritisation discussion. General advice based on my experience with oVirt: * I recommend a 6 month cadence with ~4 months feature development and ~2 months release preparation * Ensure that documentation, release marketing and website updates are included in the release plan * Move regular release prep to arch@ - the weekly meeting hasn't been effective to getting people engaged in the release process. The real-time meetings will be good for the release team you've proposed to sync up and agree on what the blocker bugs are, but you really need to have people reading those threads and prioritising their work to align with that * Make regular point releases (alpha, beta 1, beta 2, RC1, whatever they're called) before and after a release. I'm looking forward to 3.2.1! * Avoid tying oVirt releases to a specific release of an operating system (be it RHEL 7 or F18). I know that F18 was a special case and complicated things because of significant platform changes, but we still need to support F17 and CentOS 6.3/4 for this release, and hopefully next release we'll also be adding Debian & Ubuntu support. I would love to hear feedback/see how we can ensure that all this happens for this coming release. Step 1 is to prioritise the feature requests we gathered from the community (and from the oVirt team) and say what we would like to achieve with the 3.3 release and beyond. Cheers, Dave. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
On 03/06/2013 10:29 AM, Dave Neary wrote:
Hi Mike,
On 03/06/2013 12:54 PM, Mike Burns wrote:
After having coordinated the 3.2 release with questionable success, I have some thoughts on the ways to do this better going forward. I brought this up on the meeting last week, and was supposed to follow up quickly on list with the proposal, so here it is.
I also have some thoughts on general release process and improving it, and have discussed this a little bit with Moran already.
1. We need to have a group of stakeholders from each of the projects/components in the our release that will make up the release committee. 2. Members of that group should be available on the weekly meeting or have someone else on the team fill in for them 3. There should be someone that is in charge of this group of stakeholders with a preference for someone that is not tied to any one sub-project.[1] 4. The person who leads the committee should run the weekly meeting 5. The person who leads the committee should track docs, publicity, marketing, etc
My fear with this type of scheme is that the weekly meetings will continue to be a focal point, to the detriment of getting engagement from the community to get a release out the door (with everything that entails, including docs, release notes, marketing and promotion, packaging, translations...).
We don't necessarily have to concentrate the work on the weekly meeting. It can be organized however people want. I do strongly believe that we need *some* organization around a Project Manager and group or committee of people that are involved with each of the sub-projects. One of my big takeaways from 3.2 was that I had trouble reaching people for some of the projects. Having this sort of committee approach where each sub-project has a representative and designated contact can alleviate that problem. Having a person who essentially chairs that committee is essential, so there is a single person who has a view into the overall release and all the parts and is responsible for making sure all the projects and release related things get done. I think it's important that they be disconnected from one sub-project, but that's not a requirement. I think that coordinating everything that goes into the release is too big a job to do well while also working closely with a sub-project.
If you have thoughts on who could fill the leadership role or wish to volunteer yourself, please reply to this email.
Perhaps more important than the person is that we agree on the process for getting releases, and that we get buy-in into that process.
I have previously mentioned GNOME as a good example for a release process:
GNOME release process: https://live.gnome.org/ReleasePlanning
This process talks only about time - if you want to release on date X, you need a code freeze at X-4 days, a string freeze at X-3 weeks, etc. It does not describe the frenzy of release-related activity that happens after these freezes, or the branching policy that most projects have. For example, after the string freeze, translators and documentation people kick into high gear. After the UI freeze, we start taking screenshots for release notes and doing screencasts. After the feature freeze, the release team starts hammering home the release blocker bugs for the release, and we increase the emphasis on integration testing.dne
We can certainly base our process on this time based approach. I think we tried to do this initially. We need to work out what the right timeframes are for oVirt though. How much time do we need between freeze and RC and GA, etc? Some of those can be estimated now that we've done a few releases, but they should probably be discussed.
Another nice GNOME feature is the feature proposal period, when features are proposed and discussed on the developer mailing list, and then prioritised by the release team. I think we could mix and match this nicely with a roadmap process like the one I proposed previously here: http://blogs.gnome.org/bolsh/2011/02/07/drawing-up-a-roadmap/
In fact, I don't think GNOME's branching policy is terribly good - development happens on trunk through to the release, and then a release branch is made. I would prefer to see release branches made when the code freezes (or even feature freeze) comes in, to allow people to continue committing complete but too-late-for-release features to trunk.
Max Kanat-Alexander from Bugzilla wrote about the value of doing things like this, even though it makes life harder for the core team:
http://www.codesimplicity.com/post/open-source-community-simplified/
There's an extended mailing list thread on the subject:
https://groups.google.com/d/topic/mozilla.dev.apps.bugzilla/Ug9aoykXpRc/disc...
In brief: when you freeze, you lose non-professional developers who just stop working on the project until after the release. So it's worthwhile keeping the trunk open, and doing your feature & code freezes on a release branch.
Agree completely. This is why we branch where we do. I would argue strongly against moving the branching to later in the cycle.
Here's a link on the value of timeboxed feature planning and having a hard go/no go for features that get in or don't (especially the advice close to the end):
http://www.joelonsoftware.com/items/2007/10/26.html
In short, you prioritise features, and start working on the most important ones, and then the ones that are not ready to ship by feature freeze get deferred to the next feature prioritisation discussion.
I'm perfectly happy to go to a more structured feature process. The one we have now is a bit too open, for my tastes.
General advice based on my experience with oVirt: * I recommend a 6 month cadence with ~4 months feature development and ~2 months release preparation
Agree in general, but not willing to make that call.
* Ensure that documentation, release marketing and website updates are included in the release plan
Agreed
* Move regular release prep to arch@ - the weekly meeting hasn't been effective to getting people engaged in the release process. The real-time meetings will be good for the release team you've proposed to sync up and agree on what the blocker bugs are, but you really need to have people reading those threads and prioritising their work to align with that
Needs discussion. I'm not sure giving up the meeting is the right step, but making this more continuous rather than in weekly increments is an admirable goal. I think we should figure out what the right pieces are for arch vs the weekly meeting.
* Make regular point releases (alpha, beta 1, beta 2, RC1, whatever they're called) before and after a release. I'm looking forward to 3.2.1!
Not sure I agree with this. I do this for critical issues with ovirt-node, but I hesitate to say "regular" point releases. As needed, yes, but not regular. I'm all for having an alpha early in the cycle and official beta and RC releases.
* Avoid tying oVirt releases to a specific release of an operating system (be it RHEL 7 or F18). I know that F18 was a special case and complicated things because of significant platform changes, but we still need to support F17 and CentOS 6.3/4 for this release, and hopefully next release we'll also be adding Debian & Ubuntu support.
Agreed, no tying it to a specific release/distro. I'm bought in on that, but there was push back when I tried to get it even on F17 and F18.
I would love to hear feedback/see how we can ensure that all this happens for this coming release. Step 1 is to prioritise the feature requests we gathered from the community (and from the oVirt team) and say what we would like to achieve with the 3.3 release and beyond.
Cheers, Dave.
Just an observation -- Dave is more concentrated on the "how" of the release, while I was more focused on the "who" aspect. They're both certainly related, and both very important. Thanks Mike
----- Original Message -----
Hi Mike,
On 03/06/2013 12:54 PM, Mike Burns wrote:
After having coordinated the 3.2 release with questionable success, I have some thoughts on the ways to do this better going forward. I brought this up on the meeting last week, and was supposed to follow up quickly on list with the proposal, so here it is.
I also have some thoughts on general release process and improving it, and have discussed this a little bit with Moran already.
1. We need to have a group of stakeholders from each of the projects/components in the our release that will make up the release committee. 2. Members of that group should be available on the weekly meeting or have someone else on the team fill in for them 3. There should be someone that is in charge of this group of stakeholders with a preference for someone that is not tied to any one sub-project.[1] 4. The person who leads the committee should run the weekly meeting 5. The person who leads the committee should track docs, publicity, marketing, etc
My fear with this type of scheme is that the weekly meetings will continue to be a focal point, to the detriment of getting engagement from the community to get a release out the door (with everything that entails, including docs, release notes, marketing and promotion, packaging, translations...).
If you have thoughts on who could fill the leadership role or wish to volunteer yourself, please reply to this email.
Perhaps more important than the person is that we agree on the process for getting releases, and that we get buy-in into that process.
I have previously mentioned GNOME as a good example for a release process:
GNOME release process: https://live.gnome.org/ReleasePlanning
This process talks only about time - if you want to release on date X, you need a code freeze at X-4 days, a string freeze at X-3 weeks, etc. It does not describe the frenzy of release-related activity that happens after these freezes, or the branching policy that most projects have. For example, after the string freeze, translators and documentation people kick into high gear. After the UI freeze, we start taking screenshots for release notes and doing screencasts. After the feature freeze, the release team starts hammering home the release blocker bugs for the release, and we increase the emphasis on integration testing.
Another nice GNOME feature is the feature proposal period, when features are proposed and discussed on the developer mailing list, and then prioritised by the release team. I think we could mix and match this nicely with a roadmap process like the one I proposed previously here: http://blogs.gnome.org/bolsh/2011/02/07/drawing-up-a-roadmap/
In fact, I don't think GNOME's branching policy is terribly good - development happens on trunk through to the release, and then a release branch is made. I would prefer to see release branches made when the code freezes (or even feature freeze) comes in, to allow people to continue committing complete but too-late-for-release features to trunk.
Max Kanat-Alexander from Bugzilla wrote about the value of doing things like this, even though it makes life harder for the core team:
http://www.codesimplicity.com/post/open-source-community-simplified/
There's an extended mailing list thread on the subject:
https://groups.google.com/d/topic/mozilla.dev.apps.bugzilla/Ug9aoykXpRc/disc...
In brief: when you freeze, you lose non-professional developers who just stop working on the project until after the release. So it's worthwhile keeping the trunk open, and doing your feature & code freezes on a release branch.
Here's a link on the value of timeboxed feature planning and having a hard go/no go for features that get in or don't (especially the advice close to the end):
http://www.joelonsoftware.com/items/2007/10/26.html
In short, you prioritise features, and start working on the most important ones, and then the ones that are not ready to ship by feature freeze get deferred to the next feature prioritisation discussion.
+1 on all of the above
General advice based on my experience with oVirt: * I recommend a 6 month cadence with ~4 months feature development and ~2 months release preparation * Ensure that documentation, release marketing and website updates are included in the release plan * Move regular release prep to arch@ - the weekly meeting hasn't been effective to getting people engaged in the release process. The real-time meetings will be good for the release team you've proposed to sync up and agree on what the blocker bugs are, but you really need to have people reading those threads and prioritising their work to align with that * Make regular point releases (alpha, beta 1, beta 2, RC1, whatever they're called) before and after a release. I'm looking forward to 3.2.1!
if we have a 6 month release cycle, do you envision 1-2 point releases? e.g. 3.2.1 2 months after 3.2 and 3.2.2 2 months after that and then after another couple of months 3.3?
* Avoid tying oVirt releases to a specific release of an operating system (be it RHEL 7 or F18). I know that F18 was a special case and complicated things because of significant platform changes, but we still need to support F17 and CentOS 6.3/4 for this release, and hopefully next release we'll also be adding Debian & Ubuntu support.
+100 on this one. This means that we need to make new features that require capabilities that are only available in specific versions of other components optional (not stop development on the one hand, but not break if underlying components have not been updated to latest and greatest).
I would love to hear feedback/see how we can ensure that all this happens for this coming release. Step 1 is to prioritise the feature requests we gathered from the community (and from the oVirt team) and say what we would like to achieve with the 3.3 release and beyond.
Cheers, Dave.
-- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 _______________________________________________ Arch mailing list Arch@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch
----- Original Message -----
From: "Ayal Baron" <abaron@redhat.com> To: "Dave Neary" <dneary@redhat.com> Cc: "arch" <arch@ovirt.org>, board@ovirt.org Sent: Saturday, March 9, 2013 11:31:15 PM Subject: Re: Proposal: Reorganization of the Project Management
----- Original Message -----
Hi Mike,
On 03/06/2013 12:54 PM, Mike Burns wrote:
After having coordinated the 3.2 release with questionable success, I have some thoughts on the ways to do this better going forward. I brought this up on the meeting last week, and was supposed to follow up quickly on list with the proposal, so here it is.
I also have some thoughts on general release process and improving it, and have discussed this a little bit with Moran already.
1. We need to have a group of stakeholders from each of the projects/components in the our release that will make up the release committee. 2. Members of that group should be available on the weekly meeting or have someone else on the team fill in for them 3. There should be someone that is in charge of this group of stakeholders with a preference for someone that is not tied to any one sub-project.[1] 4. The person who leads the committee should run the weekly meeting 5. The person who leads the committee should track docs, publicity, marketing, etc
My fear with this type of scheme is that the weekly meetings will continue to be a focal point, to the detriment of getting engagement from the community to get a release out the door (with everything that entails, including docs, release notes, marketing and promotion, packaging, translations...).
If you have thoughts on who could fill the leadership role or wish to volunteer yourself, please reply to this email.
Perhaps more important than the person is that we agree on the process for getting releases, and that we get buy-in into that process.
I have previously mentioned GNOME as a good example for a release process:
GNOME release process: https://live.gnome.org/ReleasePlanning
This process talks only about time - if you want to release on date X, you need a code freeze at X-4 days, a string freeze at X-3 weeks, etc. It does not describe the frenzy of release-related activity that happens after these freezes, or the branching policy that most projects have. For example, after the string freeze, translators and documentation people kick into high gear. After the UI freeze, we start taking screenshots for release notes and doing screencasts. After the feature freeze, the release team starts hammering home the release blocker bugs for the release, and we increase the emphasis on integration testing.
Another nice GNOME feature is the feature proposal period, when features are proposed and discussed on the developer mailing list, and then prioritised by the release team. I think we could mix and match this nicely with a roadmap process like the one I proposed previously here: http://blogs.gnome.org/bolsh/2011/02/07/drawing-up-a-roadmap/
Agree on both; feature nomination period is much needed as demonstrated by the responses Itamar got to his mail. I'd like to see some commitment to assist development &&|| testing the suggested feature coming from the feature proposer. As for roadmap, I agree as well, we should strive to have it charted and modify as needed. The biggest obstacle with such maps is how much the project is committed to it; when do you drop a feature which does not align with the map and when do you modify the map for the feature. I think this is resolvable mostly by discussions, and eventually a much needed map will help others as well.
In fact, I don't think GNOME's branching policy is terribly good - development happens on trunk through to the release, and then a release branch is made. I would prefer to see release branches made when the code freezes (or even feature freeze) comes in, to allow people to continue committing complete but too-late-for-release features to trunk.
Max Kanat-Alexander from Bugzilla wrote about the value of doing things like this, even though it makes life harder for the core team:
http://www.codesimplicity.com/post/open-source-community-simplified/
There's an extended mailing list thread on the subject:
https://groups.google.com/d/topic/mozilla.dev.apps.bugzilla/Ug9aoykXpRc/disc...
In brief: when you freeze, you lose non-professional developers who just stop working on the project until after the release. So it's worthwhile keeping the trunk open, and doing your feature & code freezes on a release branch.
Here's a link on the value of timeboxed feature planning and having a hard go/no go for features that get in or don't (especially the advice close to the end):
http://www.joelonsoftware.com/items/2007/10/26.html
In short, you prioritise features, and start working on the most important ones, and then the ones that are not ready to ship by feature freeze get deferred to the next feature prioritisation discussion.
+1 on all of the above
General advice based on my experience with oVirt: * I recommend a 6 month cadence with ~4 months feature development and ~2 months release preparation * Ensure that documentation, release marketing and website updates are included in the release plan * Move regular release prep to arch@ - the weekly meeting hasn't been effective to getting people engaged in the release process. The real-time meetings will be good for the release team you've proposed to sync up and agree on what the blocker bugs are, but you really need to have people reading those threads and prioritising their work to align with that * Make regular point releases (alpha, beta 1, beta 2, RC1, whatever they're called) before and after a release. I'm looking forward to 3.2.1!
if we have a 6 month release cycle, do you envision 1-2 point releases? e.g. 3.2.1 2 months after 3.2 and 3.2.2 2 months after that and then after another couple of months 3.3?
* Avoid tying oVirt releases to a specific release of an operating system (be it RHEL 7 or F18). I know that F18 was a special case and complicated things because of significant platform changes, but we still need to support F17 and CentOS 6.3/4 for this release, and hopefully next release we'll also be adding Debian & Ubuntu support.
+100 on this one. This means that we need to make new features that require capabilities that are only available in specific versions of other components optional (not stop development on the one hand, but not break if underlying components have not been updated to latest and greatest).
I'm afraid today we are using some tools / concepts which are distro- specific. Still, the first step must be done in order to have ovirt available in other distro's. One of the most common questions I got in FOSDEM was about having a Debian packaging. So full ack from me on this one, knowing that it will take time and efforts.
I would love to hear feedback/see how we can ensure that all this happens for this coming release. Step 1 is to prioritise the feature requests we gathered from the community (and from the oVirt team) and say what we would like to achieve with the 3.3 release and beyond.
Cheers, Dave.
-- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
Hi Ayal, On 03/09/2013 10:31 PM, Ayal Baron wrote:
General advice based on my experience with oVirt: * I recommend a 6 month cadence with ~4 months feature development and ~2 months release preparation
<snip>
* Make regular point releases (alpha, beta 1, beta 2, RC1, whatever they're called) before and after a release. I'm looking forward to 3.2.1!
if we have a 6 month release cycle, do you envision 1-2 point releases? e.g. 3.2.1 2 months after 3.2 and 3.2.2 2 months after that and then after another couple of months 3.3?
I was thinking we could lower the cost of making a point release to the point where we could have a release every month... like this: February: 3.2.0 released March: 3.2.1 released - contains fixes for important issues discovered post-release in 3.2.0 - in the meantime, feature proposal and prioritisation (and development) continues on the trunk April: 3.2.2 released - only if there are significant bug fixes or new translations May: 3.3.alpha1 released - in-progress work, contains some early features, aimed for testing to identify features that need additional work early. Release branch is made now. June: 3.3.alpha2 released - corresponds to feature freeze. At this stage, incomplete features should no longer be committed. Work can start on testing, integration testing, bug day July: 3.3.beta1 released - Corresponds to UI and string freeze - translations and docs, and release notes, should be underway already, but can hit full speed. Testing and bug fixing continues August: 3.3.0 released The only release that should take longer than a couple of hours to put out is 3.3.0 - the other releases are a tag in the source code, and a pointer to specific nightly builds. Cheers, Dave. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
----- Original Message -----
Hi Ayal,
On 03/09/2013 10:31 PM, Ayal Baron wrote:
General advice based on my experience with oVirt: * I recommend a 6 month cadence with ~4 months feature development and ~2 months release preparation
<snip>
* Make regular point releases (alpha, beta 1, beta 2, RC1, whatever they're called) before and after a release. I'm looking forward to 3.2.1!
if we have a 6 month release cycle, do you envision 1-2 point releases? e.g. 3.2.1 2 months after 3.2 and 3.2.2 2 months after that and then after another couple of months 3.3?
I was thinking we could lower the cost of making a point release to the point where we could have a release every month... like this:
I'm not sure I understand what below reduces cost of making the point release.
February: 3.2.0 released March: 3.2.1 released - contains fixes for important issues discovered post-release in 3.2.0 - in the meantime, feature proposal and prioritisation (and development) continues on the trunk April: 3.2.2 released - only if there are significant bug fixes or new translations
I have yet to see a month pass without important fixes.
May: 3.3.alpha1 released - in-progress work, contains some early features, aimed for testing to identify features that need additional work early. Release branch is made now.
From this point there are no more point releases to 3.2 then, correct?
June: 3.3.alpha2 released - corresponds to feature freeze. At this stage, incomplete features should no longer be committed. Work can start on testing, integration testing, bug day
No longer committed to the 3.3.alpha2 branch you mean? since as you've stated above, there shouldn't be a 'quiet' period in master as it deters contributors.
July: 3.3.beta1 released - Corresponds to UI and string freeze - translations and docs, and release notes, should be underway already, but can hit full speed. Testing and bug fixing continues
August: 3.3.0 released
The only release that should take longer than a couple of hours to put out is 3.3.0 - the other releases are a tag in the source code, and a pointer to specific nightly builds.
I don't see how that is possible. 3.2.1 in this way will contain new features and code which is not fully tested yet (negative flows etc) so you may come out with a release which is less stable than the base version (3.2).
Cheers, Dave.
-- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
Hi, On 03/11/2013 05:15 PM, Ayal Baron wrote:
I was thinking we could lower the cost of making a point release to the point where we could have a release every month... like this:
I'm not sure I understand what below reduces cost of making the point release.
Just this:
The only release that should take longer than a couple of hours to put out is 3.3.0 - the other releases are a tag in the source code, and a pointer to specific nightly builds.
May: 3.3.alpha1 released - in-progress work, contains some early features, aimed for testing to identify features that need additional work early. Release branch is made now.
From this point there are no more point releases to 3.2 then, correct?
It's always possible, but that's the general idea. You're 2 months from the stable release, no new features go in the release branch, and you need to concentrate on getting the next release out.
June: 3.3.alpha2 released - corresponds to feature freeze. At this stage, incomplete features should no longer be committed. Work can start on testing, integration testing, bug day
No longer committed to the 3.3.alpha2 branch you mean? since as you've stated above, there shouldn't be a 'quiet' period in master as it deters contributors.
Let me explain the branching strategy below - it's pretty standard in several open source projects, but maybe people aren't familiar with it.
The only release that should take longer than a couple of hours to put out is 3.3.0 - the other releases are a tag in the source code, and a pointer to specific nightly builds.
I don't see how that is possible. 3.2.1 in this way will contain new features and code which is not fully tested yet (negative flows etc) so you may come out with a release which is less stable than the base version (3.2).
OK - here's a quick ASCII Art branching strategy for a release cycle. If everything is committed to trunk, your branch tree looks like this: Trunk | | Feature 1 +---+ | | Feature 2 +---+---------+ | | | | | | +---+ Merge | | | +-------------+ Merge | | Now, you want to make a new major release. At feature freeze (when all features to be included are complete), you create a release branch. Trunk | | 3.3 release branch +---------------------------+ <- Feature freeze/branch creation | | | | | | | Feature | +---+ | | | Merge fix | +---+---------------------> | | | | | | | +---+ Merge | | X <- 3.3.beta1 release | | | Merge fix | +-------------------------> | | | Features and bug fixes continue to get done on the trunk, and those which are for the 3.3 release get merged into the 3.3 release branch. 3.3 releases are made off the 3.3 release branch. The 3.3.0, 3.3.1 and 3.3.2 releases are all tagged on the 3.3 release branch. Development continues on the trunk throughout this time. At some point, the difficult part of this (committing fixes to the trunk and then merging them to the 2.3 branch) slows down or stops, and everyone is once again concentrating on the trunk, until such time as the 3.4 or 4.0 (or whatever you decide to call it) release branch is created. Once we "abandon" the 3.3 branch, there is no point in continuing to make point releases there. It serves the project better to have a period where everyone is concentrating on implementing new features and integrating them into the trunk, rather than having attention split between maintenance and new development indefinitely. In general, 6 weeks after a release is enough time to identify and take xcare of the biggest issues in the release. Does that help explain what I have in mind better? Thanks, Dave. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
----- Original Message -----
Hi,
On 03/11/2013 05:15 PM, Ayal Baron wrote:
I was thinking we could lower the cost of making a point release to the point where we could have a release every month... like this:
I'm not sure I understand what below reduces cost of making the point release.
Just this:
The only release that should take longer than a couple of hours to put out is 3.3.0 - the other releases are a tag in the source code, and a pointer to specific nightly builds.
May: 3.3.alpha1 released - in-progress work, contains some early features, aimed for testing to identify features that need additional work early. Release branch is made now.
From this point there are no more point releases to 3.2 then, correct?
It's always possible, but that's the general idea. You're 2 months from the stable release, no new features go in the release branch, and you need to concentrate on getting the next release out.
June: 3.3.alpha2 released - corresponds to feature freeze. At this stage, incomplete features should no longer be committed. Work can start on testing, integration testing, bug day
No longer committed to the 3.3.alpha2 branch you mean? since as you've stated above, there shouldn't be a 'quiet' period in master as it deters contributors.
Let me explain the branching strategy below - it's pretty standard in several open source projects, but maybe people aren't familiar with it.
The only release that should take longer than a couple of hours to put out is 3.3.0 - the other releases are a tag in the source code, and a pointer to specific nightly builds.
I don't see how that is possible. 3.2.1 in this way will contain new features and code which is not fully tested yet (negative flows etc) so you may come out with a release which is less stable than the base version (3.2).
OK - here's a quick ASCII Art branching strategy for a release cycle.
If everything is committed to trunk, your branch tree looks like this:
Trunk | | Feature 1 +---+ | | Feature 2 +---+---------+ | | | | | | +---+ Merge | | | +-------------+ Merge | |
Now, you want to make a new major release. At feature freeze (when all features to be included are complete), you create a release branch.
Trunk | | 3.3 release branch +---------------------------+ <- Feature freeze/branch creation | | | | | | | Feature | +---+ | | | Merge fix | +---+---------------------> | | | | | | | +---+ Merge | | X <- 3.3.beta1 release | | | Merge fix | +-------------------------> | | |
Features and bug fixes continue to get done on the trunk, and those which are for the 3.3 release get merged into the 3.3 release branch. 3.3 releases are made off the 3.3 release branch.
The 3.3.0, 3.3.1 and 3.3.2 releases are all tagged on the 3.3 release branch.
Development continues on the trunk throughout this time. At some point, the difficult part of this (committing fixes to the trunk and then merging them to the 2.3 branch) slows down or stops, and everyone is once again concentrating on the trunk, until such time as the 3.4 or 4.0 (or whatever you decide to call it) release branch is created.
Once we "abandon" the 3.3 branch, there is no point in continuing to make point releases there. It serves the project better to have a period where everyone is concentrating on implementing new features and integrating them into the trunk, rather than having attention split between maintenance and new development indefinitely. In general, 6 weeks after a release is enough time to identify and take xcare of the biggest issues in the release.
Does that help explain what I have in mind better?
Yes, it is fine, but saying that making the point release is a no brainer is misleading since you take a major hit during the entire period you have a branch (and you have a branch almost all the time - 3.2.1, 3.2.2, 3.3.alpha1, 3.3.alpha2...). The further you are from the last release the more difficult it is to backport from trunk to the branch (3.2.2 has to be based on 3.2.1 and not directly from trunk for stability). In fact, you need to branch 3.2.1 from 3.2 and not from trunk otherwise you immediately get patches that are not about stability. If we do this we'd need to define the criteria of what is backported and what is not.
Thanks, Dave.
-- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
On 03/11/2013 10:42 PM, Ayal Baron wrote:
----- Original Message -----
Hi,
On 03/11/2013 05:15 PM, Ayal Baron wrote:
I was thinking we could lower the cost of making a point release to the point where we could have a release every month... like this:
I'm not sure I understand what below reduces cost of making the point release.
Just this:
The only release that should take longer than a couple of hours to put out is 3.3.0 - the other releases are a tag in the source code, and a pointer to specific nightly builds.
May: 3.3.alpha1 released - in-progress work, contains some early features, aimed for testing to identify features that need additional work early. Release branch is made now.
From this point there are no more point releases to 3.2 then, correct?
It's always possible, but that's the general idea. You're 2 months from the stable release, no new features go in the release branch, and you need to concentrate on getting the next release out.
June: 3.3.alpha2 released - corresponds to feature freeze. At this stage, incomplete features should no longer be committed. Work can start on testing, integration testing, bug day
No longer committed to the 3.3.alpha2 branch you mean? since as you've stated above, there shouldn't be a 'quiet' period in master as it deters contributors.
Let me explain the branching strategy below - it's pretty standard in several open source projects, but maybe people aren't familiar with it.
The only release that should take longer than a couple of hours to put out is 3.3.0 - the other releases are a tag in the source code, and a pointer to specific nightly builds.
I don't see how that is possible. 3.2.1 in this way will contain new features and code which is not fully tested yet (negative flows etc) so you may come out with a release which is less stable than the base version (3.2).
OK - here's a quick ASCII Art branching strategy for a release cycle.
If everything is committed to trunk, your branch tree looks like this:
Trunk | | Feature 1 +---+ | | Feature 2 +---+---------+ | | | | | | +---+ Merge | | | +-------------+ Merge | |
Now, you want to make a new major release. At feature freeze (when all features to be included are complete), you create a release branch.
Trunk | | 3.3 release branch +---------------------------+ <- Feature freeze/branch creation | | | | | | | Feature | +---+ | | | Merge fix | +---+---------------------> | | | | | | | +---+ Merge | | X <- 3.3.beta1 release | | | Merge fix | +-------------------------> | | |
Features and bug fixes continue to get done on the trunk, and those which are for the 3.3 release get merged into the 3.3 release branch. 3.3 releases are made off the 3.3 release branch.
The 3.3.0, 3.3.1 and 3.3.2 releases are all tagged on the 3.3 release branch.
Development continues on the trunk throughout this time. At some point, the difficult part of this (committing fixes to the trunk and then merging them to the 2.3 branch) slows down or stops, and everyone is once again concentrating on the trunk, until such time as the 3.4 or 4.0 (or whatever you decide to call it) release branch is created.
Once we "abandon" the 3.3 branch, there is no point in continuing to make point releases there. It serves the project better to have a period where everyone is concentrating on implementing new features and integrating them into the trunk, rather than having attention split between maintenance and new development indefinitely. In general, 6 weeks after a release is enough time to identify and take xcare of the biggest issues in the release.
Does that help explain what I have in mind better?
Yes, it is fine, but saying that making the point release is a no brainer is misleading since you take a major hit during the entire period you have a branch (and you have a branch almost all the time - 3.2.1, 3.2.2, 3.3.alpha1, 3.3.alpha2...). The further you are from the last release the more difficult it is to backport from trunk to the branch (3.2.2 has to be based on 3.2.1 and not directly from trunk for stability). In fact, you need to branch 3.2.1 from 3.2 and not from trunk otherwise you immediately get patches that are not about stability. If we do this we'd need to define the criteria of what is backported and what is not.
we don't want to deter contributions so we don't want to block continued work on master. but taking the 3.3 stabilization branch earlier than alpha will only mean it gets less bug fixes due to the overhead of backporting them. I think it is fine to specify beta is in two weeks, and only bug fixes should go in at that period. or we don't do this. but considering the amount of bug fixes around the "alpha" period, doesn't make sense to branch before it (the risk from new features is lesser from amount of bugs which won't be backported in my view).
Thanks, Dave.
-- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
_______________________________________________ Arch mailing list Arch@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch
Hi, On 03/12/2013 10:14 AM, Itamar Heim wrote:
On 03/11/2013 10:42 PM, Ayal Baron wrote:
Dave Neary wrote:
Now, you want to make a new major release. At feature freeze (when all features to be included are complete), you create a release branch.
<snip>
Features and bug fixes continue to get done on the trunk, and those which are for the 3.3 release get merged into the 3.3 release branch. 3.3 releases are made off the 3.3 release branch.
The 3.3.0, 3.3.1 and 3.3.2 releases are all tagged on the 3.3 release branch.
<snip>
Does that help explain what I have in mind better?
Yes, it is fine, but saying that making the point release is a no brainer is misleading since you take a major hit during the entire period you have a branch (and you have a branch almost all the time - 3.2.1, 3.2.2, 3.3.alpha1, 3.3.alpha2...).
Yes, that's correct - all of the time when you have a release branch, you have the additional cost of merging back, and the longer the release branch lasts, the bigger the cost becomes.
In fact, you need to branch 3.2.1 from 3.2 and not from trunk otherwise you immediately get patches that are not about stability. If we do this we'd need to define the criteria of what is backported and what is not.
3.2.1 does not get a branch, it's a tag on the 3.2 branch. The criteria for what gets backported and what is not is straightforward, I think - the only thing that gets backported are bug fixes to released features - no new features.
we don't want to deter contributions so we don't want to block continued work on master. but taking the 3.3 stabilization branch earlier than alpha will only mean it gets less bug fixes due to the overhead of backporting them. I think it is fine to specify beta is in two weeks, and only bug fixes should go in at that period. or we don't do this. but considering the amount of bug fixes around the "alpha" period, doesn't make sense to branch before it (the risk from new features is lesser from amount of bugs which won't be backported in my view).
As you can see, I am suggesting branching after feature freeze - after alpha releases, and before beta releases. It could be delayed a few days, perhaps a couple of weeks, for sure, but I would like to have a place to land new features that are ready to be integrated after the feature freeze, but which we have agreed should not go into the next stable release. IMHO, that place should be the trunk (and that is only possible if you have already made a release branch). Cheers, Dave. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
On 03/12/2013 11:39 AM, Dave Neary wrote:
3.2.1 does not get a branch, it's a tag on the 3.2 branch. The criteria for what gets backported and what is not is straightforward, I think - the only thing that gets backported are bug fixes to released features - no new features.
it also gets the patches for .el6 support in 3.2 as an exception this time.
we don't want to deter contributions so we don't want to block continued work on master. but taking the 3.3 stabilization branch earlier than alpha will only mean it gets less bug fixes due to the overhead of backporting them. I think it is fine to specify beta is in two weeks, and only bug fixes should go in at that period. or we don't do this. but considering the amount of bug fixes around the "alpha" period, doesn't make sense to branch before it (the risk from new features is lesser from amount of bugs which won't be backported in my view).
As you can see, I am suggesting branching after feature freeze - after alpha releases, and before beta releases. It could be delayed a few days, perhaps a couple of weeks, for sure, but I would like to have a place to land new features that are ready to be integrated after the feature freeze, but which we have agreed should not go into the next stable release. IMHO, that place should be the trunk (and that is only possible if you have already made a release branch).
if the branch is temporary, to only fix critical issues for that phase, then goes away and we rebase for the next branch - i'm fine with it. but since you can't assess how many patches would be needed, usually at early phases snapshots are used - snapshots are just taking master, testing it, fixing all broken things and taking master again for next snapshot (hence snapshots are usually weekly builds). i think it is a better approach as a concept till the beta build.
On 03/11/2013 05:07 PM, Dave Neary wrote:
Hi Ayal,
On 03/09/2013 10:31 PM, Ayal Baron wrote:
General advice based on my experience with oVirt: * I recommend a 6 month cadence with ~4 months feature development and ~2 months release preparation
<snip>
* Make regular point releases (alpha, beta 1, beta 2, RC1, whatever they're called) before and after a release. I'm looking forward to 3.2.1!
if we have a 6 month release cycle, do you envision 1-2 point releases? e.g. 3.2.1 2 months after 3.2 and 3.2.2 2 months after that and then after another couple of months 3.3?
I was thinking we could lower the cost of making a point release to the point where we could have a release every month... like this:
February: 3.2.0 released March: 3.2.1 released - contains fixes for important issues discovered post-release in 3.2.0 - in the meantime, feature proposal and prioritisation (and development) continues on the trunk April: 3.2.2 released - only if there are significant bug fixes or new translations May: 3.3.alpha1 released - in-progress work, contains some early features, aimed for testing to identify features that need additional work early. Release branch is made now. June: 3.3.alpha2 released - corresponds to feature freeze. At this stage, incomplete features should no longer be committed. Work can start on testing, integration testing, bug day July: 3.3.beta1 released - Corresponds to UI and string freeze - translations and docs, and release notes, should be underway already, but can hit full speed. Testing and bug fixing continues
August: 3.3.0 released
The only release that should take longer than a couple of hours to put out is 3.3.0 - the other releases are a tag in the source code, and a pointer to specific nightly builds.
Cheers, Dave.
+1 on release roadmap. I was lacking some additional items on the release process of 3.2 and i would like to bring it up for 3.3: -ovirt functional dev group involvement -representative on weekly meetings -communication on when a new feature is in the code (nightly builds) - to engage early testing from the community -wiki page with contacts/maintainers, features roadmap and status, howto, etc. -lack of tracking/monitoring priority bugs/common issues -weekly meetings has been ran by very few people mostly by doing monologues- we might want to change the agenda of the meetings. I think the area coming from all above items is the need to improve communication between developers-> project PM ->community Thanks, Moran.
participants (6)
-
Ayal Baron -
Dave Neary -
Doron Fediuck -
Itamar Heim -
Mike Burns -
Moran Goldboim