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: <CA+55aFxtxBe8SaEYD6vAQME_YE+eD6mhU8F6Q850k-XBfzz4QQ@mail.gmail.com>
Date:	Sun, 12 Oct 2014 12:01:25 -0400
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Paul Moore <pmoore@...hat.com>
Cc:	James Morris <jmorris@...ei.org>,
	LSM List <linux-security-module@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: [GIT] Security subsystem upate for 3.18

One more comment on this..

On Sun, Oct 12, 2014 at 11:50 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
>
>  - you actively need infrastructure from newer versions, so you need
> to merge an upstream kernel for further development.
>
>    Even this is often questionable, but it's one of the best reasons
> to do back-merges. However, if so, that back-merge should very much
> spell out the exact reason why the merge was needed (not just "needed
> upstream features" in general, but what particular features were
> needed etc).

Btw, rather than merge from upstream, a better way is often to simply
start a new development branch. If you need a particular new feature,
you're *likely* to start doing new development rather than continuing
on some previous development, so it's often a good time to simply
create a new feature branch. I don't know how James feels about
merging multiple separate feature branches, but I know that *I* tend
to appreciate it when I get multiple well-defined pull requests rather
than one big one that does many different things.

And even if you then want to send just one pull-request, what you can
do if you have (say) three different feature branches is to create a
combined branch to be sent upstream, by just starting from one of the
feature branches and then merging the two other ones into that
combined one.  Some submaintainers do this quite a lot, and use
"octopus merges" to combine their different feature branches into one
final "please pull" branch. See for example Mark Brown's ASoC merge
for upstreaming (to Takashi Iwai, and then to me): commit bdf20b4291e.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ