Nicely put. I like the way you are directing the project. On 6/7/2011 9:20 AM, Martin Paljak wrote: > 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
-- 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
