Re: Results of the Lenny release GR
On Sun, Jan 11, 2009 at 11:35:22AM +0100, Joerg Jaspert wrote:
>
> >> > Do you have any other idea in mind?
> > Btw, Joerg, that goes for you too. If you have something constructive to say,
> > this would be a good time.
>
> How about you going elsewhere until Lenny is released, then coming back
> as soon as that happens and start working on what is left to fix then?
> (Not right before a release, right after a release for a change.)
We can talk about that, yes. I don't think right before a release is the
best time to go through all this mess, but alas we already started, and
believe it or not, it wasn't my choice. Please let me ellaborate.
I think the reason this happened is that although most of these bugs were
filed ages ago, nothing was done about them untill it became clear that the
Release Team planned to include them in Lenny without asking for an exception
(like happened for Sarge & Etch). All this could have been avoided if we
started talking about the bugs earlier (from a constructive POV rather than
just flaming), so let's talk about the bugs shall we?
The way I see it, there are 5 cathegories:
1- Firmware in Linux. We already made an exception for these. But it's not
clear what the maintainers plan to do after Lenny is released, and it's
not clear what the FTP team will do about it either.
2- Long-standing bugs in critical components for which a fix is expected to
arrive soon. This includes things like SunRPC, GLX, and even Nvidia
obfuscation (#383465). It's not unreasonable to expect the developers
would support an exception. Heck, maybe even I would. But none of this
_has happened yet_.
3- Non-bugs (IMHO), that'd be the trademark issue in #391935.
4- Bugs which are trivial to fix, such as #459705 (just remove a text file),
#483217 (only affects optional functionality that could be removed
according to the maintainer) or #509287 (just move afio to non-free).
Why isn't the FTP team enforcing these?
5- Bugs which aren't easy to fix. AFAICS this includes ONLY TWO of them:
#477060 and #498475 (aka #498476). Maybe it's worth making an exception
for them, but again this is something that should be judged by the
project as a whole.
This needs proper discussion IMHO. Maybe even a vote.
So, if you could tell me that there's going to be a proper solution for #1 and
#4, all that's left to do is have a vote to device what we do about #2 (which
almost certainly will be exempted) and #5 (which is likely to be exempted too).
OTOH, if you just tell me to "go elsewhere", I'm sorry but I don't want to
look the other way while the project destroys its reputation for having a
commitment to freedom, a democratic system and a set of principles.
--
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: