Donnie Berkholz wrote:
so next time dsd (or whoever the ninja kernel maintainer happens to be at the
time) says "hey i plan on stabilizing Linux x.y.z" and someone goes "wait,
you cant until we get <closed source driver package foo> working", the reply
is of course "blow it out your arse^H^H^H^Htalk to the package maintainer,
this will not hold up stabilization efforts"
If we're gonna go with this policy here, I'm also going to adopt it for
X so we don't get stuck in limbo as happened fairly recently.
This is how it has been for a while, and not only closed source drivers.
We have many open source kernel drivers/filesystems in the tree which
regularly break with new kernel releases. When these packages break in
this way, it is a bug in such packages, not in the kernel.
[For those wondering why the kernel keeps changing, see
Documentation/stable-api-nonsense.txt : it is by design, maintaining
kernel code outside of the kernel is discouraged for this reason,
solution is get it in the kernel]
Maintainers of these packages got unhappy that they didn't really have
warning when new kernels were going stable, so I started announcing that
(and usually giving more notice on gentoo-dev than this time around,
sorry about that). That helped, but trying to encourage maintainers to
fix their stuff every few weeks gets old and some maintainers become
less responsive. Kernels go stable anyway and so users complain.
I now take it a step further, and create package regression tracker bugs
for each kernel release. bug #184683 is the 2.6.22 one, a little smaller
than usual.
For each bug that gets added to the tracker, I comment on any patches
that have been posted (e.g. "that's the correct fix") or if there aren't
already patches, I explain how to fix the code based on the compile
error. This is work I'd rather not do (I really don't care about your
package), but seems to work relatively well.
There are times when after I 'approve' a patch, another developer asks
me to commit it. I think that's a little unreasonable. I'm not prepared
to go *that* far at the moment, especially as I usually can't test the
package in question.
The model seems to work relatively well. One associated challenge is
making sure maintainers fix their packages in the stable tree (not only
unstable) before stabilization takes place, but that has certainly been
improving lately, e.g. Stefan did a great job fixing up many external
wireless drivers this time around, and I didn't have to reopen any of
the bugs :)
All that aside, my advice for developers considering maintaining kernel
code in portage outside of the kernel still remains as "don't do it".
Your package grows bugs overnight. It's a continual challenge trying to
keep up, and it's a headache for me trying to poke you into action. Or,
if you really must do this, never mark your package stable (that way I
can ignore it).
Daniel
--
[EMAIL PROTECTED] mailing list
