I've been asked to comment on this bug log, request which I'm more than happy to fulfill.
On Tue, Mar 08, 2011 at 09:20:42AM +0900, Charles Plessy wrote:
> I checked our Social Contract and Constitution, and did not find a
> special emphasis on the stable release. In particular, the
> Constitution defines developers as people producing packages or making
> useful work according to the Delegates in charge of the new members.
I'd dare to say that most of the processes that exist in Debian are
geared towards the existence of a stable release. Examples or that are
easy to find in Debian folklore: the testing distribution, as it is now,
it's tuned to support stable releases (that's why during freezes people
are kicked out of it a bit more aggressively than in other periods:
because no packages affected by RC bugs should be part of a stable
releases); similarly, the security team vetoes (or not) packages based
on the likelihood that they can be supported security-wise for the
lifetime of a stable release; we also have specific support teams, with
corresponding Debian Developer duties already mentioned in the
Developer's Reference, which are particularly focused on stable releases
(e.g. the Stable Release Managers). There are probably countless other
examples like these.
You're right in saying that there is no mention of all this in the SC
and in the Constitution, but there are lots of developer's "duties"
which are not part of those documents.
> We had the case two years ago that it was announced abruptly (but reversed
> later) that the next freeze would take place only 6 monthes after the release.
> We are a do-o-craty, and I think that it is important that following such
> decisions is an opt-in process, where developers who disagree can simply focus
> on other useful work instead of being bound to the new strategy.
Given that such a change was reverted, exactly because it was not to the
liking of many, how can you use that episode as an example? Isn't it an
example of the fact that developers recognize the authority of the
release team, while still retaining the constitutionally granted ability
of overruling their decisions if needed?
To conclude: I think that helping the release process is one of the duty
of Debian Developers. (I also have the impression this is a shared
feeling among Debian Developer, although I've no data that back that.)
As the release process is shepherded by the release team, collaborating
with the release team and supporting their choices is a way to support
the release process.
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
signature.asc
Description: Digital signature
