Messages in this thread | | | Date | Sat, 3 May 2008 15:45:42 +1000 | From | Stephen Rothwell <> | Subject | linux-next: Requirements and process |
| |
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@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [unhandled content-type:application/pgp-signature] | |