linux-kernel - Re: is the weeks before -rc1 the time to really be working on -next?

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] [day] [month] [year] [list]

Date:	Wed, 15 Oct 2008 16:56:27 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	akpm@...ux-foundation.org
Cc:	alan@...rguk.ukuu.org.uk, greg@...ah.com, sfr@...b.auug.org.au,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: is the weeks before -rc1 the time to really be working on
 -next?

From: Andrew Morton <akpm@...ux-foundation.org>
Date: Wed, 15 Oct 2008 16:41:39 -0700

> On Wed, 15 Oct 2008 16:08:21 -0700 (PDT)
> David Miller <davem@...emloft.net> wrote:
> 
> > And just like networking we could have Stephen treat the -mm
> > GIT tree as "important" which roughly means that other conflicting
> > trees will be knocked out of a -next release in deference to -mm.
> > 
> > Those people will have to fix their stuff, not you.  And you'll
> > always therefore get coverage in -next.
> 
> Yes, but then people would end up being based on linux-next, and that's
> a pretty rubbery target with all the rebasing and trees getting
> dropped, etc.  And they'd accidentally end up having to actually
> compile and run linux-next, shock-horror-oh-the-humanity.

That's not the idea actually.

The idea is that you run your tree strictly just like any other
subsystem maintainer.  Your tree is a clone of Linus's and you
put -mm stuff in on top of that.  Full stop.

So anyone can work on -mm independent of -next.  Just like networking,
PCI, INPUT, or any other subsystem.  There is no reason in my mind to
treat -mm specially, anything else is just pain for the people that
could contribute and help.

> I doubt if the world would end if we just stopped trying to run any of
> these uber-trees.  Everyone bases their work on mainline and then
> everything goes smash/bang/curse during the merge window.  It wouldn't
> be pretty, but it'd sure make people merge their trees promptly ;)

I think this aspect is interesting actually.

For folks that use stable GIT trees, we can cross polinate ourselves
to resolve merge problems quite simply, and I have seen this happen
already in the most recent cycle.

Things go smoothly for people that maintain stable GIT trees.  The
more stuff you touch the more important this is.

The "I rebase my tree ever 3 hours" stuff only works if you are
strictly working in a certain area and have no contributors you care
about.

But I even question this situation, no piece of code is an island in
the kernel and even well contained drivers want to modify some
infrastructure from time to time.
--
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/