Re: Amendment to the Constitution: Add a new foundation document
On Fri, Apr 30, 2004 at 05:40:11PM -0400, Joey Hess wrote:
> "Manoj Srivastava <srivasta@debian.org>Organization:srivasta"@debian.org wrote:
> > There is precedence for this gap in ratifying a foundation and
> > implementing the dictats of that document; as Joey Hess reminded me:
>
> I think that this document needs some serious editing before it is
> suitable as any official statement from the Debian project, let alone a
> foundation document. In particular, note the use of "me" above; I
> noticed other minor problems while reading it but do not have time for a
> thurough edit.
>
> I prefer not to have my name in any foundation document of the Debian
> project, as it could have unforseen consequences later.
This was exactly my feeling when skimming over it. I heartily welcome
the addition of such a document, but it should be completely neutral and
self-contained.
Manoy wrote:
> We affirm that whenever a change in the Social Contract takes place,
> the activities required to provide ongoing and proactive support for
> versions of Debian that have already been released shall continue in
> the period where we are working towards compliance. This includes,
> but is not necessarily limited to, providing security updates, bug
> fixes, preparing for the release of the next (compliant) release,
> adopting new packages, and making point releases to refresh already
> released versions of Debian.
> In the specific case of the GR 2004_003, since that current release,
> code named "Sarge", is very close to release, and the previously
> released version is quite out of date, our commitment to our users
> dictates that the "Sarge" release should go on as planned, even while
> we are trying to reach compliance with the Social Contract. This
> exemption for "Sarge" applies to security releases, and point releases
> as well.
I'd like to have some clarification here: The last change of the SC was
relatively uncontroversial WRT application to past releases except as
proof-of-point ('so we have to remove woody from the archive, too, I
guess, huh?'), while the prime part of the argueing was about the
effects on the forthcoming release.
The first paragraph above mainly talks about past releases and then
mentions the currently work-on release in passing ('preparing for the
next release...') and the second paragraphs specifically mentions Sarge.
Now, I believe there should be a turn-over point where we say the we
freeze a release WRT the Social Contract, much like we freeze it for
policy changes. Otherwise the current situation might come up again,
i.e. a change in the SC very late in the release cycle results in
turmoil. On the other hand, if the SC is changed just after a release,
it is reasonable to assume that we will be able to implement the changes
until the next release, so having a general 'The currently developped
release shall not be affected by the change' is not necessary.
However, it is very hard to determine and carve in stone the 'point of
no return' for a release, especially as we are still experimenting with
the way we do releases. But I guess we could have the release manager
officially declare a point somewhere in the middle of the release cycle
which marks the change from 'developping randomly' to 'working towards
the release'. At this point, changes to the SC would only be applied to
the next stable release after the one worked on by the time. This
declaration could be accompanied by the policy freeze or whatever other
the devices the RM will have at his fingertips at that time.
This would make it more reliable for everybody to judge the implications
of the changes, and lift off the burden of decision after a vote off the
shoulders of the Release Manager.
What do you all think of this?
Michael
--
Michael Banck
Debian Developer
mbanck@debian.org
http://www.advogato.org/person/mbanck/diary.html
Reply to: