[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

DFSG-violations and NEW and DFSG-violations and I would fix them, but...

Raphael Hertzog wrote:
> Every kernel upload changing the ABI goes through NEW.

The typical situation here is that code that has the same set of DFSG
bugs is already in place and so it is questionable of what a reject
really achieves (i.e. does the archive become more DFSG-compliant or
not) and quite typically fixes some RC bugs (not always trashing
people's hardware). Sure, the ftp team can make this into a stand-off,
but the situation is much less clear than e.g. when the ftp team had
openjdk-6 in NEW, which had its (known or discovered during the vetting)
DFSG problems fixed rather fast and before it entered the archive in
first place, thanks to the maintainer (Matthias) willing to get the bugs
fixed and thanks to a cooperative upstream.

So let's evaluate options other than rejecting:
As for the suggestions to move linux-2.6 to non-free (which, again,
would have required someone to upload that): The ftp team usually are
pretty ruthless about pulling stuff from main with problems if it
doesn't get fixed fast, but in the case of the kernel and glibc the
Social Contract's
  We will never make the system require the use of a non-free component.
puts a limit on what can be done: Aside from the additional work it
would cause to everyone (installer, ...) and the undesirable effect of
effectively forcing people to add non-free, moving stuff required for
running Debian into non-free seems shady from a Social Contract point of
Note how the situation would be vastly different if we had a known-good
kernel package was somewhere in the archive (be it testing or unstable).

And about the options of fixing it or just insulting other people to fix
it I should note that the objection that finding a widely welcomed fix
involves work (on blob loaders) that someone interested in a free kernel
has no intrinsic motivation to do: A lot of tasks do that. I want a
release and when I ask the release team, they tell me to fix RC bugs in
stuff I personally don't care about one single bit. I don't get to yell
at the release team for that (though I do at the maintainers of RC buggy
packages possibly more than I should), but have the choice of working on
stuff or not. Claiming that "I want a release now and we could just
release, all the RC bugs are in packages I have no interest in" would be
openly preposterous and in the case of "I would work on freeing the
kernel of but finding something to make everyone happy involves making
the firmware loadable in non-free" thinly disguises the same sentiment
of "I'm not going to help unless it's 100% my way" in the disguise of a
taking a higher moral stance than everyone else. "Moral, das ist, wenn
man moralisch ist, versteht Er."

Kind regards

Thomas Viehmann, http://thomas.viehmann.net/

Reply to: