2:54 p.m.
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.
6:29 p.m.
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/d...
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
10:06 p.m.
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/d...
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
12:31 a.m.
----- 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/d...
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/arch
5:19 p.m.
----- Original Message -----
From: "Ayal Baron" <abaron(a)redhat.com>
To: "Dave Neary" <dneary(a)redhat.com>
Cc: "arch" <arch(a)ovirt.org>, board(a)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/d...
>
> 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
6:07 p.m.
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
7:15 p.m.
----- 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
7:54 p.m.
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
11:42 p.m.
----- 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
12:14 p.m.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/arch
12:39 p.m.
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
12:44 p.m.
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.
2:06 a.m.
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.
4273
days inactive
4279
days old
12 comments
6 participants
participants (6)
-
Ayal Baron -
Dave Neary -
Doron Fediuck -
Itamar Heim -
Mike Burns -
Moran Goldboim