--On January 20, 2006 8:00:52 PM +0000 Russell King
<[email protected]> wrote:
On Fri, Jan 20, 2006 at 12:21:40PM -0700, Michael Loftis wrote:
I think that it's fine to push the maintenance effort away from the
mainline developers, probably even desireable, but then the
bugfixing/etc tends to happen in a disparate manner, off on lots of
forks at different places without them making their way back to some
central place.
The responsibility for ensuring that those bugfixes get back to "some
central place" is with the folk who created the bugfixes.
I've seen this _far_ too many times - it's what I call "the CVS disease"
and it happens _a_ _lot_ in certain areas.
Developer X uses a CVS tree for his work and has write access to that
tree. He finds a bug, and fixes it. Maybe he writes a good explaination
of the bug and puts it in the CVS commit comments. He commits the fix.
When he's done with development, he walks away and the fix never gets
submitted. (Not everyone operates this way, but I know some do.)
As a mainline guy myself, I'll say we're all welcome to whatever bug
fixes come our way. We just need someone to send them to us with an
adequate explaination of the bug.
OK, my question though related to that is, where would they be included?
For most of my cases, latest development doesn't really help. I'd still
have to maintain a completely forked kernel. Would they be included or
eligible for the 4th digit releases you're talking about? But then that
seems that efforts might get really spread out across the many 3rd digit
releases, making that situation just as bad, or worse, as the previous
odd/even issues.
And that seems where we're going with this conversation. A fork/forks
at various versions to maintain bugfixes and support updates that's
(more?) open to submitters writing patches. Maintained by a separate
group or party, but with the 'blessing' from mainline to do so. A
place for those sorts of efforts to be focused, without necessarily
involving the primary developers.
Do you know about the bugfix-only kernel series, which have 4-digit
versions - 2.6.x.y - which is the compromise to satisfy folk with the
issue you're bringing up in this paragraph?
I don't see any maintenance releases on 2.6.8 edxcept one which addresses a
separate issue I ran into I don't see an updated e1000 in 2.6.8 (I'm not
sure where exactly this particlar e1000 gets supported Manuf ID is intel,
0x0108 is the device id...IIRC) but I'm pretty sure it's supported in
2.6.15, can't go much earlier than that because 2.6.9 and later seem to
have bugs with aic7xxx up until 2.6.14 or 15 (not clear here, I haven't
done enough testing, so basing that on input from others) as mentioned
though 2.6.8 also has buglets. I think 2.6.8.1 actually has a fix for the
NFS problem I forgot about in my slightly earlier reply to a separate part
of this thread, though I don't know if Debian has included that in their
2.6.8 kernels or not. Not even totally sure that's the issue I was seeing,
I'm still investigating that too.
I think the four digit bugfix only stuff is an excellent step, and
necessary. But the thing that I need more is stable APIs (both userland
and kernel, and at the kernel<->userland interface) *with* bugfixes and
(hopefully with) trivial hardware support update backports, like the
replacement e1000 driver. And I guess I shouldn't say 'I' need, but
colleagues need. And it's not just one company or one project or one
client/customer. And not all the issues are the same, but they come back
to needing somewhere that's kept 'dusted off' but not rearranged (too?)
regularly.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
