lkml.org 
[lkml]   [2008]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Announce: Linux-next (Or Andrew's dream :-))

    * Linus Torvalds <torvalds@linux-foundation.org> wrote:

    > On Thu, 14 Feb 2008, Stephen Rothwell wrote:
    > >
    > > Originally, I assumed the stable branch would be for our "usual" API
    > > changes, but it appears we are not having any more of those. :-)
    >
    > It's not that we should _never_ have them, it's that they shouldn't be
    > "business as usual".
    >
    > I'm happy with them being a "a couple of times a year". I'm not happy
    > with them being "once or twice for every release cycle". That's the
    > big deal for me.

    very much agreed. I've yet to see a _single_ wide-scale API change that
    broke stuff left and right where that breakage was technically
    justified. I have not seen a single one.

    All those cases were just plain old botched attempts. Either someone can
    do a large-scale API change like the irq_regs() cleanups with near-zero
    breakages, or someone cannot. In the latter case, gradual introduction
    and trickling it through subsystem trees is a _must_.

    and if it's _hard_ to do a particular large-scale change, then i think
    the right answer is to _not do it_ in a large-scale way, but do it
    gradually.

    I claim that there's just not a single valid case of doing wide-scale
    changes atomically and departing from the current to-be-stabilized
    kernel tree materially. _Every_ large-scale API change can be done in a
    staged way, with each subsystem adopting to the change at their own
    pace, it just has to be planned well and tested well enough and has to
    be executed persistently. And the moment we trickle things through
    subsystem trees, there's no integration pain, as subsystem trees are
    largely disjunct anyway.

    i also fear that having an API-changes-only tree will dillute our
    testing effort of the current to-be-stabilized upstream tree, as it
    materially disrupts the flow of patches. Most maintainers should
    concentrate on stabilizing current -git with only one serial queue of
    fixes and enhancements ontop of that tree. I dont see how having a
    second queue would help - it clearly splits attention.

    widescale API changes should be discouraged, and forcing them through
    the harder, "gradual, per subsystem" route is _exactly_ such a strong
    force that discourages people from doing them.

    Ingo


    \
     
     \ /
      Last update: 2008-02-15 02:15    [W:0.033 / U:31.544 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site