On Fri, Apr 30, 2004 at 05:40:11PM -0400, Joey Hess wrote: > "Manoj Srivastava <[EMAIL PROTECTED]>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 [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]