9:19 a.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