In general, the announcement of a new -rc kernel gives some hints when that -rc kernel may be the last one.

The required procedure, on subsystem trees is that:

a) During -rc period (e.g. latest main kernel available is 2.6.x, the latest -rc kernel is 2.6.[x+1]-rc<y>):

fix patches for the -rc kernel (2.6.[x+1]) should be sent upstream, being a good idea to send them for some time at linux-next tree, allowing other people to test it, and check for potential conflicts with the other arch's;

patches for 2.6.[x+2] should be sent to linux-next.

b) the release of 2.6.[x+1] kernel:

closes the -rc period and starts the merge window.

c) During the merge window:

the patch that were added on linux-next during the -rc period for 2.6.[x+2] should be sent upstream;

new non-fix patches should be hold until the next -rc period starts, so, they'll be added on 2.6.[x+3];

fix patches for 2.6.[x+2] should go to linux-next, wait for a few days and then send upstream.

d) the release of 2.6.[x+2]-rc1 kernel:

the merge window has closed. No new features are allowed.

the patches with new features that arrived during the merge window will be moved to linux-next

So, in other words, as currently x=32, and we are at the -rc period, being that the latest stable kernel is 2.6.32 and the latest -rc kernel 2.6.33-rc5, we are receiving patches for new features that will be available on kernel 2.6.34. After the release of 2.6.33, new features we receive will be added on 2.6.35.

In other words, the features being developed are always meant to be included on the next 2 kernels.

In the specific case of new drivers that don't touch on existing features, it could be possible to send it during the -rc period, but it is safer to assume that those drivers should follow the above procedure, as a later submission may be nacked.

Sometimes, a fix patch corrects a problem that happens also on stable kernels (e. g. on kernel 2.6.x or even 2.6.y, where y < x). In this case, the patch should be sent to stable@kernel.org, in order to be added on stable kernels.

In the case of git-submitted patches with fixes, that also need to be send to stable, all the developer needs to do is to add:

CC: stable.kernel.org

At the patch description. At the moment the patch reaches upstream, a copy of the patch will be automatically be sent to the stable maintainer.

KERNEL DEVELOPMENT PROCEDURES FOR V4L/DVB

That's the RFC on how we should work with -git.

1) fixes and linux-next patches

One of the big problems of our model is that we're using just one tree/branch for everything, with mercurial. This makes hard to send some fix patches for 2.6.[x+1], as they may have conflicts with the patches for 2.6.[x+2]. So, when the conflict is simple to solve, the patch is sent as fixes. Otherwise, it generally is hold to the next cycle. The fix patches should be tagged by the developer with "Priority: high" on mercurial.

Unfortunately, sometimes people mark the driver with the wrong tag. For example, I merged on Jan, 22 a patch marked with "high" that doesn't apply at the fixes tree. This patch fix a regression introduced
by a driver that weren't merged yet, so, the patch were added as normal patch.

How to solve those issues?

Well, basically, we should work with more than one tree (or branch), on upstream submission:

While we'll keep accepting patches via -hg, due to the merge conflicts its mentioned, the better is that, even those developers that prefer to develop patches use the old way, to send us the fixes via -git. This way, if is there a conflict, he is the one that can better solve it. Also, it avoids the risk of a patch being wrongly tagged.

Also, after having a patch added on one of the above trees, we can't simply remove it, as others will be cloning that tree. So, the only option would be to send a revert patch, causing the patch history to be dirty and could be resulting on some troubles when submitting upstream. I've seen some nacks on receiving patches upstream from dirty git trees. So, we should really avoid this.

2) how to submit a -git pull request

As the same git tree may have more than one branch, and we'll have 2 -git trees for upstream, it is required that people specify what should be done. Internally, my workflow is based on different mail queues for each type of requesting I receive. I have some scripts here to automate the proccess, so it is important that everyone sends me -git pull requests at the same way.

So, I'm basically proposing that a -git pull request to be send with the following email tags:

The from line may later be used by the git mailbomb script to send you a copy when the patch were committed, so it should be your real email.

The indication between [] on the subject will be handled by my mailer to put the request at the right queue. So, if tagged wrong, it may not be committed.

Don't send a copy of the pull to my addresses. I'll be filtering based on the subject and on the mailing list. If you send a c/c to me, it will be simply discarded.

NEVER send a copy of any pull request to a subscribers-only mailing list. Everyone is free to answer to the email, reviewing your patches. Don't penalty people that wants to contribute with you with SPAM bouncing emails, produced by subscribers only lists.

When a patch touches on other subsystem codes, please copy the other subsystem maintainers. This is important for patches that touches on arch files, and also for -alsa non-trivial patches.

The email should be generated with the usage of git request-pull:

git request-pull $ORIGIN $URL

where $ORIGIN is the commit hash of the tree before your patches, and $URL is the URL for your repository.

For example, for the patches merged directly from -hg on my -git trees on Jan, 22 2010, the above commands will produce:

This helps to identify what's expected to be found at the -git tree and to double check if the merge happened fine.

3) Tags that a patch receive after its submission

This is probably the most complex issue to solve. So, I'd like to see some suggestions here.

Signed-off-by/Acked-by/Tested-by/Nacked-by tags may be received after a patch or a -git submission. This can happen even while the patch is being tested at linux-next, from people reporting problems on the existing patches, or reporting that a patch worked fine.

Also, the driver maintainer and the subsystem maintainer that is committing those patches should sign each one, to indicate that he reviewed and has accepted the patch.

Currently, if a new tag is added to a committed patch, its hash will change. I saw some discussions about allowing adding new tags on -git without changing the hash, but I think this weren't implemented (yet?).

The same problem occurs with -hg, but, as -hg doesn't support multiple branches (well, it has a "branch" command, but the concept of branch there is different), it was opted that the -hg trees won't have all the needed SOBs. Instead, those would be added only at the submission tree.

With -git, a better procedure can be used:

The developer may have two separate branches on his tree. For example, let's assume that the developer has the following branches on his tree:

media-master (associated with "linuxtv" remote)

fixes

devel

His development happens on devel branch. When the patches are ready to submission will be copied into a new for_submission branch:
git branch for_submission devel

And a pull request from the branch "for_submission" will be sent.

Eventually, he'll write new patches on his devel branch.

After merged, the developer updates the linuxtv remote and drops the for_submission branch. This way, "media-master" will contain his patches that got a new hash, due to the maintainer's SOB. However, he has some new patches on his devel, that applies over the old hashes.

Fortunately, git has a special command to automatically remove the old objects: git rebase.

All the developer needs to do is to run the commands bellow:

git command

notes

git remote update

to update his remotes, including "linuxtv"

git checkout devel

move to devel branch

git pull . media-master

to make a recursive merge from v4l/dvb upstream

git rebase media-master

to remove the legacy hashes

After this, his development branch will contain only upstream patches + the new ones he added after sending the patches for upstream submission.