On Tue, Oct 21 2008, Pierre Habouzit wrote:
> Though, when this software is central to all Debian (as the kernel is,
> or the glibc for the sunrpc issue, or mesa for the GLX code, or ...),
> then as it's a long and slow work to either prune the firmware, or deal
> with the copyright holders to relicense (and mesa has made it, proof
> that it's possible, but it needed like 2 or 3 releases of Debian to do
> so !), the Release team acknowledge that progress has been made, and
> tags the bugs $suite-ignore.
This is the part I am not comfortable with. I do not think the
delegates have the powers to decide when enough progress has been made
to violate a foundation document in our release. Just like an
individual developer does not have a right to decide to violate the
DFSG in their work, I think the release team, which prepares the
release, can do so unilaterally either (I did not vote for Bush).
This is why my contention has been that the developer body, as a
whole, has to be brought into the decision loop, like they have
for the last two releases, and make sure we, as a project, stand
behind the decision, not just a few hapless RMs.
So, I would like to see an option on the ballot that sates that
we will release Lenny with known DFSG violations, we believe in the SC,
but we also have to respect the needs of users, and we think progress
is being made towards ensuring that the needs of our users can be met
with free software in the future. I just do not think this is within
delegate or individual developer powers.
manoj
--
VMS must die!
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
