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).

[EMAIL PROTECTED] mailing list

Reply via email to