[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Question for all candidates: Release process

On Sun, Mar 14, 2010 at 02:44:15PM -0700, Russ Allbery wrote:
> Releasing is regularly the hardest thing that Debian does, not just
> technically but also socially.

To some extent, I believe it is normal. Releases are our main
"products", they define our purpose. The people which are putting their
names in driving the release process, i.e. the members of the release
team, are very tightly bound to the release process. The closer we get
to a release, the closer they might feel pressure, which sometimes has
unfortunate consequences.

My impression is that most impromptu resignations in Debian happen as a
consequence of some form of burn-out, which are unfortunately not
uncommon in volunteer FOSS projects. I don't believe the release team
constitutes an exception to this unfortunate rule.

A general cure to this is to avoid people taking over their shoulders
more responsibility than they can handle. I was very positively
impressed when Steve McIntyre's team review of two years ago found out
people involved in an incredibly high number of Debian teams and
actually incouraged those people to step back from some of them. We
should encourage DDs to periodically review their involvements and focus
their energies on a few specific areas. Being a member of the release
team, or even the release manager is, again, no special case.  As it is
hard to actively state "I step back", we should also more frequently do
(self-)appointments with an attached "expiry date", when the date
expires the involved people can "snooze" it actively or just let others
know that it is time for them to move on to Debian activities which are
more fun for them.

> Do you have any thoughts about how to resolve release issues with less
> hurt and negative impact to the project all around?

On one hand, I believe that the pressure on, and even some personal
conflicts with, the release team could have been much lower in the past
(generally, not necessarily only in this last release process) with a
bit more communication with project. As a DPL, I would generally prod
the release team for periodic status reports (at least monthly) which
are much needed, considering the peculiar role of the release process in
Debian. If prodding is not enough, the DPL can also take care of the
communication him/herself.

On the other hand, I think the release team has felt in the past more
than a bit of frustration, due to the apparent disinterest of DDs in
getting a release done. I particularly remember during DebConf8 (Lenny
release cycle) a deserted BSP which was largely perceived as lack of
interest in getting the RC bugs count down. That is just an example and
maybe not even the most appropriate one [1], but the problem exists:
beside maintainers that don't care about fixing RC bugs in their
packages, not so many people care about helping in releasing Debian, by
working on packages other than theirs. That can easily make the release
team feel "alone against the release", which is surely not a productive
context to work in.

Ultimately, I believe this is a cultural problem that will take us quite
some time to fix. I'm aware of various initiatives in the right

- use the NM process to coach newbies about the importance of fixing
  packages other than theirs (we already request to provide RC bug
  patches during T&S). I personally had very good responses on this from
  a couple of NMs which started patching and/or NMU-ing RC-buggy
  packages with (proper) patches just after becoming DDs

- more generally, diminish strong package ownership by communicating
  that contributions like NMUs are good, as long as they are done
  following the rules (initiatives like RCBW and its predecessors
  attracted quite a lot of "minions", for instance)

The ideal bottom line of this is that, if the DD body starts feeling
more part of the release process (rather than only thinking at their own
pet packages), then DDs will more and more stand on the side of the
release team, rather than against it.


[1] one can argue that a DebConf should better be used in other ways, etc

Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime

Attachment: signature.asc
Description: Digital signature

Reply to: