[announce] changes on my git tree

[Mauro Carvalho Chehab <mchehab@redhat.com>]

Dear developers and users,

After merging patches directly on my git tree, I was impressed by the number
of things I discovered that I should not do when handling it ;) 
Living and learning :)

There are lots of trash there, due to the way patches get merged back from
upstream.

As reverting a patch there will break things for everybody that clones from
my tree, I decided to go to an easier way: let's start from scratch.

I've created a new tree, at:
	http://git.linuxtv.org/media_tree.git

Currently, it is just a clone of Linus tree, all pointing to v2.6.35. I'll soon
be adding more patches there.

In order to avoid the same kind of troubles I had in the past, I intend to
use the following guidelines:

1) branch "master" - will have the contents of Linus tree.
2) branch "staging/2.6.35" - will have patches for the current stable kernel;
2) branch "staging/2.6.36" - will have patches for the current development cycle;
3) branch "staging/2.6.37" - will have patches for linux-next

On every new kernel release, I'll create another branch.

No branches will be rebased, but I won't merge from a staging branch into
master. If needed, I'll just update master to from Linus tree after having
a changeset pulled there.

As need arises, I'll be adding some development branches there with stuff that
are already accepted, but there are still pending patches that are needed before
sending that patch set upstream (for example, new internal/external API's
added, while there's no driver actually using them).

For those that already sent me pull requests, and for a few weeks, there's no
action need. I'll be manually handling the tree differences for a while. Yet,
the better is to rebase your trees using the new one as the basis.

Except when needed (like depending on a third-party patch applied on my tree), 
the better is to have your local git trees always based on master.

Cheers,
Mauro.