Proposal: Reorganization of the Project Management

[Dave Neary]

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/discussion

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