Re: linux-next: the selinux tree needs cleaning up

[Paul Moore]

On Friday, June 20, 2014 08:59:31 AM Stephen Rothwell wrote:
> Hi Paul,

Hello again.

> On Thu, 19 Jun 2014 15:47:01 -0400 Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> > I want to avoid use a -rcX release as the foundation of any of my trees;
> > the -rc releases aren't as stable and it goes against what we're trying
> > to do with the different Linux Security trees.  Unfortunately, based on
> > what I've read above, this seems to be incompatible with linux-next.
> 
> The problem with basing your development for v3.17 on v3.15 is that
> you  do not take into account any of the changes done by others during
> v3.16-rc1 (or even your upstream tree) some of which may be core API
> changes.

The way I currently do things - merge the latest major release on top of the 
existing #next and then start applying the new #next patches - does leave the 
SELinux tree a bit behind when it comes to other subsystems, but it does at 
least include all of the SELinux relevant patches.

I'll admit it isn't perfect, but it seems to work reasonably well for SELinux 
development, and it was the process used by the previous SELinux maintainer.

> > While I hate to split my development branch from the #next branch, it
> > seems
> 
> I don't want that either ...
> 
> > like that is the only way to accomplish both a reasonably current and
> > stable development tree and get the patches into linux-next.  Unless you,
> > or anyone else for that matter, has a different suggestion I'm going to
> > go ahead and turn the current SELinux #next branch into a development
> > branch and create a new #next branch that will be based on the most
> > current -rc1, this new #next branch will be created new for each major
> > release.  Not exactly what I was hoping for, but will that work?
> 
> Do you mean that your #next branch will just be a merge of -rc1 and
> your development branch?  That would not actually change anything
> (except that you would possibly take care of some conflicts for me).

Sort of, I would basically create a new #next branch for linux-next which 
would be created fresh from the latest -rc1 and I would cherry-pick the 
patches for linux-next from my development branch.  It would be a bit of a 
mess to be honest, but I'm trying to reconcile the SELinux development 
needs/wants with the linux-next needs/wants. 

> At the core, what is in linux-next should just be exactly what will be
> merged by your upstream.

That has been, and remains the goal for me as well.  However, there have been 
a number of problems with this in the past, even excluding the latest merge 
window; I believe these past problems are what you are seeing now.

I am hopeful that these issues are behind us now, at least for the most part.

> My real point here is that that is not what has happened recently.  The
> patches in your tree have been cherry-picked or rebased into James' or
> Serge's trees, not merged so we now have duplication.  This is what you need
> to solve with James and Serge.  linux-next is a side issue - I can cope with
> a lot.

See above.  This issue has been solved with James a few months ago, this merge 
window was actually on track to go off without a problem, and it sorta did, 
but there were some out-of-band issues which caused some confusion in the 
linux-security world.  Let's try to move on a bit, discussing why the SELinux 
#next branch has some cruft in it doesn't help us resolve things since we all 
acknowledge there were problems for a while that should now be resolved ...

Stephen, assuming for a moment that I created a fresh branch, based against 
3.15, and then added the SELinux patches for 3.16 (basically the few new 
patches that were in the ole #next branch) would that serve as a reasonable 
basis for a new SELinux #next branch?  Around the -rc5/6/7 timeframe I would 
send a pull request to James to pull from this next branch into the Linux 
Security branch for 3.17.  Once 3.16 is released, I would merge that into this 
new #next branch and continue with the next round of patches.

FYI, more or less, the above is the process we've settled upon for all of the 
trees that get accumulated into the Linux Security tree.

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/