Hello, On Mar 31, 2010, at 17:51 , Jean-Michel Pouré - GOOZE wrote: > For information, when do you plan to release the next OpenSC version? That's a good question what I've wanted to write about ASAP.
> I am just asking this question because the SVN version seems to fix > several important issues for me: > > * OpenSC and OpenCT conflicts. Please describe, I'm not aware of it? > * RSA key transfer from FEITIAN PKI to smartcard (Linux, Mac). What is this (FEITIAN PKI) and why it does not work currently? > * Several readers connecting simultaneously. That looks like a ghost bug to me... Are you sure it exists in 0.11.13 and not in SVN? > On Gooze.eu, I explain how to compile from SVN. But binary packages in > distros would be better. Only Linux distros have the requirement to synchronize our releases with their release plans. For example, there's no need to rush in case of Ubuntu, as they have very precise release roadmaps and none of their deadlines is in near future. Debian SID is again a different story. Don't know about Fedora/Suse etc For OS X and Windows, we need to provide installers ourselves and there it does not matter, feature-completeness driven releasing works just fine. You can generate snapshots if you dislike building from SVN, which should not be the preferred method for "end users" anyway. Why don't you use/reuse/update/improve the installation instructions in the OpenSC wiki? http://www.opensc-project.org/opensc/wiki/CompilingInstalling should be the page that describes compilation on *nix platforms (but not OS X), the Windows/OSX information should be moved to an "(soon)obsolete information" page. I wrote down on the roadmap page what I personally would consider would look like a successful release: http://www.opensc-project.org/opensc/roadmap I set the date for 0.12.0 to be 21.06.2010 which is the end of astronomical spring and usually a happy celebration day in the northern hemisphere. It does not mean that it should be released on that date or so late in the spring, nor should it be rushed, as 0.12 has some major changes both inside and outside, distros need to adapt anyway. I just think that it is reasonable to think that "it will take some more time, but not half a year" Even though the outside interface is now "fixed" to be PKCS#11 and thus we can re-arrange the internals however we deem necessary in the future, it would be good to shift around as much as possible now, for example make sure what has to be changed to successfully support secure messaging, get rid of some unused "frameworkisms" in the PKCS#11 module etc. Basically do whatever seems necessary to clean the codebase up and refresh and reflect the current state of the smart card ecosystem (like a default single reader subsystem and libopensc-openct, libopensc-ctapi, and libopensc-multi packages, as 90% of people only need PC/SC and we can't implement/support all features expected by casual end users in a super-flexi-ultra-forward-looking-framework-framework). Such pretty unpredictable things aside, the measurable successful release would be one that really has all the broken pieces accounted for, this includes all floating around patches reviewed and either integrated, postponed, invalidated or modified to be usable, at least dealt with. And all actionable tickets dealt with. It all takes time. Yes, there are reasons to release early and often, and we should release -beta/-pre/-rc packages earlier. Especially if picking a fight with the Portuguese government about their use of OpenSC and at the same time not having a release of Portuguese eID support (which exists, but only in the trunk) might look silly or at least not well planned. But it would be nice if a "major" version release would look qualitatively different to the end user, not just a small incremental diff. And it requires If a goal is to "compete" with commercial/official offerings (in case of eID cards, it is the "official software" we're competing against, like in Spain or Portugal or Estonia or Belgium) we need to be on par with the usability of their offerings, which lags behind a lot, even if they actually use OpenSC internally. This is what I think. What do YOU think? -- Martin Paljak http://martin.paljak.pri.ee +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
