lkml.org 
[lkml]   [2006]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Development tree, PLEASE?


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


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-01-20 22:23    [W:0.031 / U:58.152 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site