On 6/2/2011 1:02 PM, Martin Paljak wrote: > Hello, > > A question: how many current commiters don't yet use Git (and/or git-svn) for > OpenSC development?
I don't but its time to convert. Are there any major changes or new cards that developers need to get in right now? If not this would be a good time to convert. > > OpenSC should move to DVC and because this requires changing the way > developers work and support infrastructure functions, it takes time and most > probably a few setbacks. IMO DVC related infrastructure is these days stable > enough to warrant a move the sooner the better, to "catch up with the rest of > open source scene" > > > Pros: > - no "gatekeeping" necessary in the development process which is mandated > by SVN > - maintaining the "who can commit to SVN" list is a politically unpleasant > activity even if done with full transparency and is a often a source of > distress and arguments. It is avoided in DVC by natural processes with the > help of technology. > - better separation from development and releasing > - more consistent new features and better differentiation between "bugfix > and typo commits" and "feature commits" > - requires more work for integration and releasing or more development > policies to make integration very straightforward. > > Cons: > - change in development tools and processes causes stress and discomfort > with developers > - SVN is a de facto standard for version control. Tool support is excellent > for SVN but sometimes lags behind for Git. > - But github support read-only access for Git through SVN, so that legacy > tools continue to work with minimal changes. > > I'd like to clean up the file structure of OpenSC source code to more > precisely reflect the nature of files and how it is built into binaries: > group common code, create a unified libopensc folder for both read only and > initialization code, separate drivers from "core framework", separate > "possibly exportable headers" from internal headers etc. Something similar to > Linux directory layout in spirit, but the utmost idea is internal cleanup and > visibility. This type of activity feels much better with Git than with SVN. > This cleanup could also serve as a starting point for re-exporting libopensc > interfaces in a controlled manner. > > So I think the easiest would be to start building current state from Git ASAP > and see how it goes. If the outcome is OK from Jenkins (I doubt there would > be problems on Linux or OSX, but expect some with Windows), then the internal > re-organization can be more easily done. > > Moving to DVC would change how the OpenSC "infrastructure" can help the > community. The central "build from SVN trunk for platforms" should be > replaced with "Build (feature) branches for developer for platforms" > approach, but eventually the documentation should be in a state that it would > be a no-brainer for even inexperienced non-developers to re-build OpenSC > installer for their platform in one (long) evening. Or so that taking over > OpenSC releases would be a no-brainer. It would also mean more self-control > from commiters and better communication and planning for releases (I would > basically see branches that "implement stuff" and branches that "contain > obvious bugfixes"). But Releases would be become more granular and the > availability of "feature branch builds" (like current OpenDNIe or for > MiniDriver or for anything that requires "substantial amount of work to get > implemented") would help to get the thing right before releasing to public. > > Please explain your thoughts, suggestions and fears in relation to moving the > documented contribution scheme to Git? > > Best, > Martin > -- Douglas E. Engert <deeng...@anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
