Martin Paljak wrote: > 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. >
Does all the tasks, that have to be accomplished before the new release work can start, have corresponding tickets? (For example, it seems that we were talking about removing of pkcs15init framework and I do not see ticket). This question is because I'm interested to make a new release as soon as possible. It would be nice to define list of tasks to be accomplished before new release work can start . As for secure messaging, I propose to start to implement it in the separate branch, together with external authentication, qualified signature and multi-oncard-applications. That's because there are number of SM mechanisms, (one card can support two different SMs); also more or less general implementation will need considerable intervention into the libopensc. With the regards to the number of recent changes in the 'core', it seems reasonable to start this SM branch after the new release. > 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. > To the certain degree the goal is to 'compete', but mostly to 'complete' with the functionalities that are not supplied by official offer. Many actual cards declares compatibility with PKCS#15, and, as for me, OpenSC is quiet well positioned to be as an alternative or complementing middleware compatible with the official ones. Kind wishes, Viktor. -- Viktor Tarasov <viktor.tara...@opentrust.com> _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
