On Tue, Mar 16, 2010 at 09:56:56PM -0600, Gunnar Wolf wrote:
> Hmm, you got me thinking here on why this happened, as I share your
> impression. Maybe it was because the project as a whole put more care
> into the release process after the massive pain it was to release
> Sarge, a three-year-long pain we didn't want to suffer again? For
> Lenny we lost some of that push, although the release process was
> still mostly swift, with a minor slip regarding what we expected.
I do think this kind of analysis is a bit too simplistic to explain what
has happened. Our release cycles are long enough to encompass *a lot* of
factors that can impact on how "good" a release cycle is perceived to be
by DDs. For sure all of us experienced the pain of getting Sarge out,
but I don't believe that, as a consequence, our collective conscience
has risen up and got a better Etch release cycle.
FWIW, I haven't personally felt the Lenny release cycle to be worse than
the Etch one, both felt quite slick to my DD eyes.
> As for the reasons why we are not freezing yet... I think it is
> somewhat a lack of commitment to what the Release Team says, as (too)
> many people felt betrayed with the way the freeze-related
> announcements were made (a topic that has already been analized here).
I don't think the residual effects of the past-DebConf-flames had much
(cascade) effect on why we are not freezing yet. All in all the usual
reasons for not freezing are a too high RC bug count [1] and some
important work still to be completed (e.g. big transitions). If we are
not freezing yet, it is most likely do to those classical reasons, no
need to piggyback others, IMO.
> So, going back to the questioning of the candidates: Do you agree with
> this very simplistic analysis? If so, how would you push to get the
> drive and the confidence back?
Essentially, I believe I disagree with the analysis :-)
Ultimately, driving the release process is the specific role of the
release team, on which the DPL should not intervene directly. The help
that the DPL should contribute to the release team is of a different
nature: helping in staffing the team if/when needed, ensure that the
release team communicates periodically about the release status (by
prodding the team and/or helping them to send out status bits),
motivating developers to feel part of the release process. The above
items are not specific of any release cycle, it is just what I think it
should be a sane relationship between the DPL, the release team, and the
DD body.
Cheers.
[1] I've discussed in another thread how I think we need a cultural
shift on that, making it more distribute within the project. Of
course this is nothing specific to the current release cycle, but it
gets more and more important as our distro grows
--
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