I would like to write a short article about the new development process discussed during last Linux Kernel Developers' Summit for my local LUG.

Since I'm not able to find an accurate report of what has been discussed during that meeting I try to summariza what is my understanding of the current process:

The are two kind of releases, 2.6.x kerneles and 2.6.x.y

2.6.x.y are maintained by the "stable" team (stable at kernel dot org), are released amost every week.

Here is the latest ( I hope ) announce I found in the archive including an explanation of how stable development works:

Rules on what kind of patches are accepted, and what ones are not, into the "-stable" tree:

• It must be obviously correct and tested.
• It can not bigger than 100 lines, with context.
• It must fix only one thing.
• It must fix a real bug that bothers people (not a, "This could be a problem..." type thing.)
• It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some "oh, that's not good" issue. In short, something critical.
• No "theoretical race condition" issues, unless an explanation of how the race can be exploited.
• It can not contain any "trivial" fixes in it (spelling changes, whitespace cleanups, etc.)
• It must be accepted by the relevant subsystem maintainer.
• It must follow Documentation/SubmittingPatches rules.

Procedure for submitting patches to the -stable tree:

• Send the patch, after verifying that it follows the above rules, to stable@kernel.org.
• The sender will receive an ack when the patch has been accepted into the queue, or a nak if the patch is rejected. This response might take a few days, according to the developer's schedules.
• If accepted, the patch will be added to the -stable queue, for review by other developers.
• Security patches should not be sent to this alias, but instead to the documented security@kernel.org.

Review cycle:

• When the -stable maintainers decide for a review cycle, the patches will be sent to the review committee, and the maintainer of the affected area of the patch (unless the submitter is the maintainer of the area) and CC: to the linux-kernel mailing list.
• The review committee has 48 hours in which to ack or nak the patch.
• If the patch is rejected by a member of the committee, or linux-kernel members object to the patch by bringing up issues that the maintainer and members did not realize, the patch will be dropped from the queue.
• At the end of the review cycle, the acked patches will be added to the latest -stable release, and a new -stable release will happen.
• Security patches will be accepted into the -stable tree directly from the security kernel team, and not go through the normal review cycle. Contact the kernel security team for more details on this procedure.

Review committe:

• This will be made up of a number of kernel developers who have volunteered for this task, and a few that haven't.

2.6.x kernel are maintained by Linus Torvalds and Andrew Morton (both are from OSDL) and the development is as follow:

• As soon a new kernel is released a two weeks windows is open, during this period of time maintainers can submit big diffs to Linus (usually the patched sitted in -mm kernels for a few weeks). Preferred way to submit big changes is using GIT ( more information about GIT at http://git.or.cz/ and http://www.kernel.org/pub/software/scm/git/docs/tutorial.html).
• After two weeks a -rc1 kernel is released and now is possible to push only patches that do not include new functionalities)
• Aftwer two weeks -rc2 is released
• Process continues until the kernel is considered "ready", the process should last three months ( 4 kernels per yeard should be released).

I'm sure I'm missing lot of details so I would really appreciate if you could support me in writing this article that hopefully will be usefull outside my LUG as well :-)

I recently wrote a document on the different kernel trees and how to apply patches for them. In that document I also give a description of the various trees.

Perhaps that document will be useful to you. You can find it in a recent kernel source tree as Documentation/applying-patches.txt or you can read it online via lrx at this URL: http://sosdg.org/~coywolf/lxr/source/Documentation/applying-patches.txt

Good luck on your article. Once you are done with it I'd love to read it and I guess a lot of other people would too, so please supply an URL to it at that time :-)

However, three months is _far_ too long. Look at what is happening post-2.6.14? There's loads of really huge changes going in which were backed up over the last two months.

Continuing like this will just push the release of each kernel further and further out as there's more stuff merged during the mayhem than can possibly be properly reviewed and tested.

Shorter release cycles means that there's less mayhem, which in turn means more time to review.

Yes. Three months would be too much. I considered even 2.6.14 to be delayed by at least one week. So 8 weeks is certainly better than it used to be, but I think 6 weeks should be the goal-post.

But to hit that, we'd might need to shrink the "merge window" from two weeks to just one, otherwise there's not enough time to calm down. With most of the real development happening during the previous calm-down stage, that might not be impossible: we'd only have one week for merges, but that isn't the week when development actually happens, so who cares?

Everything said, I think 2.6.13->14 worked well enough, even if it's hard to say how well a process works after one release. Considering that 2.6.13 had the painful PCI changes (you may not have noticed too much, since they were x86 only) and there were some potentially painful SCSI changes in the .14 early merges, so it's not like 13->14 was an "easy" release - so the process certainly _seems_ to be workable.

So I'm planning on continuing with it unchanged for now. Two-week merge window until -rc1, and then another -rc kernel roughly every week until release. With the goal being 6 weeks, and 8 weeks being ok.

I don't think anybody has been really unhappy with this approach? Hmm?

That's not actually a very safe bet at all.

Why? Because only a small percentage of people actually test -rc kernels in the first place.

So if you release the last -rc as the standard kernel, you (a) get no real coverage advantage anyway and (b) you just wasted a week in order to try to get some coverage that you aren't getting.

The current kernel development model is to merge stuff early, which hopefully motivates the people who _do_ test -rc kernels to actually test -rc1, since they know that that's the one that has _all_ the really relevant goodies.

And most of those that do test -rc1 will never see any problems at all. Those that do, are now more likely to test the rest of the -rcs, hopefully until their problem is resolved. And those that don't test -rc releases (because they simply don't upgrade very often) will _never_ test an -rc release, whether it's the first one or the last one.

So what we have to fight this problem is the stable kernel series. We release the final 2.6.x kernel with as much testing as we can, but it's just an undeniable fact that a lot of people will try that kernel only after the release, and often it might be weeks after the release. Doing -rc kernels didn't do anything for those cases.

But when they find a problem (or somebody who _did_ test an -rc kernel, but didn't notice a problem until much later), we try to have a process to get those issues fixed.

So repeat after me: "Most people never test -rc kernels".

Btw, the ones that _do_ test -rc kernels usually don't test all of them. The current model is set up in a way where there is _one_ special -rc kernel that we should try to get people to test: the first one.

That hopefully encourages people to try an -rc kernel who might otherwise decide that there's too many -rc kernels to bother with. If they know that all of the real development happened before -rc1, they also are thus aware that it doesn't really matter which -rc kernel they test, so just testing _one_ is very good indeed.

The first -rc kernel is also special in another way: it's the one we "wait" for. It's the one that happens after two weeks, and has a deadline. The others happen more frequently, and are really objectively less important than the first one.

(In contrast, some other projects try to make the _last_ -rc be the important one. That's totally the wrong way around, because if there are more people testing the last one, the testing happens at _exactly_ the wrong point in time from a "let's fix the problems" standpoint)

So the call to people who can be bothered to test at all: if you only test one -rc kernel, please test the first one. That way we get a heads-up on problems earlier.

(And if you like testing -rc kernels, please test all of them. Or even the nightly snapshots. Or track the git tree several times a day. The more, the merrier, but if you only want to boot one kernel a month, make it be the -rc1 kernel).

I *try* to test *ALL* versions which are announced as the most likely future -final. When Marcelo tells us that -rc2 will be -final if nobody complains, I really test it. I build it on several archs and try to catch stupid bugs because I hate stupid bugs in final releases, they pollute bug reports (worst ones being build errors).

However, when he announces -preX (X>1) or when you annonce any -rc which is not likely to become -final, I just check the changelog, and build it if I both see something which applies to my setup, and I have nothing else to do.

The freezes are for fixing bugs, especially recent regressions. There's no shortage of them, you know.

I you can think of a better way to get kernel developers off their butts and actually fixing bugs, I'm all ears.

a) you're sitting around feeling very very very bored while

b) the kernel is in long freeze due to the lack of kernel developer attention to known bugs

The solution seems fairly obvious to me?

Most driver bugs cannot be reproduced by the developer. Almost by definition: if the patch had caused problems on the developer's machine, he wouldn't have shipped it.

This is why we have this wonderful group of long-suffering people who download and test development kernels for us, and who take the time to report defects.

Yes, it's painful to get into a long-range debugging session, sending debug patches, twelve-hour turnaround, etc. But what alternative have we?

The problem is that you usually cannot do proper bug fixing because the release might be just around the corner, so you typically chose the ugly workaround or revert, or just reject changes for bugs that a are too risky or the impact too low because there is not enough time to properly test anymore.

It might work better if we were told when the releases would actually happen and you don't need to fear that this not quite tested everywhere bugfix you're about to submit might make it into the gold kernel, breaking the world for some subset of users.

Nobody knows when a kernel will be released, because it's released according to perceived bug status, not according to a preconceived timeline.

I just don't buy what you're saying. Unless the kernel is at -rc3 or -rc4, we *know* the release is weeks away - it's always been thus.

Indeed - a prime example is the bootmem initialisation problem. Had I known on 1st October that the final release wouldn't have been for a long time, I'd have applied that patch and you wouldn't have had that problem with ARM relying on the bootmem initialisation order clashing with your ia64 (or x86_64) swiotlb fix.

But stupid rmk - again I hasten to add - was suckered into this "-rc is frozen" idea again and decided it wasn't appropriate to submit it. In hind-sight, there would have been plenty of time to sort out any issues.

Hell, we held up 2.6.14 for swiotlb _anyway_.

I'd say that was an *exception*, not a "prime example".

I've filed away 322 unresolved bug reports here. The great majority are busted drivers on random hardware dating back as far as 2.6.11. Many of them are regressions.

There is nothing stopping anyone from working with the originators to get these things fixed up at any time.

Why is it necessary for me to chase maintainers to get their bugs fixed?

Why are maintainers working on new features when they have unresolved bugs?

Why is it so often me who has to do the followup for un-responded-to bug reports against subsystems which I don't know anything about?

(Those are rhetorical questions, btw).

Because zero bugs is just unrealistic and they would never get anything done if that was the requirement?

(especially considering that a lot of the bugs at least on x86-64 are hardware/firmware bugs of some sort, so often it is not really a linux bug but just a missing ha^w^wwork^w^w^w^wfix for something else)

I agree regressions are a problem and need to be addressed, but handling all non regressions on a non trivial platforms is just impossible IMHO...

Perhaps it would be nice to have better bug classification: e.g. regression/new hardware/reported by more than one person etc. I think with some prioritization like that it would be much easier to keep the bugs under control.

Sometimes bugs are less important than others. e.g. on x86-64 the bootmem issue was obscure at best, affecting only a very small part of the user base. Sure the few people hit by it will be annoyed, but trying to make everyone happy is impossible so one has to try to just make the majority of users happy. So it was imho ok to just revert the patch to fix ARM again and not breaking IA64 (I cannot assess how many users were on ARM/IA64 affected) for the next release and try to sort it out later.

Regressions are important, everything else has to be prioritized based on the impact on the user base (and this doesn't necessarily mean the most noisy part of the userbase)

Perhaps some people could volunteer to set some flags in bugzilla for obvious things, like regression or new hardware or missing basic information or for really old kernel and no report for a new one and that could be used to filter the queries better. Should be an relatively easy task.

They may not be feature-equivalent in reality, but it's hard to generate something that has the features (or lack there-of) of old kernels these days. Which is problematic.

But some of it is likely also compilers. gcc does insane padding in many cases these days.

And a lot of it is us just being bloated. Argh.

I really don't see the point of shaving less than a kB with ugly calling convention magic, when switching to -Os can save us much more, and when the networking code is several hundred kB.

If we start doing size optimizations, we need to think big.

No, I think that's a lost cause.

It doesn't grow by 700 bytes once in a while. It grows by much more, and much more often. And we can't fight it that way, that's just not going to work. Maybe have something that tracks individual object file sizes and shames people into not growing them..

As mentioned at the kernel summit, we're working on it at the CE Linux Forum. These things take time to set up, but we have code already for something that tests the size impact of individual kernel configs, and we're working on a test to track individual function sizes for each new kernel (using Andi Kleen's bloat-o-meter).

We're still in process of setting up the test lab, but we have a number of hardware boards already, and we're hoping to be publishing size regression data for the kernel on a regular basis, starting in about April of next year.

The main reason it's taking so long is that it's a background task for everyone working on it. (Basically, me and one guy at NEC. ;-) We've gotten sidetracked with lab setup issues (signing a lease for office space, processing paperwork for board donations, etc. etc.) But I can run some tests now on a few different platforms just on my desk.

I had hoped to have at least some preliminary results by the end of November, with a bigger call for help inside the forum to finish up something big and professional-looking in April. However, maybe I can cobble together some things, and let people (both in and out of the forum) look at the preliminary results sooner.

I'll see what I can do by the end of November.

Here goes the second release candidate for v2.4.32.

The most significant changes are v2.6 backports of IPv4/IPv6 bugfixes, and a USB OHCI regression introduced during v2.4.28 which could lead to crashes on SMP kernels.

Aleksey Gorelov:
asus vt8235 router buggy bios workaround

Alexey Kuznetsov:
[TCP]: Don't over-clamp window in tcp_clamp_window()

Andrew Morton:
loadkeys requires root priviledges

Dan Aloni:
fix memory leak in sd_mod.o

Denis Lukianov:
[MCAST]: Fix MCAST_EXCLUDE line dupes

Herbert Xu:
Clear stale pred_flags when snd_wnd change

Horms:
[IPVS]: Add netdev and me as maintainer contacts
Fix infinite loop in udp_v6_get_port()

Julian Anastasov:
[IPVS]: ip_vs_ftp breaks connections using persistence
[IPVS]: really invalidate persistent templates

Marcelo Tosatti:
Change VERSION to 2.4.32-rc2

Marcus Sundberg:
[NETFILTER]: this patch fixes a compilation issue with gcc 3.4.3.

Nick Piggin:
possible memory ordering bug in page reclaim

Pete Zaitcev:
usb: regression in usb-ohci

Ralf Baechle:
AX.25: signed char bug

Willy Tarreau:
Fix jiffies overflow in delay.h

There is nothing else pending for v2.4.32 on my part.

Will wait a couple of days and tag it as v2.4.32.

Is there someone out there, with sharp zaurus sl-5500, willing to test kernels? There's a linux-z tree on kernel.org, which I try to more or less keep in sync with mainline, that is slowly starting to get usable. It could use some testing.

Main drawback is that battery charging is not yet done; touchscreen is there but I did not have chance to test it with proper userspace filtering.

This set of patches constitutes eCryptfs version 0.1. We are presenting it to be reviewed and considered for inclusion into the kernel.

eCryptfs is a stackable filesystem that is based off of the Cryptfs that is generated by the FiST stackable filesystem framework written by Erez Zadok:

http://filesystems.org/

eCryptfs stores cryptographic metadata in the headers of each file; the headers contain OpenPGP-like packets (see RFC 2440). This allows the encrypted underlying files to be copied between hosts, and all of the information necessary to decrypt the files stays with the files themselves. eCryptfs aims to make the encryption and the decryption of each individual file completely transparent to userspace applications, so long as the recipient has the requisite key or passphrase to access the file available.

Michael Halcrow presented eCryptfs at the 2004 and the 2005 Ottawa Linux Symposiums; the high-level overview from this year's symposium starts on page 209 of the first half of the symposium proceedings:

http://www.linuxsymposium.org/2005/linuxsymposium_procv1.pdf

Note that this set of patches contains a considerably trimmed-down version of eCryptfs than what was sent to the LKML earlier this year. Release 0.1 includes mount-wide passphrase support only; this will make eCryptfs easier to analyze and debug before the more advanced policy and public key features are merged in.

eCryptfs performs well under a variety of tests, including FSX and Connectathon (Basic and General functional). There is a bug that crops up on a kernel compile. We would appreciate any insight that the VFS guru's could give us in tracking down and fixing any extant bugs.

eCryptfs utilizes David Howells' keyring; at mount, eCryptfs version 0.1 expects an existing authentication token in the user's session keyring. The tarball containing the code to do this is available from the eCryptfs SourceForge site (ecryptfs-v0_1.tar.bz2):

http://sourceforge.net/projects/ecryptfs/

Future releases will have policy support, which will entail per-file passphrase and per-file public key support. Those who are interested in looking at that code are welcome to obtain it from the eCryptfs CVS repository on SourceForge:

cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ecryptfs login
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ecryptfs co -P ecryptfs

Yes. I don't think it's been heavily tested, but the very architecture of git should mean that there just shouldn't be any issues with binary files outside of the obvious ones.

The only binary file the kernel ever uses is the logo.gif thing, so it's been "tested" in the sense that binary files exist, but there's never been any changes to that file, so..

GIT 0.99.9c is found at http://kernel.org/pub/software/scm/git/ as usual. It includes the following fixes and documentation updates since 0.99.9b:

Alex Riesen:
remove CR/LF from .gitignore

Jon Loeliger
Illustration: "Fundamental Git Index Operations"
Illustration: "Git Diff Types"
Illustration: "Commit DAG Revision Naming"

Junio C Hamano:
Do not put automatic merge message after signed-off-by line.
git-clone: do not forget to create origin branch.
Make test-date buildable again.
Do not fail on hierarchical branch names.
Ignore '\r' at the end of line in $GIT_DIR/config
Be careful when dereferencing tags (credits Pasky).
Document --since and --until options to rev-parse.
Add --no-commit to git-merge/git-pull.
Add 'ours' merge strategy.
git-merge-ours: make sure our index matches HEAD
GIT 0.99.9c

Peter Eriksen:
Clean up the SunOS Makefile rule

The slow and steady march toward 1.0 continues.

I plan to do another full sweep in the documentation directory on my next GIT day.

On the proposed updates front, I am hoping to include Nick's http-push using DAV in the "master" branch soon. And I would appreciate somebody who actually uses svnimport to Ack on Yaacov's svnimport fix.

Here's an experiment I've been dying to try.

The current "tracker-less" BitTorrent employs a distributed hash table called Kademlia, where the total content is spread across a bunch of computers on the network. I kinda prefer TANGLE to Kademlia.

Anyway, I was thinking that it would be a neat experiment to add simple TANGLE-like peer-to-peer code, to enable git to query "the git network hash table" for content.

Comments, or any pre-code-creation objections? How easy is it to add a new storage backend to git?

To restrict unlimited uploading, I'm thinking that I'll want the system to fall back to {www,git,rsync}.kernel.org as the original source of content. [though the code will obviously be generic, and not hardcode *.kernel.org policy]

Almost everything is contained within sha1_file.c.

Object creation side is simple -- everybody who creates an object (e.g update-index registering blobs, write-tree writing the toplevel and intermediate level trees, commit-tree building a commit object, unpack-objects exploding a pack) goes through write_sha1_file(), which checks if the object is already available using has_sha1_file() and creates a new object in the local .git/objects/?? directory. I am assuming that you are not planning to create objects in a remote peer from within the git code path, and instead to have background process that replicate them over the network to peer repositories, so you probably do not have to touch this side.

Extending inspection and reading from existing objects for your networked storage may be somewhat messy, but starting points are:

• has_sha1_file() takes the object name and returns true/false; if the object is available to us in any form (be it in one of the alternate object stores or the local repository, as individual object in an objects/??/ file or stored in a pack). Currently it looks at packs and then checks individual files for performance reasons (to minimize seeks and to prevent polluting dcache with many negative hits); you would be adding another data source.
• read_sha1_file() takes the object name, and returns the uncompressed contents of the object in addition to the type and the size.
• sha1_object_info() takes the object name and returns the type of the object and optionally returns the size of it, without reading the contents. Some programs call this before reading the data using read_sha1_file(), so you might want to use this as a cue to prefetch from a remote peer; also you _might_ want to keep type and size cached if you plan to implement forgetful storage that deliberately loses objects and expects to refetch it from its peers. Good test program once you are done extending this part is git-cat-file with -t and -s flag.

The above three are the primary read interfaces, but there are some places that cheat by assuming that packs and individual objects are the only two kinds of sources for the object data, so you need to be careful. For example, write_sha1_to_fd(), which is used only by ssh-upload, first tries to call map_sha1_file_internal(), which is only valid for individual objects, to grab the object data, and when it fails, calls read_packed_sha1(), which is only valid for objects in packs, without even checking if read_packed_sha1() succeeded. This doesn't crash only because the caller of write_sha1_to_fd() checks if the object is available by calling has_sha1_file() itself before calling this function, but you would need to change it to fall back on your networked storage if you do not want to crash when used by ssh-upload.

HTH, and have fun.

I've got a small project in git where I made a dumb error. All my commits have author/committer information like this:

Author: Darrin Thompson <darrint@dhcp-1-211.(none)> 2005-10-20 16:50:38
Committer: Darrin Thompson <darrint@dhcp-1-211.(none)> 2005-10-20c16:50:38
Tags: svn-5099

I'd like to replace the commits (yes, I know that means all of them) with new ones with corrected email addresses and also manage to migrate my tags. A push in the right direction would be appreciated.

Next I'd like to do the same with the kernel sources... :-)

There's a program in the git sources called "git-convert-objects.c".

It basically knows how to walk the git object chains, and rewrite each object according to a few rules.

The rules currently do _not_ include changing the author/committer info, but it does know how to parse the really old-style dates, for example, which are on those same lines, so adding some code there to also re-write the author/committer name and email wouldn't be impossible.

The code isn't necessarily all that easy to understand, and usage-wise you also have to convert each head separately (you tell it which branch head you want to convert, it trawls every reachable object from that head, and will create the new objects and return the new head value).

What I'm trying to say is that it might not be _pleasant_, but it's certainly something you can automate and do in a timely manner (ie a small project will take just a few seconds - or minutes - to convert).

The same program will work, but it will take some time.

Actually, as long as you only rewrite commits, it should even be reasonably efficient. It's when you start rewriting every single object (like I did when I switched the compression scheme around) that it gets _really_ expensive, and a project like the kernel would take a long long time.

Hint to the wise: don't do the conversion on the only copy of the repository you have. It's always worked for me, but hey, maybe I'm just lucky and never write buggy conversion software.

Some people may have noticed the new git tree located at:

rsync.kernel.org:/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git

This tree will directly reflect the Ubuntu Linux Kernel that is available in our distribution (along with build system). First use of this kernel tree is slated for Dapper Drake (Ubuntu 6.04), and will stay synced with the just released 2.6.14(.y).

There are several reasons for making this repo available on kernel.org. Primary reasons include a more open development model, better visibility with the kernel developer community, and to make the kernel available to other distro's who may want to base their kernel off of ours.

Primary goals include:

• A kernel geared toward a real world Linux distribution, supporting drivers and subsystems that end users need. You will find a lot of external drivers in our tree, that for whatever reason, are not included in the upstream kernel. We hope that including these drivers will give users a one-stop kernel (no downloading and compiling external modules), and also provide much needed testing for modules hoping to be included into the mainstream kernel.
• Real world configurations. We will provide default kernel configs for a variety of architectures and system "flavors".
• Any feature and/or driver included will attempt to be configurable. That is, if you don't select to compile it, it will not cause any significant changes from the stock kernel we are using at that point.
• Open development model. We want to be as close to the kernel community as possible. Integrating ideas, getting feedback, and causing as little havoc as possible :)

GIT 0.99.9e maintenance release is found at the usual places:

RPM, tarballs, and deb:

http://www.kernel.org/pub/software/scm/git/

With git, fetch maint branch from

git://git.kernel.org/pub/scm/git/git.git/

It contains everything from the master branch. Since we seem to be shelving the separate git binary directory idea indefinitely, what we have here is pretty much what will be in 1.0, from the source code POV.

• http-push seems to still have a bug or two but that is to be expected for any new code, and I am reasonably sure it can be ironed out; preferably before 1.0 but it is not a showstopper.
• I've done the initial round of package splitting for Debian side myself, but it probably needs proofreading and fixing by experienced Debian person. Similar RPM package splitting that parallels the above is needed. Although it is not an absolute requirement for my sources to have perfect binary packaging support (I am just an upstream for binary packagers), it is certainly desirable to have RPM specs and debian/ files in a presentable shape for 1.0.
• I still need to go over the tutorial and core-ish documentation once for consistency checks.

Changes since 0.99.9d are:

Johannes Schindelin:
Allow GIT_DIR to be an absolute path
http-fetch: do not use curl_message after releasing it

Jon Loeliger:
Refactor merge strategies into separate includable file.

Junio C Hamano:
test: t4102-apply-rename fails with strict umask (Peter Baumann).
git-format-patch: silly typo fix.
Documentation: pull/clone ref mapping clarification (Josef Weidendorfer).
git-fetch: fail if specified refspec does not match remote.
Simplify CFLAGS/DEFINES in Makefile
Package split: Debian.
Install asciidoc sources as well.
Further Debian split fixes.
Debian: test build.
Merge in http-push first stage.
Document expat dependency when using http-push.
ls-files: --others should not say unmerged paths are unknown.
git-status: do not mark unmerged paths as committable.
Set up remotes/origin to track all remote branches.

Nick Hengeveld:
Add support for pushing to a remote repository using HTTP/DAV
Verify remote packs, speed up pending request queue
Support remote references with slashes in their names
Improve lock handling
Refresh the remote lock if it is about to expire

Paul Collins:
http-push.c: include with angle bracket, not dq.

Randal L. Schwartz:
Use fink/darwinport paths for OSX

Linus, please do an update from:

http://www.kernel.org/pub/scm/linux/kernel/git/bunk/trivial.git

I've taken over the trivial patch monkey from Rusty, and I'll send the really trivial patches like spelling corrections through this tree.

Is this tree OK or are there any problems with it?

Please don't try to make me update over http. Either point to master (which is not accessible by all), or point to git://git.kernel.org/. Or do both..

And if you do the latter (or, in fact, rsync or http for others), please make sure that you delay your "please pull" sufficiently that the contents have actually mirrored out, because otherwise, if the mail comes in while I'm in merging mode (like right now), and I try to pull, I may not have anything to pull at all just because it hasn't mirrored out yet.

A side comment (this was true with BK too): I prefer not to see unnecessary two-way merges, since that just makes the history much messier.

Here are the same "delete devfs" patches that I submitted for 2.6.12 and 2.6.13. It rips out all of devfs from the kernel and ends up saving a lot of space. Since 2.6.13 came out, I have seen no complaints about the fact that devfs was not able to be enabled anymore, and in fact, a lot of different subsystems have already been deleting devfs support for a while now, with apparently no complaints (due to the lack of users.)

Please pull from:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/devfs-2.6.git/
or if master.kernel.org hasn't synced up yet:
master.kernel.org:/pub/scm/linux/kernel/git/gregkh/devfs-2.6.git/

I've posted all of these patches before, but if people really want to look at them, they can be found
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-devfs/

Also, if people _really_ are in love with the idea of an in-kernel devfs, I have posted a patch that does this in about 300 lines of code, called ndevfs. It is available in the archives if anyone wants to use that instead (it is quite easy to maintain that patch outside of the kernel tree, due to it only needing 3 hooks into the main kernel tree.)

We (the -stable team) are announcing the release of the 2.6.14.1 kernel.

The diffstat and short summary of the fixes are below.

I'll also be replying to this message with a copy of the patch between 2.6.14 and 2.6.14.1, as it is small enough to do so.

The updated 2.6.14.y git tree can be found at:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/linux-2.6.14.y.git
and can be browsed at the normal kernel.org git web browser:
www.kernel.org/git/

Two small issues showed up,

• IPVS refcont leak
• unpriviledged virtual terminal ioctls should be allowed to read function keys

So here goes -rc3.

Attaching the full changelog since this is probably the last -rc release.