Messages in this thread | | | Subject | Re: [PATCH]: How to be a kernel driver maintainer | From | Arjan van de Ven <> | Date | Sun, 08 Jan 2006 19:57:37 +0100 |
| |
On Sun, 2006-01-08 at 19:43 +0100, Arjan van de Ven wrote: > > 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, > > patches yes. but usually only small stuff > > > 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. > > that's different... that's a patch queue. That's not the same as being > the prime repository.
this deserves expanding.
What net/usb/scsi queue is *deltas* to the kernel.org kernel. This is fundamentally different from having the main driver be in its own repository. Each delta is meant to do a certain change to the driver, eg it's a CHANGE BASED thing. While "own repository" is "here is new code" (even though you can disguise it as changes pretty well). The linux development model is based on introducing changes, not on introducing new code (of course the difference goes away if you introduce a new driver, but that's a corner case)
The result is also highly different. In the net/usb/scsi case, there is no "we need to move changes in mainline to our tree or they get lost". The only thing needed would be resolving conflicts in the proposed changes in the subsystem maintainers queue and the changes already in mainline.
Note: this is independent of what kind of tool is used to store and distribute such changes. quilt and git are used most, but git can also be used in a CVS way if you want. But it's the "the main driver is in the kernel, and we have proposed improvements to it" that counts (versus "we have the main driver that we push to the kernel occasionally if we feel like it").
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |