Hello, A question: how many current commiters don't yet use Git (and/or git-svn) for OpenSC development?
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 -- @MartinPaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
