Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Tue, Aug 08, 2006 at 04:49:33PM -0700, Thomas Bushnell BSG wrote:
> Sven Luther <firstname.lastname@example.org> writes:
> > Well, it reads to me that we won't screw our users without second
> > thought like some here are proposing.
> In my opinion, we have been screwing our users for years by lying to
> them about whether their software was free. We would even say things
> like "hardware such-and-such is supportable with free software" and
> then ship them a non-free driver.
Well, its a different sort of screwing.
But then my position on this has always been to be clear, and say things
plainly as they are, and not like others or other distribs or upstream to
ignore the issue and hope it does go away.
At this point we have those possible choices :
1) move the kernel to non-free, and be done with it.
2) either move the individual affected drivers or just their firmware if
possible to non-free, and keep the cripled kernel in main.
3) reverse-engineer and reimplement those firmwares, or convince upstream to
4) pass a GR explaining the issue as is, and admitting our incapacity to fix
it with 2 or 3 due to lack of ressources.
3) would be nicest, but it is a never ending task, and we can't do it. We
could do 2), but even this will mean some serious work and possibly a delay of
the etch release schedule, especially as we don't have a full audit of what
files are exactly affected. 2) (and 1) also mean the cooperation of the d-i
team, which we have not been getting on this so far, all to the contrary,
since they need to fix d-i to load more than one apt source, and since the d-i
folk probably consider the etch d-i as frozen right now, ...
So, this leaves us what, as reasonable solution for etch ? 1 and 4, and 1 will
be too disruptive, so only 4 is left.
It is not as if the issue is new though, we have been knowing about this since
almost a year, and many voiced their concern or support at various time, but
actual help was few and far between (partly our fault in one case though at