RE: RFD: Kernel release numbering

From: Linus Torvalds (torvalds_at_osdl.org)
Date: 03/03/05

  • Next message: Chris Wright: "Re: 2.6.11-rc5-mm1" 
    Date:	Thu, 3 Mar 2005 11:11:05 -0800 (PST)
To: Hua Zhong <hzhong@cisco.com>

    On Thu, 3 Mar 2005, Hua Zhong wrote:
    >
    > Do you consider having a real stable release maintainer again?

    No, this really is a different thing.

    This is not a "truly separate" parallell track, exactly because it would
    not actually get a life of its own. For it to make sense, it would not do
    any big changes, ie it would be _limited_ in a way that a real stable
    release would not. Also, since it would leave the old kernel behind when a
    new stable release comes along, it would not have any real independence in
    time either.

    Now, I think this "sucker tree" I'm talking about would be a great basis
    for somebody else then taking it _further_ (ie vendor stable trees), but
    it really is a fairly small step.

    > If you want someone to do the job, give him a title. It's a thankless and
    > boring job, and you can't make it worse by just hiding him somewhere.

    Actually, that was something I'd _avoid_ - make it non-glorious on
    purpose. In the kind of tree I envision, the _last_ thing we'd want is the
    maintainer looking at a big picture and feeling important. I'd be happiest
    if he was almost totally anonymous, because I think it's likely a boring
    job, but it's a boring job that _many_ people could do (ie to avoid
    burnign people out, make it be a stint of a couple of months, not a
    "crowning life work", and then you could probably have half a dozen people
    who are perfectly willing to take it on every once in a while.

    Ie I'd organize it like some of the "checkin committees" work for other
    projects that have nowhere _near_ as much work going on as Linux has. That
    seems to work well for small projects - and we can try to keep this
    "small" exactly by having the strict rules in place that would mean that
    99% of all patches wouldn't even be a consideration.

    In other words, I'm really talking about something different from what you
    seem to envision. I think we should call the tree the "sucker tree", and
    if somebody wants to make a logo for it, make it be a penguin with a
    jokers' hat: exactly to remind people that it's not about the glory.

    (Maybe that's going overboard a bit ;)

                    Linus
    -
    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/

  • Next message: Chris Wright: "Re: 2.6.11-rc5-mm1"

    Relevant Pages

    • Lets make a small change to the process
      ... Both Andrew and Linus are doing an impressive job so I really don't ... We, of course, need a maintainer for it, ... fixes to his tree), maybe someone else... ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: -mm merge plans for 2.6.21
      ... If the subsystem tree maintainer wants to tell me "I can't be bothered ... or unless the maintainer is vacationing or totally ... queued-up arch patches and will merge it after the arch trees have gone in. ...
      (Linux-Kernel)
    • Re: Adrian Bunk is now taking over the 2.6.16-stable branch
      ... No user is forced to follow a particular maintainer. ... up and declare that they are also offering a maintained tree. ... Once those users depend on this kernel, ... back when they'll find a bug. ...
      (Linux-Kernel)
    • Re: [PATCH] doc: add suggestions about good practises for maintainers
      ... merging or back-porting when you're a maintainer. ... +exactly the same in your tree and the submitters'. ... +and protect the submitter from complaints. ... It seems to be a common and useful practise ...
      (Linux-Kernel)
    • Re: [PATCH] Fix VIDIOCGAP corruption in ivtv
      ... I sign the patch, because I have handled it in my -stable queue. ... The authorwill send this to a driver maintainer, that will send to a subsystem maintainer, etc, until reach mainstream. ... You didn't wrote the patch, not forwarded it to me, so, the tag doesn't apply on my tree. ...
      (Linux-Kernel)