Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Wed, Aug 09, 2006 at 12:57:36AM -0700, Thomas Bushnell BSG wrote:
> Sven Luther <sven.luther@wanadoo.fr> writes:
>
> > 2) either move the individual affected drivers or just their firmware if
> > possible to non-free, and keep the cripled kernel in main.
>
> This is certainly the last resort, in my opinion, but it isn't
> "crippled". Merely not supporting particular pieces of hardware, in a
> world in which Linux *already* fails to support lots of popular
> hardware, is not a disaster. It's a shame, and we should avoid it if
> we can, but it's a shame.
>
> > 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.
>
> Life is rough. The kernel team has had *ample* warning, since it was
> midway through *sarge* that the rules became clear.
Nope, the issue only surfaced early after the sarge release, a bit less than a
year ago, when the new kernel team formed.
Now, this is a long term *UPSTREAM* kind of work, and we simply don't have the
ressources of undertaking it.
As for me, i have been bogged down into defending against the multiple
tentatives to get ride of me since early marsh, and could thus produce no
useful work of this nature during this time, Andres Salomon left because his
tentative of exclusion of me from debian failed, others have been assortedly
busy too.
And it is not as if *YOU* had not ample warning about the ressource problems,
since we mentioned the lack of manpower and ressources regularly since a
almost as long as the issue surfaced. And this is not really a work which can
be done without diverting ressources from normal maintenance work, which would
be detrimental.
So, basically, you are criticizing the kernel team for not having devoted
enough of their *volunteer* time to this issue, and at the same time you
expect us to provide good quality kernel packages to debian ?
Well, again, the offer is open, and i already multiple times proposed those
like you to start helping and providing an exhaustive list of those files
which are involved, as well as a basic classification of the nature of their
problem. This is assuredly within the reach of each debian maintainer or
associated, and doesn't need any particular kernel-coding skill, but some
legal/licencing knowledge.
Friendly,
Sven Luther
Reply to: