Hi Jan-Niklas, On 10/05/2011 01:17 PM, Jan-Niklas Meier wrote: > I am watching the SocketCAN project from a user point of view and if I > wouldn't have known some people like Oliver who explained all the cool > features to me I probably never would have used SocketCAN. > I think it is good that Berlios is closing and it is time for something new. > Mailing lists, diffs and SVN are technologies that surely worked well for > years but there are new ways to do collaborative coding. > If you want the young and wild web2.0 guys like me to find interest in this > project I suggest a new way.
Well, maybe I'm already to old for that stuff. Anyway, the interest in this project should not depend on the tools we use for development ;-). > I talked with Oliver about my ideas and he said I should post theme here. So > here it goes: > > - use git as the version control system (many git-SVN comparisons on the > internet; I think it _really_ is the way to go; kernel using git) Yes, *abandon* SVN in favor of GIT is what we want do since a while. > - use GitHub as the hosting platform > > - create a SocketCAN 'team' at GitHub containing the core developers who had > write access to the SVN (https://github.com/features/projects/collaboration) That's what we already have on BerliOS and what we can't do with kernel.org accounts and facilities (because they are per maintainer/user), > - create two projects associated with the team: > > 1. 'SocketCAN' with the current state of the SocketCAN-tree in the kernel > (not what is currently in the SVN). All patches should go here and for a > kernel update the changes should be pulled from this repository. Every user > like me can fork this project, commit changes and send a pull request to the > main repository. The core developers review the pull request, discuss it and > accept it or not (https://github.com/features/projects/codereview) Maitaining our own GIT kernel tree, that's what we tried to avoid so far as it means substantial effort. Pushing SocketCAN related patches mainline through the netdev mailing list and David Miller's net-(next-)2.6 tree works fine. Furthermore, we still need the out-of-kernel Socketcan tree, mainly for backward compatibility. > 2. 'can-utils' containing the content of the current SVN > > - use the integrated wiki functionality of GitHub for documentation ( > https://github.com/features/projects/wikis) Do we need a separate project to handle the kernel and utilities? > > - use the integrated issue tracker ( > https://github.com/features/projects/issues) Yep, a bug tracking system would be nice to have. > - possibly use github pages (http://pages.github.com/) for general > information about the project, logos, link to mailing list, can-utils > binaries etc.) > > - possibly buy a domain and redirect it to these pages I have some free time but no free money ;-). > - don't discuss patches on the mailing list but do it inline on github. This > is really cool! https://github.com/features/projects/codereview Cool stuff, indeed, which might even allow efficient community development. But I hesitate to base my work on external tool/frontends. > - this way everything is in one place which is very handy for new developers > and users A one place solution has advantages but I would prefer SourceForge or GNU Savanna. > > - this is not a 'GitHub-only' solution because core developers can still > pull changes from every other git repository OK. > No I am not getting money from GitHub but I am convinced that the features > they are offering are really great and fun. Of course. > Just my two cents ;) Thanks for you input. Wolfgang. _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
