Re: [PATCH]: How to be a kernel driver maintainer

[Arjan van de Ven <arjan@infradead.org>]

On Sun, 2006-01-08 at 11:07 -0500, Ben Collins wrote:
> 
> +The other side of the coin is keeping changes in the kernel synced to
> your
> +code. Often times, it is necessary to change a kernel API (driver
> model,
> +USB stack changes, networking subsystem change, etc). These sorts of
> +changes usually affect a large number of drivers. It is not feasible
> for
> +these changes to be individually submitted to the driver maintainers.
> So
> +instead, the changes are made together in the kernel tree. If your
> driver
> +is affected, you are expected to pick up these changes and merge them
> with
> +your primary code (e.g. if you have a CVS repo for maintaining your
> code).
> +Usually this job is made easier if you use the same source control
> system
> +that the kernel maintainers use (currently, git), but this is not
> +required.

I don't quite agree with this part. This encourages cvs use, and "cvs
mentality". I *much* rather have something written as "the primary
location of your driver becomes the kernel.org git tree. This may feel
like you're giving away control, but it's not really. If you maintain
your driver there, people will still send patches via you for
approval/review. Of course you can keep a master copy in your own
version control repository, however be aware that most users will see
the kernel.org tree one as THE drivers. In addition, merging changes and
keeping uptodate is a lot harder that way. And worse, keeping the "main"
version outside the kernel.org tree tends to cause huge deviations and
backlogs between your main tree and the "real" kernel.org tree, with the
result that it becomes impossible to find regressions when you DO merge
the changes over.