Hi Sebastian, Sebastian Haas wrote: > Oliver Hartkopp schrieb: [snip] > So we have the benefits to have a local repository were the developer can > work on > and creating and submitting patches becomes easier. Would be fine. > >> For me the current process could be: > >> * For new drivers (like ems_usb.c): > >> 1. Post source as a diff to net-next-2.6 on SocketCAN Core ML >> 2. Make some reviews. Still needed changes: goto 1 >> 3. Post source as a diff to net-next-2.6 on netdev ML >> 4. Make some reviews. Still needed changes: goto 1 or 3 >> 5. Acked-by: Wolfgang >> 6. Done Mainlining >> 7. Apply source to out-of-tree-repository >> 8. Add backward compatibility stuff >> 9. Done > I don't like 8. This sounds simple for a simple network driver, but becomes > un- > maintainable for complex drivers like an USB device driver or PCMCIA board.
Almost nobody is working with the bleeding edge kernel and there is some real benefit for the users providing backward compatibility. This does not mean that we spend time for providing support for very old kernels, at least not without real demand. Oliver introduced: #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,22) #error This driver does not support Kernel versions < 2.6.22 #endif which makes clear what kernel versions are supported. [snip] >> And in most cases the developer can post git-patches based on net-next-2.6 >> which becomes the leading development repository. > Great. > >> It is no big difference then whether the out-of-tree-repository is a SVN or a >> GIT then. I could live with both of them. > It's not a difference for you, I know. ;-) But I guess persons without write > access to SVN prefer a local GIT repository to better keep track of their > modifications and submitting their patches. We all known the advantages of git and that's why I said it's a valuable option. >> Looks the described process sane to all of you? > Let summarize: > Work on already mainlined drivers or new drivers is done on net-next-2.6. Not > yet > mainlined drivers becomes ready for mainlining in the out-of-tree repository > which > we move to GIT. In principle yes, but it's not a real requirement that the driver must first be for the SVN trunk. Patches directly for net-next-2.6 are accepted as well, of course, if they are OK. See the ti_hecc driver posted recently. When it gets accepted, it's not a big deal to adapt it for the out-of-tree SVN code. > Ok for me. > > There is another option (just a thought worth). The staging-tree is indented > for > drivers which are not yet ready for kernel inclusion. This criteria matches > for all > currently not yet mainlined drivers. Why not moving them to the staging tree > so > we have all drivers in net-next-2.6? This would also increase the audience of > kernel > developers which may take look at this drivers to help us, getting them out > of staging? Honestly, it's a *waste* time and I also do not want that pre-mature and buggy drivers enter the mainline kernel. I'm really surprised that it's possible at all. Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
