tbm's Release Management talk

Thanks to Romain Francoise, I found and watched Martin Michlmayr’s Release Management in Large Free Software Projects talk on Google Video’s Open Source Speaker series. Martin: Thanks a lot, great talk. I’ve been following your presentations lately, as I’ve given some talks on this topic - Quality Assurance on Free Software Projects (Spanish only) - However hard I try to remain faithful to the subject, I end up giving a talk on what Free Software is and how its processes are naturally more prone to yielding better quality than propietary projects.
Anyhow, with this post I want to do basically three things: <ul><li>To cheer Martin for writing and presenting the topic. I’ve been refering to your work for a long time, and although my presentations are not formally papers and thus have no quotation value (in fact, they often don’t have the references as anything more than comments in the source files, it at all), I should thank you frontally and publicly.</li><li>To get some more attention to the topics presented. Your point is very interesting and important to be taken into account specifically for Debian: I’m not 100% with you regarding that time-based releases is the way to go, but the point you make when discussing GCC (IMHO) is an important one: A project can shift to time-based releases even if it does not release on time, and its general inner processes can become quite cleaner. I do think we witnessed this with Etch in Debian - The process was much more believable and peaceful (even with all the release-related mudfights) than with Sarge. I think it partly stems from what you point out: We aimed to release in December, and we failed to precisely meet the target - but having the date helped set the release goals to something believable, and not let Sid’s unstability drift too far away. During Sarge’s testing cycle, for a long time, few of us even cared to use testing at all, as it was… Something completely undefined.</li><li>To get some insight on some points. Martin, in several of the projects you analyzed, there is a tendency to get to a six months release cycle. Many other projects also follow that cycle - There is a time-based project you didn’t mention that is to me one of the inspirations of such model, and has proven to work for over a decade: OpenBSD. Yes, it lacks in many areas, and definitively not everybody can aspire to become an OBSD developer, but they have done high-quality six-month releases since they exist. However, speaking specifically for Debian: Would you like our project to follow such a schedule? For many reasons (including one you mentioned, the difficulty to support several concurrent versions, or just having oldstable versions be left too early with no support) I think we should aim for a 18 month cycle, 12 at the very least. Either I lacked attention when you went over that part or you didn’t mention it - but why do you think such a short cycle is good for so many projects? What would you like Debian to do? (Of course, for answering this, you might be Martin, or somebody else entirely ;-) )</li></ul>

Comments

garaged 2007-04-26 05:29:53

Re: tbm’s Release Management talk

Not having any good background as a project planing, I would say that setting 6 month (12 at max) would give some minimal support for important (or fast changing) applications that would really benefit to the final user.

I don’t think it would be a good idea to have the ability to install mysql 5.x, beryl 0.2, apache2.2, etc 1 year or more later that its release, and maintaner teams should be worried about getting fast releases, if unstable doesn’t probe the package good enough, it will never pass to testing, but I think the critical path for a package (from its oficial release to the introduction on debian stable) should almost never cross the 6 month figure, unless the package is really obscure.

Let’s take a look at snort on debian, we have 2.3 ! on unstable, I have tested 2.6 and 2.7 for months, I have even made really rough packages, but nobody seems to care on updating it on debian :(, snort is pretty popular, and important, specially recent versions that implement snort_inline’s features. I think deadlines are stressful, but they could help notice the need for more people on a particular project, and they would allow to make predictable assumpsions about de availability of some packages.