Hello, On Jun 6, 2011, at 17:46 , Douglas E. Engert wrote: > On 6/6/2011 8:52 AM, Martin Paljak wrote: >> This is a generic messup by me, but I'm not entirely sure it was *not* >> intentional, read below. > > I agree, it is what OpenSC has been doing since I got involved, > basically take what was in the trunk and produce a release.
Uncertainty with releases has caused issues in OpenSC before. Some tries with branch based development in SVN have not been IMHO very successful except maybe for the given developer himself, mostly because merging back and forth and tracking changes is a pain with SVN and distributing/building branches for testing purposes has been a pain (especially on/for Windows or OS X, which all developers don't have at hand). Thus concentrating on trunk has seemed a logical step, as "this is anyway the place where everybody else work as well". While the community of OpenSC is not that huge then keeping focus on "trunk" will remain a priority, but spreading the focus a *little* would do good. By using some technical tools to help fix the shortcomings, namely Git for helping with the branching/merging and code mangling and Jenkins with automatic builds for a bunch of "meaningful branches" in addition to trunk/master. And work to make maintaining the feature branches in a stage that ease merging back and forth, which will *require* some internal re-arrangements to better structure the code. Carrot and whip case, maybe. > What I am trying to point out is that OpenSC has become the > defacto open source smartcard provider and we need to > treat it as such. Its more then a just package for smartcard > hackers to try and add their own card for their personal use. Nice way of saying it, I believe this is a sign that a) smart cards in fact *are* becoming a commodity and b) OpenSC has a meaningful position in the ecosystem (even if not perfect by nature). Which also means everyone should try hard to make it even better. > As such we need to have better testing on what gets released. > This is especially true, as no one developer has all the cards > that are supported, and thus testing relies on all of us > to test our part before a release. I still hope for automated test script running against a set of cards to report a personalize+user or plain use cycle on a nightly basis or so. But it will come when the time is right. And grouping of thing to be released through branches (which are way more functional in Git than in SVN) is another way of achieving this. As said before: "more granular releases and better visibility". >> The "branch" based development in OpenSC has not turned out to be very >> successful. Even if development is easy, delivering it for testing is >> cumbersome and tracking merges in SVN not only requires adequate >> (documented) processes, it even requires special software (think: >> svnmerge.py) to be effective. Also, even though smart cards related software >> is often very inert and for example even buggy cards need to be supported >> for several years (until certificates expire or new cards are issued or >> similar), it is a client-side software that should ideally be distributed >> like Google Chrome - with transparent continuous updates, if all succeeding >> versions are mostly functionally equivalent with previous versions. >> >> Thus I personally actually like the "linear" development/release cycle which >> ideally with SVN with the ever-increasing "revision number". But the >> "trunk" centric development with release branches is IMHO not very >> effective. I'd prefer more granular merges with Git instead. >> > > That is fine too. It requires developers to hold off on new features while > a release is being prepared. The group of developers is small enough > that this could be done. What I meant with "linear" development (actually linear releases) was that IMO it is not optimal to create and maintain several *parallel* minor/major versions with several build/fix revisions, where the logical step to fix an issue would be installing the next release, that should contain any necessary fixes AND any additional features. The interfaces OpenSC caters to (PKCS#11, CryptoAPI, CDSA/tokend) should be quite stable, thus no need to maintain longstanding branches (think: php? vs Apache x.y) Work on easily testable features (meaning deliverable testable binaries containing any new features) should not in any way be hindered by release processes. Best, Martin -- @MartinPaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
