Re: Announce: Linux-next (Or Andrew's dream :-))

Linus Torvalds
2008-02-14T18:03:20Z

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.

If we have a big flag-day that affects a lot of drivers (or architectures)
once or twice a year, I think everybody involved will be happy to stand up
and say "ok, that fixes problem X, and the new thing really is better, so
let's do it, it's worth it".

But if it's something that happens essentially every single release, that
is somethign else altogether. Then it's not a "ok, let's bite the bullet
and make the kernel better" thing any more, but instead it devolves into
"f*ck, the merge window is open again, now I have to fix up all the crap
people pushed on me".

See? That's a *huge* difference, even if it is "only" a mental one (and
clearly it isn't - there's the actual real work of the "I have to fix
things up" part too).

So to recap: I have absolutely nothing against fixing up bad internal
API's and breaking things. But 99% of the time that should be something we
can do incrementally (ie introduce the new API, and simply accept the
fact that removing the old API will take a few months). And the case when
that _really_ doesn't work should be rare enough that it doesn't wear
people down.

Because if you listen to the tone of people in this discussion, much of it
is about people being _tired_ of having to fix things up. It's not exactly
been a "wow, the end result sure was nice!" kind of discussion, is it?

And this is where "process" really matters. Making sure people don't get
too frustrated about the constant grind.

> However,
> I see an argument for attempting to stabilise possible conflicting
> changes get Linus' review/ack and add them to the stable branch.
>
> Linus suggested that such changes should go into an independent tree that
> everyone could pull into their trees with the full confidence that that
> tree would be merged into Linus' tree when the merge window opens. I am
> suggesting that that tree be the stable branch of linux-next.

I absolutely have no problem with having a "this is the infrastrcture
changes that will go into the next release". In fact, I can even
*maintain* such a branch.

I've not wanted to open up a second branch for "this is for next release",
because quite frankly, one of the other problems we have is that people
already spend way too much time on the next release compared to just
looking at regressions in the current one. But especially if we're talking
about _purely_ API changes etc infrastructure, I could certainly do a
"next" branch.

Linus