On Thu, Oct 23, 2008 at 06:32:51PM +0200, martin f krafft wrote: > It's all a matter of defining what your priorities are, which brings > us back to the Social Contract, which says that these include:
> - 100% freeness > - cater best to the interests of our users > Note that it does not say: release regularly, or on time. This may > well be interpreted to be part of the second of the aforementioned > priorities, but it's not explicitly so. Except you're paraphrasing here. What the Social Contract actually says is: 1. Debian will remain 100% free We provide the guidelines that we use to determine if a work is "free" in the document entitled "The Debian Free Software Guidelines". We promise that the Debian system and all its components will be free according to these guidelines. We will support people who create or use both free and non-free works on Debian. We will never make the system require the use of a non-free component. So if we're promising that Debian will *remain* 100% free, then we already broke that promise - depending on your POV, either we broke it when we allowed the first piece of sourceless firmware or the first piece of GNU documentation into the archive, or we broke it when we changed the scope of "free" in the Social Contract. It is not the release team that has broken this promise; it is Debian as a whole. While the release team /could/ use their authority to decide to block the lenny release until all known firmware issues are resolved, or until the kernel has had a full license audit by a party of Robert Millan's choosing, do you think that will beneficially affect the point at which we have a Debian release that's free of kernel licensing problems, instead of just negatively impacting the utility of Debian to our users due to the open-ended delays of the lenny release? Bear in mind that the current round of firmware bugs that have stirred up such a ruckus are all bugs that have been discovered and filed within the past three months - whereas the firmware bugs that were knowingly given exceptions for etch have all been resolved. > We've released sarge bundled with an excuse. We've agreed > that these amendments, which have already been ratified by the > Debian Project, will be reinstated immediately after the release > of the next stable version of Debian, without further cause for > deliberation. > -- http://www.debian.org/vote/2004/vote_004 > We've released etch without an excuse for failing to comply to our > own rules. > Are we just going to continue down this road? The road we're continuing down is one of incremental *improvement* of Debian's compliance with the current Social Contract. We waived the requirement for DFSG-compliant documentation for sarge, and resolved that for etch; we waived the requirement for firmware in main to be accompanied by source (http://www.debian.org/vote/2006/vote_007) for etch, and have subsequently fixed, for lenny, the firmware source issues that we knew about when etch was released. In between the once-a-release-cycle mailing list rants from developers who aren't willing to do the hard work of ensuring users can *use* the release on their systems, there's real progress being made. (We've even managed to see bug #368560 resolved for lenny, a software licensing bug that predates any of the rest of this which, to my chagrin, was reported as a bug that "little was done about" in spite of efforts by multiple Debian developers over the years to discuss this with SGI.) I don't see the point in delaying releases on the grounds that we haven't yet reached the end of that road. I especially don't think it's a good plan to treat difficult-to-resolve DFSG bugs as blockers for the release when these bugs have only been brought to our attention after we're in freeze for the release. Why is "release" a better cut-off for these bugs than "freeze", anyway? OTOH, I do understand the desire to put such (diminishing) exceptions to a referendum instead of leaving them implicit, and am happy to vote for a GR that makes clear to our users the state of affairs in lenny. I also encourage the kernel team to pursue the patches that Ben Hutchings has so wonderfully provided for this latest round of bugs. They need to be weighed against the risk of regression, but they should still be considered for inclusion in lenny. Kudos to those who are actually doing the legwork to fix the bugs. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
