----- Original Message ----- > From: "Ayal Baron" <[email protected]> > To: "Dave Neary" <[email protected]> > Cc: "arch" <[email protected]>, [email protected] > 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 _______________________________________________ Board mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/board
