Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sat, Aug 05, 2006 at 11:29:44PM -0400, Nathanael Nerode wrote:
> I apologize for responding to Marco's post; in retrospect he was clearly
> trolling and I should not have responded to him.
>
> The point of my initial message was not to argue: it was that the etch
> timeline is unrealistic, because I see no progress on removing the
> substantial number of sourceless binaries from the Linux kernel source
> package, and it's *after* the kernel was supposed to have frozen!
>
> Is there a plan for dealing with this fast enough to avoid delaying the
> release of etch? If so, please post it.
Well, there is no way i see that we can deal with this in a timely fashion
without delaying etch by a year or so. Remember that d-i and kernel freeze
date was planned last week.
Furthermore, there is no evidence that future upstream version of the kernel
will not add more such non-free firmware, so this would be an ongoing process,
and we also have to keep in sync with the upstream efforts to do so.
As thus, i think the more reasonable way to handle this, is to not force this
to be solved for etch, but let etch be released as is (needs a GR though, but
not a 3:1 one), while at the same time start a coordinated process to solve
the issue, which would probably be something akin to a never ending work,
until upstream uses the no-non-free-firmware policy also.
<skipped nice plan to file bugs>
So, the real solution to this would be to setup a, maybe separate, team of
folk working on the non-free firmware issue, and proposing patches, patches
which have a chance to be merged upstream, to solve this issue. This could
overlap with the kernel team, or not, but the patches need to be approved by
the kernel team, and forwarded upstream. The kernel team as is should continue
focusing on packaging issues and normal maintenance.
Now, on how to go forward with this issue, i think the most reasonable way
would be for someone caring about the issue (you ?) to take ownership of the
wiki page (maybe saving the current content in another page), and start with
an exhaustive list, as well as analysis of each individual case. This would be
preferable to a bug filing tactic, which would just be lost in the huge load
of kernel bug reports anyway, and be more constructive. Maybe open a single
bug pointing to said wiki page or something.
Once that is done, the real work can start. Notice that the situation has
clearly improved upstream with relation to the patches you sent a couple of
year back, and which apparently somehow broke the drivers, so now would be a
good time to restart that effort.
Friendly,
Sven Luther
Reply to: