linux-kernel - Re: [git pull] orangefs bugfixes for rc2

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, 31 Mar 2016 17:11:01 -0500
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Mike Marshall <hubcap@...ibond.com>
Cc:	Martin Brandenburg <martin@...ibond.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [git pull] orangefs bugfixes for rc2

On Thu, Mar 31, 2016 at 4:06 PM, Mike Marshall <hubcap@...ibond.com> wrote:
> sorry to follow up my own post... perhaps we should
> point our pull requests at Al and base them on one
> of Al's trees? I'm sure all this should be easy, we're
> just clumsy 'cause we're new...

No, for stuff that is entirely internal to a filesystem, the
filesystem maintainers should preferably strive to be as independent
of all other trees as possible.

That means that the base you use should generally be either your own
previous top-of-tree (ie without any back-merges from me or other
trees at all: so your branch only contains your own work), or if it
ends up being more convenient some "well-defined" general release (ie
a major release like 4.5, or a later rc like rc4+ that is starting to
be considered reasonably stable).

For bug-fix pulls, the best base tends to be your own tree that you
asked me to pull during the merge window, while then "new development
for the next version" might be some known base.

Of course, since orangefs just got merged, you can't use 4.5 as a
base, but then going forward when you start doing development that you
expect to be merged for 4.7, you might want to use 4.6 as a base for
that.

Right now, using rc1 as a base for fixes would also be reasonable,
exactly because you can't use any older release. But in general it's
best to try to have better starting points than rc1 (or worse yet,
some "random daily point from Linus") which may have undiscovered bugs
etc.

         Linus