On 6/3/2011 2:12 AM, Viktor Tarasov wrote: > Le 02/06/2011 17:32, Douglas E. Engert a écrit : >> >> >> 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. >>> >>> 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. >> >> 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. >> >> 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 would propose to fork a branch for every release > and commit the 'fixes' into the both - 'trunk' and 'rcXX', > and commit improvements only into 'trunk'.
I know other projects do one commit then pull up selected changes for a release, thus avoiding two separate commits that could also introduce errors. > > It's difficult to find a time to make an 'improvement', > it's more difficult to coincide this time with a proper season for > 'improvement'. I agree. > > >> >> I think we all (me included) can do a better job of testing. We need to know who and what they are testing in an RC. What happened here was the last RC was not the same as the final release, so many changes were not properly tested. Testing from the RC also tests that the versions of the build tools used to build the release produce configure and Makefile.in files that will work in the field, where as building from the trunk, each developer may have different verisons of the auto* tools that work for them. > > Agree. > > > -- 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
