Re: Preparing linux-2.6 2.6.18-1
On Sun, Sep 24, 2006 at 01:08:10PM -0400, Nathanael Nerode wrote:
> Sven Luther wrote:
> > On Fri, Sep 22, 2006 at 03:25:12AM -0700, Steve Langasek wrote:
> >> On Fri, Sep 22, 2006 at 07:12:53AM +0200, Sven Luther wrote:
> (someone, I'm not sure who, wrote:)
> >> > > Re-adding them at this stage
> >> > > 1) is against the current social contract
> >> > Yes, but then so is shipping the firmware actually still in main,
> >> So two bugs is better than one?
> > Yes, because re-adding the drivers which used to be pruned, allow a
> > category of users to install, which they did not previously. Thus, your
> > arithmetic is wrong, because you don't count the "can't install" bug, and
> > if you do, it sorts out evenly, especially if you take in account that we
> > put non-free software and users equally in the SC.
> "Our users" cuts both ways. There are users who use Debian *because* the
> contents of main are (supposed to be) 100% free. I'm one. The two users
So, nobody is forcing you to use those non-free drivers ?
Really, these are something like 5-6 drivers involved, among them the acenic
one, and the keyspan usb ones, and a couple of other i don't remember.
> complaining of Debian's "hypocrisy" on debian-legal recently are two more.
Well, here there is no such hypocricy, because we are well aware of the
problem, we mentioned it clearly enough in the GR we are proposing, and we
engage ourselves to solve the issue for etch+1.
> Undoubtedly there are others, probably including many DDs. Those users are
> being mistreated in order to benefit some other users.
They are welcome to provide patches :) Well, good quality patches that is.
The reality is not that the kernel team don't want those firmware in main, but
that in the current state of the debian technology, it is not feasible to do
it right, and it will take time, and will be best done during the etch+1
> (In some cases, nonexistent users. drivers/net/dgrs "was killed in place
> and never reached the market". No users were impacted by removing this
> driver, and we know that for a fact. Why readd it?)
Because it is a pain to remove them ? I am not familiar with all those stuffs,
but i suppose that a firmware for which there is no hardware available on
which it can run can be accounted as pure useless data or something.
> Meanwhile, "Debian will remain 100% free" doesn't really leave much room for
> argument. "Our users" is a priority, as is "free software", but "Debian
> will remain 100% free" is a *promise*.
Sure, and we deplore it cannot be fullfilled for etch, but we will do our
best, for etch+1.
> > Indeed, but then you also need to backport all the fixes that the kernel
> > team will put in 2.6.18 to 2.6.17, fine sharing of effort. Did you not
> > read Frederik's GR, where the kernel team states that kernel dev
> > ressources are rare, which is why we request a waival of the requirement
> > for etch, in order to be able to work on this issue in peace for etch+1,
> To be honest, if the release team was clearly making progress on removing
> the non-free firmware, you'd be a *lot* more likely to get a waiver.
Upstream is making progress, see the qlogic firmware for example, and the
debian kernel team, which is the one who will be making this work, not the
release team, has a strict policy of following upstream closely, in part
because we don't have the ressources and work-force to maintain a huge set of
> A good start would be the tg3 patches. Reintroducing the dgrs driver,
> which drives *no existing hardware at all*, would be a very bad move.
So, you dismiss the qlogic firmware out of hand ? tg3 may follow, if there is
a good enough patch to do it nicely. This may come, either from someone like
you (but the patch has to be upstream-quality, which apparently your patch was
not), or from the kernel team. tg3 is not the only case of such though, is it
emblematic to you because you provided a patch when Herbert was still around ?
Also, i have many time asked for help on working on Larry's list, and find out
the copyright holders of those files, and continue to fine-tune the analysis
he has done, but upto now, nobody gave any indication that they are ready to
help in this regard, and this includes you. So, what are you going to do to
help us make sure the non-free firmware finds an adequate solution for etch+1 ?
> Today I sent an email asking upstream to remove dgrs based on its
> uselessness; we'll see what happens.
> > without having to deal with the two new GRs a week over highly emotional
> > issues, not mentioning the remaining bullshit that is going on beside it
> > (RM payement,
> > duck stuff,
> Duck stuff? Quack, Quack? <looks confused>
dunc-tank, which some guys mispelled duck-tank (or dung-tank too), having no
idea what dunc is, i find the duck term more easy to remember.
> I have a wild turkey living in my front yard, but no ducks.