public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ben Collins <ben.collins@ubuntu.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Linux Kernel Development <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@osdl.org>
Subject: Re: [PATCH]: How to be a kernel driver maintainer
Date: Sun, 08 Jan 2006 13:27:50 -0500	[thread overview]
Message-ID: <1136744870.1043.4.camel@grayson> (raw)
In-Reply-To: <1136737997.2955.10.camel@laptopd505.fenrus.org>

On Sun, 2006-01-08 at 17:33 +0100, Arjan van de Ven wrote:
> 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. 

But this isn't at al true. Almost all subsystems maintain the primary
tree outside of the kernel, with the kernel being the primary _stable_
tree. USB, Netdev, Alsa, etc. All changes go someplace else before being
pushed to the primary kernel tree. 99% of the time, patches are going
somewhere else before going into the main kernel. So the above
paragraphs is really misleading.

-- 
   Ben Collins <ben.collins@ubuntu.com>
   Developer
   Ubuntu Linux


  reply	other threads:[~2006-01-08 18:28 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-08 16:07 [PATCH]: How to be a kernel driver maintainer Ben Collins
2006-01-08 16:33 ` Arjan van de Ven
2006-01-08 18:27   ` Ben Collins [this message]
2006-01-08 18:43     ` Arjan van de Ven
2006-01-08 18:57       ` Arjan van de Ven
2006-01-09  9:51       ` Joel Becker
2006-01-08 21:45 ` [PATCH updated]: " Ben Collins
2006-01-09  7:46   ` Arjan van de Ven
2006-01-09 13:34     ` Ben Collins
2006-01-09 14:02       ` Grant Coady
2006-01-09 21:28       ` Arjan van de Ven
2006-01-10  0:09         ` Linus Torvalds
2006-01-10  0:58         ` Ben Collins
2006-03-08 18:03         ` [Updated]: How to become " Ben Collins
2006-03-08 19:05           ` Jesper Juhl
2006-03-08 19:10             ` Arjan van de Ven
2006-03-08 19:27               ` Jesper Juhl
2006-06-02 21:38                 ` [Updated v3]: " Ben Collins
2006-06-02 22:16                   ` Randy.Dunlap
2006-06-03  0:03                   ` Greg KH
2006-06-05 10:27                   ` Jan Engelhardt
2006-03-09  4:32           ` [Updated]: " Randy.Dunlap
2006-01-08 21:47 ` [PATCH]: How to be " Ben Collins
2006-01-09 19:26 ` Pavel Machek
2006-01-10 15:10   ` Ben Collins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1136744870.1043.4.camel@grayson \
    --to=ben.collins@ubuntu.com \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox