Message-ID: <alpine.LNX.2.00.1307161124430.29788@pobox.suse.cz>
Date:	Tue, 16 Jul 2013 11:46:05 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	James Bottomley <James.Bottomley@...senPartnership.com>,
	Greg KH <greg@...ah.com>
Cc:	ksummit-2013-discuss@...ts.linuxfoundation.org,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [Ksummit-2013-discuss] KS Topic request: Handling the Stable
 kernel, let's dump the cc: stable tag

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@...cle.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists