Hi Carsten, just a few more comments on your mail which I haven't
covered in the separate "summary" mail I've just sent.
On Mon, Apr 04, 2011 at 08:38:18AM +0200, Carsten Hey wrote:
> We are in the good position to have a very experienced release team that
> is be able to decide whether testing is in a good condition to be
> frozen. It should also have option to adapt their time planing to the
> team's responses to "what are your plans for stable+1?" mails or to
> events that can't be known a few weeks after the prior stable release
> has happened.
I couldn't agree more, but TBH in setting a release scheme for the
future, I don't think we should make any assumption on the experience of
the release time. I believe the scheme should have its own merit, no
matter who will be called to put it into use. That would also have the
additional advantage of putting a bit less responsibility on the release
team (OK, just a little bit less, but it could make a difference on
whose who need to explicitly volunteer to take on their shoulders a
highly sensitive task).
That's also part of the reason why I don't think we should rely *only*
on "what are your plans for stable+1" mails. Those are of course very
good and I'm sure answers to those questions would help a lot the
release team anyhow. But at the same time if we could find a scheme
where a release period precise enough to enable DDs to define their own
roadmaps work "by default", without having to wait for specific human
intervention, I believe it would be better. Of course nothing will stop
the release team to make exceptions on the basis of those answers or on
the basis on any other factor they see fit, but seeing them as
exceptions would hopefully induce them, and the project as a whole, to
think twice about the consequences.
> This time frame could be rather imprecise at first and narrowed over
> time.
Fair enough, I've integrated this comment in an updated proposal.
(Although I've taken into account there several other comments of people
who proposed a specific threshold of 1 month to the imprecision.)
> This seems to be suboptimal (probably it's just your wording). The
> following quote from a mail sent by the release team in 2008 describes
> how it also has been handled for Squeeze:
> | Packages that are present in unstable the day we freeze will be
> | automatically allowed into testing, that is, the freeze date ... does
> | not mean your package should be in testing by then, but only in
> | unstable.
ACK-ed as well in my other mail, thanks to yours and other comments.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams
Attachment:
signature.asc
Description: Digital signature