linux-kernel - How linux-staging is released (was Re: linux-staging/linux-next merge/build errors)

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]

Date:	Sat, 21 Jun 2008 00:19:56 -0700
From:	Greg KH <greg@...ah.com>
To:	Stephen Rothwell <sfr@...b.auug.org.au>,
	Ingo Molnar <mingo@...e.hu>
Cc:	linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: How linux-staging is released (was Re: linux-staging/linux-next
	merge/build errors)

On Sat, Jun 21, 2008 at 12:40:17PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today I have done a test merge of linux-staging into linux-next.

Thanks for doing this.

I've been thinking this past week about how to properly handle the
linux-staging tree.

For some background, it came about because Ingo pointed out that it
seems hard to get new drivers merged into the main tree quickly, and
that perhaps we should have a drivers/staging/ directory in Linus's tree
where we can dump things in quickly and then clean them up later.

That got quickly vetoed by a number of other maintainers, and I brought
up the point of me just doing a separate -staging tree that would be
something like this, but not go into Linus's tree directly.

I originally sprung the idea on you of having you merge it into -next to
get testing and build coverage, but I've been thinking a lot more about
this, and I don't want to burden you with this, you have enough work to
do with trying to get the normal -next tree out :)

So, if you don't mind, and no one else objects, here's how I would like
to run the -staging tree:

  - It's a set of patches, in quilt form, that can be applied on top of
    a released kernel from Linus.
  - It will be rebased at the least with every -rc and -final release,
    and probably a lot more frequently with a few -git releases
    inbetween.
  - I will do a "roll-up" patch release for ever -final release and -rc
    release to make it easy for users to grab it and apply it to a
    release so that they can use the drivers/filesystems contained in
    it.
  - Once the patches in the -staging tree are nearing "cleaned up" stage
    (i.e. their TODO list is finished off), I will submit them to the
    proper subsystem maintainer for inclusion into their tree, on the
    way to Linus's tree eventually.

This process should allow for a much easier barrier to development and
using the drivers by everyone, instead of having to rebase on top of
-next, which can be hairy at times.  It also allows distros and anyone
else to grab the full patchset in a much easier manner for their users,
if they so desire.

Does that sound reasonable to everyone?

I'll go do a release for 2.6.26-rc7 to start it all off.

thanks,

greg k-h
--
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/