linux-next: Requirements and process

[Stephen Rothwell]

Hi all,

This email will outline the way I think that I should run linux-next.
People are welcome (in fact encouraged) to comment and add their thoughts.

Definitions:
"current" - this is the release we are working on now (i.e. at the moment
	2.6.26)
"next" - this is the release after "current" (i.e. at the moment 2.6.27)

Changesets I will accept into linux-next (currently being abused a bit):

	1) things destined for "current" i.e. fixes that have not made it
into Linus' tree yet. These will obviously have been posted on lkml and
reviewed and tested.

	2) things expected to be in "next".  These will have been posted
on appropriate mailing lists (most often lkml) and reviewed and tested.

Linux-next is not for experimental patches (but see below).

During the merge window, there is clearly a cross over between these types.

I would expect subsystem owners who use git would have two separate
branches in their published trees (or two separate trees) for these two
types of commits  (e.g. the powerpc tree has a "merge" branch for type 1
and a powerpc-next branch for 2).  Quilt users may have two series files
or just keep the type 1 patches at the start (or something similar).

I would expect the flow of changes to be something like this:

	During the entire cycle, the number type 1 changes would vary up
and down but never be very high.  These changes would probably stay in
linux-next only for short periods and then be integrated into Linus' tree.

	The number type 2 changes should be at its highest just before
the merge window opens and be close to zero at rc1 (or maybe rc2). After
that it should grow again until the next merge window.  Things entering
linux-next should generally stay there (though they may be modified due
to conflicts or bugs).

I currently have 9 trees that are of type 1 above:

x86-fixes	sched-fixes	powerpc-merge
scsi-rc-fixes	net-current	sparc-current
sound-current	arm-current	pci-current

I currently have 54 trees that (I assume) are of type 2 above:

driver-core	usb		x86
sched		pci		device-mapper
hid		i2c		kernel-doc
avr32		v4l-dvb		s390
sh		jfs		kbuild
ide		libata		nfs
xfs		infiniband	acpi
blackfin	nfsd		ieee1394
hwmon		ubi		kvm
dlm		scsi		ia64
tests		ocfs2		selinux
m68k		powerpc		hrt
lblnet		ext4		4xx
async_tx	udf		security-testing
net		sparc		galak
mtd		wireless	crypto
vfs		sound		arm
cpufreq		semaphore	semaphore-removal

And three trees that I am not sure about:

x86-latest	sched-latest	ldp

Most of these trees (apart from the last three) are now small or empty
relative to Linus' tree.

Process (so you all know what I am up to):

Each day (or so) I start with Linus' tree and merge all the above trees
one at a time.  I will attempt to fixup merge conflicts and notify the
appropriate tree/change owners of what I have needed to do.  If things
are too bad, I will not merge a particular tree for that day (I have only
had to do that a couple of times).  Between each merge (including before
the first) I do two builds of the tree (currently a powerpc
ppc64_defconfig and an x86_64 allmodconfig).  If the build fails, I
either revert offending changes or add small fixup patches.  Again I will
notify the appropriate tree/change owners.

Occasionally, I will pick up single patches that are needed to make the
tree build for some architectures/configs.  Andrew tells me that I need
to take ownership of these patches and make sure someone adds them to a
tree destined for Linus - that makes sense to me.

After all the above, I put the tree into our build farm and make sure it
builds a few configs before I release it.

Experimental stuff:

I am currently integrating the Linux Driver Project tree from Greg KH on
the understanding that anything in it that causes a problem gets dropped
i.e. I generally don't even try to figure out what went wrong, just let
him know.  I am beginning to feel that this may need to be in some way
separated from linux-next proper.  Ideas welcome.

Where from here:

Andrew is currently rebasing the -mm tree on linux-next.  He intends to
also feed some of the trees he hosts into linux-next (hopefully avoiding
circular dependancies :-))

The following architectures are not in linux-next (and should be):

alpha		cris		frv
h8300		m32r		m68knommu
mips		mn10300		parisc
um		v850		xtensa

See Andrew's mail for a list of other subsystems.

-- 
Cheers,
Stephen Rothwell                    sfr@xxxxxxxxxxxxxxxx
http://www.canb.auug.org.au/~sfr/

Attachment: pgp00000.pgp
Description: PGP signature