linux-kernel - Re: [GIT] Security subsystem upate for 3.18

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: <1585069.kQpl3ZVDtr@sifl>
Date:	Sun, 12 Oct 2014 17:19:24 -0400
From:	Paul Moore <pmoore@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
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

On Sunday, October 12, 2014 11:50:41 AM Linus Torvalds wrote:
> 
> Examples of *good* reasons to do a back-merge:
> 
>  - the code was developed on a really ancient tree, and is *so*
> out-of-date that not only are there conflicts, they are complicated
> and might be more than simple data conflicts - semantic changes etc
> that you as a submaintainer might be better off handlng the merge of,
> since you presumably know the code you are merging intimately.
> 
>    Note: you may know your code intimately, but maybe you don't know
> the other changes intimately, and maybe the top-level maintainer is
> actually better at merging (possibly because that maintainer does 10+
> merges a day at times). So "a few conflicts" is not necessarily a good
> reason in itself, but there are certainly cases where things just get
> so ugly that "break the rules" is a very valid approach.
> 
>  - 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).
> 
>  - and hey, as with so many (all) kernel development rules, I don't
> actually want people to think that the rules are completely hard.
> Mistakes happen, shit happens, things go wrong, whatever.

Okay, understood.  I suppose I was hoping to see something a little less 
subjective (?), if for no other reason than to avoid the "what the hell?!" 
moments.  However, like you said, development is messy, and it's probably 
naive to try and force too rigid a process.

I'll stop back merging each new release without a valid reason.  I suspect 
there will be disagreements at points in the future about if the merge was 
truly warranted, but at least that is a step in the right direction.

Regardless, sorry for the problems this time around, hopefully things will be 
smoother in the future.

On Sunday, October 12, 2014 12:01:25 PM Linus Torvalds wrote:
> 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.

Aside from my own patches/work, I've tried to keep a single, continuous 
development branch (next) that can be used by others for SELinux development, 
in the linux-next tree, and by James via pull requests.  Unless this becomes 
to difficult to manage without regular back-merges (and I don't think this 
would be the case), I'd just assume keep this approach.

-Paul

-- 
paul moore
security and virtualization @ redhat

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