linux-kernel - Re: [Stable-review] 4 stable kernel review cycles starting

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 1 Apr 2010 06:40:48 +0200
From:	Willy Tarreau <w@....eu>
To:	Greg KH <gregkh@...e.de>
Cc:	Dave Chinner <david@...morbit.com>, linux-kernel@...r.kernel.org,
	stable@...nel.org, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org, stable-review@...nel.org,
	alan@...rguk.ukuu.org.uk
Subject: Re: [Stable-review] 4 stable kernel review cycles starting

On Wed, Mar 31, 2010 at 03:47:55PM -0700, Greg KH wrote:
> On Thu, Apr 01, 2010 at 08:53:32AM +1100, Dave Chinner wrote:
> > On Wed, Mar 31, 2010 at 10:38:31AM -0700, Greg KH wrote:
> > > The issue is that applying individual patches like this is more
> > > "difficult" than just handling patches that are already marked in
> > > Linus's kernel tree as to be added to the stable queues.  So it
> > > takes a bit more time and effort to get to those patches, while
> > > still keeping up with the series like you, and other developers,
> > > sent.
> > 
> > Understood. Would providing a git tree to pull from for large series
> > like the XFS one make this easier for you in future? I can do that
> > bit of extra work if that makes things easier for you...
> 
> No, patches are still easier, I would have to convert the git tree to
> patches anyway, so for now, this is fine.

I don't know for you, Greg, but one thing that I find time consuming
when merging fixes that I'm not backporting is to try to find the
commit ID of the equivalent mainline fix. And it's not specific to
the kernel, I also have the same issue with other projects.

For this reason, IMHO it helps when submitters can indicate in each
patch the mainline equivalent ID, or alternatively that it's pointless
to look for it because the fix is much different.

Just my 2 cents,
Willy

--
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/