lkml.org 
[lkml]   [2016]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH] doc: change the way how the stable backport is requested
    On Mon 05-12-16 15:43:59, Greg KH wrote:
    > On Mon, Dec 05, 2016 at 03:39:15PM +0100, Michal Hocko wrote:
    > > On Mon 05-12-16 15:21:37, Greg KH wrote:
    > > > On Mon, Dec 05, 2016 at 03:14:51PM +0100, Michal Hocko wrote:
    > > > > On Mon 05-12-16 14:58:24, Greg KH wrote:
    > > > > > On Mon, Dec 05, 2016 at 02:05:08PM +0100, Michal Hocko wrote:
    > > > > > > On Mon 05-12-16 13:52:36, Greg KH wrote:
    > > > > > > > On Mon, Dec 05, 2016 at 08:21:54AM +0100, Michal Hocko wrote:
    > > > > > > > > From: Michal Hocko <mhocko@suse.com>
    > > > > > > > >
    > > > > > > > > Currently if a patch should aim a stable tree backport one should add
    > > > > > > > >
    > > > > > > > > Cc: stable@vger.kernel.org # $version
    > > > > > > > >
    > > > > > > > > to the s-o-b block. This has two major disadvantages a) it spams the
    > > > > > > > > stable mailing list with patches which are just discussed and not merged
    > > > > > > > > yet
    > > > > > > >
    > > > > > > > That's not a problem in that I know I like to see them to give me a
    > > > > > > > "heads up" that something is coming down the pipeline soon.
    > > > > > >
    > > > > > > Are you really tracking all those discussion to catch resulting patches
    > > > > > > in the Linus' tree? I simply fail to see a point having N versions of
    > > > > > > the patch on the stable mailing list before it gets picked up from the
    > > > > > > _Linus'_ anyayw.
    > > > > >
    > > > > > I do scan them, sometimes I even find problems with them (like a zram
    > > > > > "fix" that went by this weekend.) So yes, it is always good to have
    > > > > > more reviewers on patches, don't you think?
    > > > >
    > > > > Yes I do agree that more review is better. But then the stable mailing
    > > > > list is a complete failure in that resopect - at least for me. Why?
    > > > > Simply because it doesn't contain discussion for the stable inclusion
    > > > > but rather something that eventually might happen to become stable
    > > > > material. This what I call noise and the reason why I've stopped
    > > > > following the stable ML.
    > > >
    > > > That doesn't make sense, I want to see patches that are being proposed
    > > > for the stable kernels _before_ they get into the maintainers and
    > > > Linus's tree, as then, it is almost always too late.
    > >
    > > Too late for what? I am still not sure I see your point. Are you
    > > suggesting that a review from the stable mailing list, which wouldn't
    > > be a part of a standard review process normally, has helped to identify
    > > issues?
    >
    > Sometimes, yes, this happens.

    It is really hard to argue here... But effectivelly something is really
    broken when wrong/unsuitable patches marked for stable pass the maintainer.

    > > > I will point out the zram patch this weekend as an example of that,
    > > > where if the original had gone in, it would be a while before the
    > > > "fixup" would have then gone in, and the abi deprecation would probably
    > > > have missed 4.11 entirely.
    > >
    > > I do not have a full context here. Do you have a pointer please?
    >
    > A patch for the zram subsystem was cc: stable this weekend and I pointed
    > out problems with it and the user/kernel api that it was modifying. I
    > would have never seen this patch otherwise.

    I guess you are talking about https://lkml.org/lkml/2016/12/3/257? If
    yes then the patch hasn't even been taken by Andrew so I am wondering
    why do mention it as a hand break coming from the stable tree.

    > > > Don't you want to catch things earlier rather than later?
    > >
    > > Sure, but I fail to see the role of the stable ML in this area. I might
    > > be underastimating its role of course.
    >
    > I think you are :)
    >
    > Seeing the patches sent to the list _before_ they end up in a
    > maintainers tree, or Linus's tree, helps some issues to be resolved.
    > Most of the time it just lets me know what to watch out for, and what
    > areas of the kernel are having lots of issues.
    >
    > Given that the current maintainers of the stable kernels don't seem to
    > be objecting to the current setup of this list, I find it odd that you
    > wish to change it :)

    The reason I came up with this is simple and I have mentioned that in
    the changelog. I just thought we might improve the process a bit, if
    there is no demand for that then I will not push for it. This is an RFC
    after all.
    --
    Michal Hocko
    SUSE Labs

    \
     
     \ /
      Last update: 2016-12-05 15:58    [W:3.959 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site