Re: [Ksummit-2013-discuss] KS Topic request: Handling the Stable kernel, let's dump the cc: stable tag

Jiri Kosina
2013-07-16T09:46:05Z

On Tue, 16 Jul 2013, James Bottomley wrote:

> > But I need, from the distros, specific examples of what they object to.
> > So far all I've gotten is one security patch (that was needed), and one
> > patch for sysfs that I backported too far in the version numbers (my
> > fault.)
> >
> > Given the huge number of stable patches over the past few years, only
> > having 2 patches be an issue sounds like things are working well for
> > people here.
> >
> > If I don't get pushback, with specifics, from the distros, I will not
> > know what to change, so if people can provide me that, it will help out
> > a lot.
>
> I agree ... I think Jiďż˝ďż˝ and his Red Hat equivalent need to pipe up and
> give us more examples of the problems they've been having.

I am still continuing with my pushback against the /dev/random revamp that
happened in -stable; at least in the form it happened. I still strongly
believe it's something that's not a stable material. But that's happening
in parallel in a different thread already.

Okay, if you want another example:

commit a6aa749906b92eaec6ca0469f90f35de26044d90
Author: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Date: Thu Dec 20 15:05:14 2012 -0800

drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists

While this is a correct fix for major kernel release, as it achieves
correctness by checking SMBIOS version properly and behaving according to
the spec, it actually causes an userspace ABI regression in some sense, as
it just changes byte order of /sys/class/dmi/id/product_uuid on certain
systems.

Which is something I absolutely *do not* expect from a minor release of
branch which is called "stable".

As has been pointed out in other thread already, this all might be a
matter of taste; I am just trying to point out where the stable process is
failing for us.

> > > > I don't like this at all, just for the simple reason that it will push
> > > > the majority of the work of stable kernel development on to the
> > > > subsystem maintainers, who have enough work to do as it is.
> > >
> > > Well, I think of this as a feature not a bug because it enables scaling,
> > > but we can certainly debate the topic; it's probably one of the more
> > > important things that should be discussed.
> >
> > How does this scale? It makes the maintainers do more work, which does
> > not scale at all.
>
> We obviously have different ideas of what "scaling" means. Being a
> mathematician I think of a process were you review everything as o(1)
> and where the maintainers review everything as o(n). Since the number
> of patches (np) tends to grow as the number of maintainers, np/o(n) is
> an approximate constant meaning the amount of work per maintainer
> scales. np/o(1) grows.

Having a degree from mathematical insitute as well, I agree with James :)

On Mon, 15 Jul 2013, Greg KH wrote:

> I give maintainers 2 different chances to NAK a patch, and if they miss
> those, I can also easily revert a patch that got applied and do a new
> release, which I have done in the past.

This is exactly what I wanted to change with my proposal yesterday --
asking for NAKing of something that is already upstream is just "boring"
and going to be ignored by many people. That's reality, unfortunately.
It's basically a passive approval scenario.

If you completely push the burden out to maintainers, to have them prepare
the branch and send it to you for pulling, that requires an *active*
action from them, which means much more thinking about what code is going
into the branch.

It could mean that less code will be going to stable, yes. But it will be
documented *why* it's going there (in the pull request), there will be
clearly someone responsible for it (the person who conducted the pull
request) and the changes will have much higher chances to be reviewed in
terms of applicability to -stable.

Oh, and I need to add: I am not pushing against you personally or the
stable branch in general, at all. We are heavy users of -stable releases
of course, and it saves us a lot of work. I am just trying to figure out
ways how to avoid another lot of extra work on our side when change that
shouldn't be pulled into stable lands in our tree through it. Once that
happens, it causes us quite some headache, as we are implicitly relying on
stable to actually be "stable", in our understanting of the word :)

Thanks,

--
Jiri Kosina
SUSE Labs