linux-next: unusual update of the security tree

linux-next: unusual update of the security tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 465 bytes --]

Hi James,

The security tree
(git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git#next)
looks a bit strange today ... It appears to have been created by Casey
Schaufler (cc'd) and contains some quite old commits and back merges of
your tree.  I *guess* you have merged in Casey's tree after he merged in
your tree from yesterday.

Just for your consideration.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: unusual update of the security tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

Hi James,

On Wed, 28 Nov 2012 10:16:35 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> The security tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git#next)
> looks a bit strange today ... It appears to have been created by Casey
> Schaufler (cc'd) and contains some quite old commits and back merges of
> your tree.  I *guess* you have merged in Casey's tree after he merged in
> your tree from yesterday.

If that is what happened, it may be worth always using the --no-ff flag
to git merge/pull to make sure that the top commit on your tree always
has you as the committer (and maybe SOB).

Linus, does that make sense in general for maintainers?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: unusual update of the security tree

[Linus Torvalds]

On Tue, Nov 27, 2012 at 3:28 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> If that is what happened, it may be worth always using the --no-ff flag
> to git merge/pull to make sure that the top commit on your tree always
> has you as the committer (and maybe SOB).
>
> Linus, does that make sense in general for maintainers?

No. That just hides the real problem - back-merges of random points in history.

Don't do them, people. EVER.

              Linus

Re: linux-next: unusual update of the security tree

[Casey Schaufler]

On 11/27/2012 3:16 PM, Stephen Rothwell wrote:

> Hi James,
>
> The security tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git#next)
> looks a bit strange today ... It appears to have been created by Casey
> Schaufler (cc'd) and contains some quite old commits and back merges of
> your tree.  I *guess* you have merged in Casey's tree after he merged in
> your tree from yesterday.

I *thought* that I had used the same procedures that worked before.
In fact, I still do think that, but if it's a problem I can purge my
smack-next tree and start over.

James, the two changes that came from smack-next are pretty minor. I
don't think you should hesitate to back them out if that helps.


>
> Just for your consideration.
>

Re: linux-next: unusual update of the security tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

On Tue, 27 Nov 2012 15:30:31 -0800 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> On Tue, Nov 27, 2012 at 3:28 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > If that is what happened, it may be worth always using the --no-ff flag
> > to git merge/pull to make sure that the top commit on your tree always
> > has you as the committer (and maybe SOB).
> >
> > Linus, does that make sense in general for maintainers?
> 
> No. That just hides the real problem - back-merges of random points in history.
> 
> Don't do them, people. EVER.

I was also thinking about the case where a developer does work based on
the maintainer's published tree and then the maintainer pulls that work
sometime later (when his published tree has not been updated in the mean
time).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: unusual update of the security tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3660 bytes --]

Hi Casey,

On Tue, 27 Nov 2012 15:45:17 -0800 Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> On 11/27/2012 3:16 PM, Stephen Rothwell wrote:
> 
> > The security tree
> > (git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git#next)
> > looks a bit strange today ... It appears to have been created by Casey
> > Schaufler (cc'd) and contains some quite old commits and back merges of
> > your tree.  I *guess* you have merged in Casey's tree after he merged in
> > your tree from yesterday.
> 
> I *thought* that I had used the same procedures that worked before.
> In fact, I still do think that, but if it's a problem I can purge my
> smack-next tree and start over.
> 
> James, the two changes that came from smack-next are pretty minor. I
> don't think you should hesitate to back them out if that helps.

This is the shortlog for the changes in the security tree between
yesterday and today;

Casey Schaufler (32):
      Commit 272cd7a8c67dd40a31ecff76a503bbb84707f757 introduced     a change to the way rule lists are handled and reported in     the smackfs filesystem. One of the issues addressed had to     do with the termination of read requests on /smack/load.     This change introduced a error in /smack/cipso, which shares     some of the same list processing code.
      Revert "Commit 272cd7a8c67dd40a31ecff76a503bbb84707f757 introduced"
      Smack: smackfs cipso seq read repair
      Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
      Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
      Smack: recursive tramsmute
      Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
      Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
      Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
      Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
      Smack: allow for significantly longer Smack labels v4
      Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
      Smack: fix smack_new_inode bogosities
      Smack: Maintainer Record
      Smack: onlycap limits on CAP_MAC_ADMIN
      Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
      Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
      Smack: user access check bounds
      Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
      Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
      Smack: remove task_wait() hook.
      Smack: setprocattr memory leak fix
      Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
      Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
      Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
      Merge branch 'for-1209'
      Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
      Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
      Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
      Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security into for-1211
      Smack: use select not depends in Kconfig
      Smack: create a sysfs mount point for smackfs

Rafal Krypa (2):
      Smack: don't show empty rules when /smack/load or /smack/load2 is read
      Smack: implement revoking all rules for a subject label

Tetsuo Handa (1):
      gfp flags for security_inode_alloc()?

It's a bit of a mess :-(
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: unusual update of the security tree

[James Morris]

On Tue, 27 Nov 2012, Linus Torvalds wrote:

> On Nov 27, 2012 4:01 PM, "Stephen Rothwell" <sfr@canb.auug.org.au> wrote:
> >
> > Hi
> > This is the shortlog for the changes in the security tree between
> > yesterday and today;
> 
> This is an excellent example of the kind of tree I will not pull from.
> 
> There are more merges than actual work. No way, Jose.

Ugh, I somehow missed this thread last week.


-- 
James Morris
<jmorris@namei.org>

Re: linux-next: unusual update of the security tree

[James Morris]

Any suggestions on how to fix this?  That branch is public, and what 
people use to develop against, so I can't rebase it.



On Wed, 28 Nov 2012, Stephen Rothwell wrote:

> Hi Casey,
> 
> On Tue, 27 Nov 2012 15:45:17 -0800 Casey Schaufler <casey@schaufler-ca.com> wrote:
> >
> > On 11/27/2012 3:16 PM, Stephen Rothwell wrote:
> > 
> > > The security tree
> > > (git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git#next)
> > > looks a bit strange today ... It appears to have been created by Casey
> > > Schaufler (cc'd) and contains some quite old commits and back merges of
> > > your tree.  I *guess* you have merged in Casey's tree after he merged in
> > > your tree from yesterday.
> > 
> > I *thought* that I had used the same procedures that worked before.
> > In fact, I still do think that, but if it's a problem I can purge my
> > smack-next tree and start over.
> > 
> > James, the two changes that came from smack-next are pretty minor. I
> > don't think you should hesitate to back them out if that helps.
> 
> This is the shortlog for the changes in the security tree between
> yesterday and today;
> 
> Casey Schaufler (32):
>       Commit 272cd7a8c67dd40a31ecff76a503bbb84707f757 introduced     a change to the way rule lists are handled and reported in     the smackfs filesystem. One of the issues addressed had to     do with the termination of read requests on /smack/load.     This change introduced a error in /smack/cipso, which shares     some of the same list processing code.
>       Revert "Commit 272cd7a8c67dd40a31ecff76a503bbb84707f757 introduced"
>       Smack: smackfs cipso seq read repair
>       Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>       Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>       Smack: recursive tramsmute
>       Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>       Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>       Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>       Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>       Smack: allow for significantly longer Smack labels v4
>       Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>       Smack: fix smack_new_inode bogosities
>       Smack: Maintainer Record
>       Smack: onlycap limits on CAP_MAC_ADMIN
>       Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>       Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>       Smack: user access check bounds
>       Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>       Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>       Smack: remove task_wait() hook.
>       Smack: setprocattr memory leak fix
>       Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>       Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>       Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>       Merge branch 'for-1209'
>       Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>       Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>       Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security
>       Merge branch 'next' of git://git.kernel.org/.../jmorris/linux-security into for-1211
>       Smack: use select not depends in Kconfig
>       Smack: create a sysfs mount point for smackfs
> 
> Rafal Krypa (2):
>       Smack: don't show empty rules when /smack/load or /smack/load2 is read
>       Smack: implement revoking all rules for a subject label
> 
> Tetsuo Handa (1):
>       gfp flags for security_inode_alloc()?
> 
> It's a bit of a mess :-(
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 

-- 
James Morris
<jmorris@namei.org>

Re: linux-next: unusual update of the security tree

[Linus Torvalds]

On Thu, Dec 6, 2012 at 5:25 AM, James Morris <jmorris@namei.org> wrote:
> Any suggestions on how to fix this?  That branch is public, and what
> people use to develop against, so I can't rebase it.

Quite frankly, I really am not going to pull that. It has random crazy
merges for no reason what-so-ever. This is *exactly* the kind of stuff
I used to speak out against years ago, and I thought we had long since
put behind us. Do

    git fetch git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
next
    gitk ..FETCH_HEAD

from mainline to see what I'm talking about. It has all those random
merges interspersed with random sporadic development. This is not how
we make history make sense.

It looks like Casey has for the last year+ just had his own tree, done
his own thing, and then pulled from the 'next' branch of security at
random points to intermix his occasional commits with everything
else.So now all his sporadic commits are randomly intermixed together
with *everything* else that happened over the last year. It's kind of
the epitome of not-a-feature-branch.

There are 26 "normal" commits spread out over the year, coupled with
22 merges that have been done bi-weekly or something, and have
altogether brought in 13 *thousand* commits that have very little to
do with the 26 commits that are new work. And with many of the merges
done despite that development tree having *no* development in it of
its own, so you have those repeated "let's merge upstream code" pulls
that only add upstream code with no development in between.

This is the kind of development that should be kept private, and maybe
using a "git pull --rebase" to maintain the private commits on top of
whatever upstream. NOT be used to say "ok, I now have more than a year
of messy development history of 22 changes randomly interspersed with
the thirteen thousand commits that went into mainline during that
year+ time".

Or it should just have been a development branch that only did its own
development and never pulled from upstream.

Have people pulled that thing into anything else? Because quite
frankly, I think it's unsalvageable except with a rebase.

                  Linus

Re: linux-next: unusual update of the security tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 664 bytes --]

Hi James,

On Thu, 6 Dec 2012 08:25:21 -0800 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> Have people pulled that thing into anything else? Because quite
> frankly, I think it's unsalvageable except with a rebase.

So to be explicit, I think you need to do this:

	- tell as many people as possible that you are going to rebase
	  your tree
	- reset your tree back to the point just before you pulled Casey's
	  tree (3f0cc6ae8662).
	- Casey needs to rebase his tree on top of yours
	- then after Casey has tested his tree again you can repull his
	  new tree.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: unusual update of the security tree

[James Morris]

On Thu, 6 Dec 2012, Linus Torvalds wrote:

> Have people pulled that thing into anything else? Because quite
> frankly, I think it's unsalvageable except with a rebase.

AFAIK, only developers such as Casey will have pulled it for development 
purposes.

And sorry, I should be checking the trees I pull from more carefully.



- James
-- 
James Morris
<jmorris@namei.org>

Re: linux-next: unusual update of the security tree

[Casey Schaufler]

On 12/6/2012 3:21 PM, James Morris wrote:
> On Thu, 6 Dec 2012, Linus Torvalds wrote:
>
>> Have people pulled that thing into anything else? Because quite
>> frankly, I think it's unsalvageable except with a rebase.
> AFAIK, only developers such as Casey will have pulled it for development 
> purposes.
>
> And sorry, I should be checking the trees I pull from more carefully.

I have messed up and believe that I understand my error and the
impact that it has had on others. I also believe that I understand
what I should be doing henceforth. Once I get the word from James
I will rebase my tree from his. I will stop doing merges except as
recommended.

Re: linux-next: unusual update of the security tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

Hi James,

On Fri, 7 Dec 2012 10:21:31 +1100 (EST) James Morris <jmorris@namei.org> wrote:
>
> On Thu, 6 Dec 2012, Linus Torvalds wrote:
> 
> > Have people pulled that thing into anything else? Because quite
> > frankly, I think it's unsalvageable except with a rebase.
> 
> AFAIK, only developers such as Casey will have pulled it for development 
> purposes.
> 
> And sorry, I should be checking the trees I pull from more carefully.

Are you going to fix this before asking Linus to pull?
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: unusual update of the security tree

[James Morris]

On Thu, 13 Dec 2012, Stephen Rothwell wrote:

> Hi James,
> 
> On Fri, 7 Dec 2012 10:21:31 +1100 (EST) James Morris <jmorris@namei.org> wrote:
> >
> > On Thu, 6 Dec 2012, Linus Torvalds wrote:
> > 
> > > Have people pulled that thing into anything else? Because quite
> > > frankly, I think it's unsalvageable except with a rebase.
> > 
> > AFAIK, only developers such as Casey will have pulled it for development 
> > purposes.
> > 
> > And sorry, I should be checking the trees I pull from more carefully.
> 
> Are you going to fix this before asking Linus to pull?

Yes.

-- 
James Morris
<jmorris@namei.org>