Proposal: Reorganization of the Project Management

Mon Mar 11 14:19:31 UTC 2013

----- Original Message -----
> From: "Ayal Baron" <abaron at redhat.com>
> To: "Dave Neary" <dneary at redhat.com>
> Cc: "arch" <arch at ovirt.org>, board at 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/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.
> > 
> 
> +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