Re: Discussion period: GR: DFSG violations in Lenny
On Tue, Nov 11, 2008 at 04:39:58PM +0100, Adeodato Simó wrote:
> you say you act out of alarm by
> seeing the release team take some decisions for the project. I claim
> that the Release Team is entitled to this decision, because our job is
> just copying bits of unstable/Packages.gz to testing/Packages.gz,
Yes, your job is only concerned about copying bits. Then again, what isn't?
GR 2006 / 007 was a collection of bits, too, but it allowed Etch to be
released with known DFSG violations.
Your job is also, I believe, sending an announcement message declaring that
Lenny has been released. That's also just bits, but it has the effect that
as project we would be declaring that a bunch of other bits are a stable
release of Debian. If you sum this up with another collection of bits
(the Social Contract), it turns out all these innocent bits mean we're
liing to our users.
> and
> the project should get its act together about unstable/Packages.gz.
Everything we do is significant. The Release Team is the last part of a chain
that would produce a release which doesn't comply with our own Social Contract.
The first part is the maintainers ignoring the problem indefinitely, with the
excuse that the technical requisites they expected haven't been met.
The second part is FTP masters not actively enforcing DFSG compliance for a
few selected packages.
The third and last part is the Release Team explicitly sanctioning all this,
when it is clearly beyond their powers to do so. This part is worse than the
rest, in that it requires explicit action rather than just inactivity, and in
that it has the worst consequence, as we would be telling the public: "here,
this is our finished work, it doesn't comply with what we promised, but who
cares".
But if what you're trying to say is that it's not all your fault as Release
Team, I acknowledge that. Then again, it's a really poor excuse to justify
missbehaviour because of pre-existing missbehaviour somewhere else.
> You
> don't share that view, and hence you come up with this proposal. Have
> you thought for a second, though, that the project as a whole could not
> agree with you in not sharing that view?
If the project as a whole determines that the Release Team is empowered to
make exceptions to SC #1 as they see fit, I would accept it [1].
I won't accept that the Release Team determines that on their own, without
the endorsement of the project, no matter what.
[1] I would also conclude that Debian is broken beyond repair, but that's just
my personal POV.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
Reply to: