Proposal: Reorganization of the Project Management

[Mike Burns]

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

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