Re: RFC: what's in a stable series?

[Marcelo Tosatti <marcelo@conectiva.com.br>]

On Wed, 9 Jul 2003, Jeff Garzik wrote:

> Does it mean, no API changes except for security (or similarly severe) bugs?
> Does it mean, no userland ABI changes, but API changes affecting onto
> the kernel are ok?
> Does it mean, "just don't break things such that people are pissed off"?

My initial though on some new feature is to avoid it. We are a stable
release, after all.

The quota patches have been around for a long time, and Jan Kara has been
trying to include for sometime now (since 2.4.20/21). I tried to avoid it.

Now I realized the possible drawbacks of it are minimal (if any) compared
to the overall advantage it brings to Linux 2.4.

The same goes for ACPI, people have been trying to include it for a long
time, and I prefered to reject it until 2.4.22-pre.

Its a case-by-case problem.  You can't have a general rules like "no API
changes except for security (or similarly severe) bugs? Does it mean, no
userland ABI changes, but API changes affecting onto the kernel are ok?"

I reverted the direct IO patches because hch complained on me that they
change the direct IO API, and we really dont want that kind of
change, IMHO.

Trond/Christoph/you now have the direct_io2 possibility, which wouldnt
break the current API and still get us the desired "feature".

> I request the community's input, particularly those CC'd, for some sort
> of direction or consensus on this.
>
> In any case, I personally feel that increased stability of the API,
> coupled with the increased frequency of releases, will make the most
> people happy.  I would prefer some sort of 2.4.x API freeze, say
> post-2.4.22, but maybe that's too radical?

I also plan a 2.4.x API freeze. Maybe latter.

In general, I think each case is a case and has its tradeoffs which need
to be discussed and agreed on.