Stable patches that don't apply to older kernels and how to get them

Stable patches that don't apply to older kernels and how to get them

[David Sterba]

Hi,

would it be possible to have a git repository with all patches that are
submitted to stable@ but don't apply directly?

I get notified by mail, that's fine though it's not that convenient to
see all the pending patches for backport to a given version.

My proposal:

- create a separate stable-unapplied git repository

- if a patch does not apply to a given version, it's stored as-is to a
  directory of the base version (like 4.4)

- once a fixed version is applied to stable-queue.git/released-4.4, the
  patch in the other repo is deleted

I believe this can be highly automated and once implemented would not
too much additional work to the stable workflow. I could possibly write
a scraper of the mail archives to pick the patches and manage the
repository but I think that a central repository could help other
maintainers too or to spread the load to all interested developers.

If something like that already exists, please let me know.
Thanks.

Re: Stable patches that don't apply to older kernels and how to get them

[Greg KH]

On Thu, Mar 21, 2019 at 04:14:14PM +0100, David Sterba wrote:
> Hi,
> 
> would it be possible to have a git repository with all patches that are
> submitted to stable@ but don't apply directly?
> 
> I get notified by mail, that's fine though it's not that convenient to
> see all the pending patches for backport to a given version.
> 
> My proposal:
> 
> - create a separate stable-unapplied git repository
> 
> - if a patch does not apply to a given version, it's stored as-is to a
>   directory of the base version (like 4.4)
> 
> - once a fixed version is applied to stable-queue.git/released-4.4, the
>   patch in the other repo is deleted
> 
> I believe this can be highly automated and once implemented would not
> too much additional work to the stable workflow. I could possibly write
> a scraper of the mail archives to pick the patches and manage the
> repository but I think that a central repository could help other
> maintainers too or to spread the load to all interested developers.
> 
> If something like that already exists, please let me know.

Nothing like this exists, sorry.

And if you want to automate this, wonderful, but I do not have any time
to do so, and it does not fit into my workflow at all.  Patches that do
not apply are the exception by far, not the rule, so I doubt this would
really help out much.

And of course, the i915 developers would just ignore it, as they hold
the record for patches that never apply, and then never send patches in
as they are already 6-8 months ahead :)

thanks,

greg k-h

Re: Stable patches that don't apply to older kernels and how to get them

[Greg KH]

On Thu, Mar 21, 2019 at 05:39:41PM +0100, Greg KH wrote:
> On Thu, Mar 21, 2019 at 04:14:14PM +0100, David Sterba wrote:
> > Hi,
> > 
> > would it be possible to have a git repository with all patches that are
> > submitted to stable@ but don't apply directly?
> > 
> > I get notified by mail, that's fine though it's not that convenient to
> > see all the pending patches for backport to a given version.
> > 
> > My proposal:
> > 
> > - create a separate stable-unapplied git repository
> > 
> > - if a patch does not apply to a given version, it's stored as-is to a
> >   directory of the base version (like 4.4)
> > 
> > - once a fixed version is applied to stable-queue.git/released-4.4, the
> >   patch in the other repo is deleted
> > 
> > I believe this can be highly automated and once implemented would not
> > too much additional work to the stable workflow. I could possibly write
> > a scraper of the mail archives to pick the patches and manage the
> > repository but I think that a central repository could help other
> > maintainers too or to spread the load to all interested developers.
> > 
> > If something like that already exists, please let me know.
> 
> Nothing like this exists, sorry.
> 
> And if you want to automate this, wonderful, but I do not have any time
> to do so, and it does not fit into my workflow at all.  Patches that do
> not apply are the exception by far, not the rule, so I doubt this would
> really help out much.
> 
> And of course, the i915 developers would just ignore it, as they hold
> the record for patches that never apply, and then never send patches in
> as they are already 6-8 months ahead :)

Note, what does work today is Sasha's bot that finds patches that are
 cc: stable and tries to apply them to older kernels and sends you an
email if the patch fails.  That is running today in semi-frequent waves,
and we have gotten backports sent to the list before the patch lands in
Linus's tree, which is great.  So you can take advantage of this now if
you want to.

thanks,

greg k-h

Re: Stable patches that don't apply to older kernels and how to get them

[David Sterba]

On Thu, Mar 21, 2019 at 05:39:41PM +0100, Greg KH wrote:
> On Thu, Mar 21, 2019 at 04:14:14PM +0100, David Sterba wrote:
> > Hi,
> > 
> > would it be possible to have a git repository with all patches that are
> > submitted to stable@ but don't apply directly?
> > 
> > I get notified by mail, that's fine though it's not that convenient to
> > see all the pending patches for backport to a given version.
> > 
> > My proposal:
> > 
> > - create a separate stable-unapplied git repository
> > 
> > - if a patch does not apply to a given version, it's stored as-is to a
> >   directory of the base version (like 4.4)
> > 
> > - once a fixed version is applied to stable-queue.git/released-4.4, the
> >   patch in the other repo is deleted
> > 
> > I believe this can be highly automated and once implemented would not
> > too much additional work to the stable workflow. I could possibly write
> > a scraper of the mail archives to pick the patches and manage the
> > repository but I think that a central repository could help other
> > maintainers too or to spread the load to all interested developers.
> > 
> > If something like that already exists, please let me know.
> 
> Nothing like this exists, sorry.
> 
> And if you want to automate this, wonderful, but I do not have any time
> to do so, and it does not fit into my workflow at all.  Patches that do
> not apply are the exception by far, not the rule, so I doubt this would
> really help out much.

I'm concerned about patches that are sent to sable but don't get applied
in the end. IOW dropped on the floor, unless somebody cares, which is
probably the maintainers that are known to be overloaded.

So, I'm looking for some kind of help, to extend the stable workflow and
address the problem where it happens and where the whole mail and git
machinery already is.

The number of unapplied patches has raised recently for me because I
started to closely examine which stable versions could be affected. And
go as far as 4.4.

Why there are otherwise only a few patches that don't apply, I can only
speculate and I think that differs by subsystem. That stable kernels are
potentially missing stability fixes should be a concern in general. But
well, it seems I have to help myself here.

Re: Stable patches that don't apply to older kernels and how to get them

[Greg KH]

On Thu, Mar 21, 2019 at 07:19:46PM +0100, David Sterba wrote:
> On Thu, Mar 21, 2019 at 05:39:41PM +0100, Greg KH wrote:
> > On Thu, Mar 21, 2019 at 04:14:14PM +0100, David Sterba wrote:
> > > Hi,
> > > 
> > > would it be possible to have a git repository with all patches that are
> > > submitted to stable@ but don't apply directly?
> > > 
> > > I get notified by mail, that's fine though it's not that convenient to
> > > see all the pending patches for backport to a given version.
> > > 
> > > My proposal:
> > > 
> > > - create a separate stable-unapplied git repository
> > > 
> > > - if a patch does not apply to a given version, it's stored as-is to a
> > >   directory of the base version (like 4.4)
> > > 
> > > - once a fixed version is applied to stable-queue.git/released-4.4, the
> > >   patch in the other repo is deleted
> > > 
> > > I believe this can be highly automated and once implemented would not
> > > too much additional work to the stable workflow. I could possibly write
> > > a scraper of the mail archives to pick the patches and manage the
> > > repository but I think that a central repository could help other
> > > maintainers too or to spread the load to all interested developers.
> > > 
> > > If something like that already exists, please let me know.
> > 
> > Nothing like this exists, sorry.
> > 
> > And if you want to automate this, wonderful, but I do not have any time
> > to do so, and it does not fit into my workflow at all.  Patches that do
> > not apply are the exception by far, not the rule, so I doubt this would
> > really help out much.
> 
> I'm concerned about patches that are sent to sable but don't get applied
> in the end. IOW dropped on the floor, unless somebody cares, which is
> probably the maintainers that are known to be overloaded.
> 
> So, I'm looking for some kind of help, to extend the stable workflow and
> address the problem where it happens and where the whole mail and git
> machinery already is.
> 
> The number of unapplied patches has raised recently for me because I
> started to closely examine which stable versions could be affected. And
> go as far as 4.4.
> 
> Why there are otherwise only a few patches that don't apply, I can only
> speculate and I think that differs by subsystem. That stable kernels are
> potentially missing stability fixes should be a concern in general. But
> well, it seems I have to help myself here.

You can easily just filter on the FAILED emails and see what happens
there if you want to track these.  I figure that if I send out the email
and no one responds with a backported patch, then no one really cares
about that issue on that old kernel, so we are fine.  If they did care,
they would do the backport :)

Again, look at Sasha's emails, that might be what you are looking for.

Or better yet, create something automated on your own that does the "did
this apply or not" test for you, that way you get to see what happens
here much more easily and only for the subsystems you care about.

thanks,

greg k-h