lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 21 Mar 2019 17:39:41 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     dsterba@...e.cz, stable@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: Stable patches that don't apply to older kernels and how to get
 them

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ