On Apr 14 Felipe Contreras wrote:
> On Sat, Apr 14, 2012 at 2:05 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
> > I don't think Stefan meant the above as tongue-in-cheek, for what it's
> > worth. Another stable kernel with different rules really would be an
> > interesting exercise, and would probably fulfill a need for a certain
> > audience.
> >
> > It's not like nobody does that already, anyway. For example, I hear
> > Fedora has a kernel that they maintain well for a different audience,
> > using different rules.
>
> Of course, although the difference with the stable kernel would be
> very small if the only thing added is an extra rule for acceptance:
> "It reverts an earlier
> patch to 'stable'."
It looks like a small difference on the surface, but it isn't. It would
mean "yes, we /do/ forward ports in -stable too in some cases".
In face of the frequent and predictable rate of mainline releases and the
very frequent stable releases, the problems associated with forward ports
very much appear to outweigh the benefits.
So the folks who do the actual work appear to be content with stable =
backports only, and it seems you can't convince them to do forward ports.
Which means that if you really want forward ports, you need to find
somebody else who does forward ports (e.g. a suitable distributor) or do
them yourself.
> But "we do this, and if you don't like it you can do whatever you
> want" is not a valid argument in favor of the status quo,
That would not be a valid argument, no. But it has been mentioned /why/
only backports are done in stable, i.e. what the problems with forward
ports are:
- First of all more work. (Could be compensated by longer periods
between stable releases, which would be an obvious downside too,
and actually defeat much of the purpose of the stable series of
getting out fixes to people.)
- Backports are already risky, which is why only /small/ backports are
allowed into stable. Forward ports bring their own set of risks.
Inevitably, users of the kernel called "stable" will get even
more reason to wonder why this series is not "stable" in a sense of
"absolutely free of regressions".
For example, merging subsystem development trees into the mainline is
actually a forward port. The mainline is at risk not only because
that subsystem tree hasn't had as much exposure to hardware and
workloads as the mainline will have, but additionally because the
merge result is different from the subsystem tree head. (The result
is a forward port.) Mainline development uses for example the
linux-next tree in order to reduce a subset of these forward porting
risks, those associated with conflicting developments in different
subsystems and cross-tree development. Which kinds of tools should
stable use if it were to accept forward ports?
So, rather than managing the risk of forward ports in stable, those
risks are systematically avoided by not ever doing forward ports, not
even small ones.
- The mainline would not immediately benefit from the work put into
forward ports in stable. Worse, fixes in those forward ports might
not ever make it into the mainline. That would be detrimental to all
mainline users, and thus to all stable users. (Stable users are
mainline users because stable is branched off of mainline every 2.5
months.)
These downsides have been mentioned in the thread; please consider them.
It is not about "we¹ do this because we are set in our ways". The stable
rules have pragmatic reasons which are for example founded on lessons
learned from the 2.4/2.5/2.6 history of development, maintenance, and
distribution.
So there are arguments for the status quo, the arguments have been
mentioned several times, and I can't see what would invalidate any of
these arguments.
--------
¹) Greg, if you are still reading this thread: Excuse the 'we', I do not
mean to speak for you.
Besides, Greg, thank you for the work. As a driver maintainer and when
supporting end users, I benefit from it since distributor kernels do not
deviate much from mainline these days, among else thanks to your stable
and longterm series. And it is an important way for me to get certain
driver fixes delivered to users conveniently and timely.
--
Stefan Richter
-=====-===-- -=-- -===-
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
