Re: Development tree, PLEASE?

[Michael Loftis <mloftis@wgops.com>]

--On January 20, 2006 8:00:52 PM +0000 Russell King 
<rmk+lkml@arm.linux.org.uk> 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.