Hello, On Jun 2, 2011, at 18:32 , Douglas E. Engert wrote: > On 6/2/2011 9:22 AM, Martin Paljak wrote: >> On Jun 2, 2011, at 16:39 , Douglas E. Engert wrote: >> >>> Yes, the patch fixes the problem. Please commit it. >>> >>> Eric, >>> Since Debian is in the process of accepting 1.12.1, >>> (I saw your note from 02 Jun 2011 06:33:03 +0000 >>> 7 hours ago) and this bug will affect the use of OpenSC >>> with Kerberos/PKINIT with login or kinit, (and maybe other >>> applications) I would like to make sure that this patch >>> also gets in to Debian somehow.
This is a generic messup by me, but I'm not entirely sure it was *not* intentional, read below. >> >> OpenSC 0.12.2 will be released 10.06.2011. >> I guess that would be similarly OK ? > > Not sure. There appears to be a circumvention, (I need to > try it) and Debian and Ubuntu add patches between releases. > So does RedHat and I assume others. > > I would like to suggest that for future releases, we > discuss more about how we test release candidates. Agreed. Some more formal planning of "what gets released when" would also do good. That's in theory the "roadmap" in Trac but maintaining Trac has shown to require some work and input from people, which does not happen so often and easily. So the roadmap has turned up to be more like a "very rough plan of what could be in the pipeline". Maybe agitation to turn attention to it would be necessary every now and then on the list ? > On 4/29/2011 0.12.1-RC1 was based on #5409 > On 5/17/2011 0.12.1 was based on #5451 ... > So 42 changes were added, with no new RC. I would like to > suggest that if a RC has problems we fix these and come out > with a new RC, and we all test it again. The final release > should have only have one change from the last RC to change > the name by dropping the -rc* in the name. 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. > > I am not sure what is in the 42 changes since RC1, > but there should only be fixes needed for the RC, > and not improvements. I am not sure how #5421 fits in > to this, or if other changes were also introduced > that may have introduced other problems. > > I think we all (me included) can do a better job of testing. True. One of the steps is adding automatic tests, which in cases like this can be run against an "empty" PKCS#11 module as a smoke test. My personal goal for 0.12.1 was a fluid transition to nightly builds and automatic binary installers to the extent possible (only OS X lags behind because lack of resources, namely a dedicated OS X machine). Around the same time Debian packaging caught up so one way of interpreting 0.12.1 release is as a release candidate for the next version, which release date was intentionally fixed and set close to 0.12.1 release (10th of June, in 4 days). This means that all interesting parties should be prepared to catch up with the more smoothly rolling and more predictable (in terms of time) OpenSC release cycle, even though the period is set for a slow and easy summer and vacations period for the northern hemisphere. The next logical step is the transition to Git in the nearest future with staging builds or the "feature branches" which will be the base for release candidates and a step to a different direction from the "trunk based evolution". You could take the release mess-up as a (not so nice) method of triggering discussion on the topic ;) But I'll try to be more careful in the nearest future to avoid such mishaps. As always - any input in the mailing list, which could be transferred to documented approaches on Wiki, are most welcome. Best, Martin -- @MartinPaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
