linux-ext4 - Re: [PATCH v2 00/25] e2fsprogs patchbomb 10/2013

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]

Message-ID: <20131018183943.GB6101@thunk.org>
Date:	Fri, 18 Oct 2013 14:39:43 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	"Darrick J. Wong" <darrick.wong@...cle.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH v2 00/25] e2fsprogs patchbomb 10/2013

On Thu, Oct 17, 2013 at 09:48:54PM -0700, Darrick J. Wong wrote:
> 
> Ted, since you've accepted patches into -pu, do you want me to send
> patches against -pu as well?  Or put more bluntly, what are your
> thoughts about revert-and-replace of patches in -pu?  Patches 2, 6,
> 11, 23, and 24 have changed significantly since 9/30.

The pu branch is a rewinding patch.  What this means in practice is
that I'll accept those patches which I believe are aready, and for the
rest, I'll rewind the "dw/resize64-fuse" branch back to next, and
apply the rest onto the dw/resize64-fuse branch.  If I get a new set
of inline patches, I'd do the same thing.

Then when I update the pu branch, I rewind the pu branch to next, and
then merge in all of the "xx/yyyy" feature branches, resolving
conflicts along the way.  This makes it obvious which branches have
conflicts against each other, and it also allows me to run regression
tests against the combined set of feature patch sets that aren't quite
ready for next.

So in other words, no, you don't need to send patches against pu,
thanks!

      	    	       	   	      - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html