Dear Peter, Thank you for your time. In organization theory, there is no perfect solution. There are several ways to achieve success.
Let us take two examples to see how OpenSC can be improved: 1) The ePass2003 code was reviewed by Viktor and included in his branch. You probably did not know, did not compile, did not test and therefore Viktor's work is ignored. He needs and deserves write access to OpenSC main GIT to speed up development. The reasons is that we need more new features, more beta testers. 2) Take the example of Alon developments around PKCS#11. A lot of them were ignored by OpenSSH. The reason is that when a small number of people have a grasp on a project, strange things sometimes happen. I would not like this to happen with OpenSC. Locking a project to a small number of developers is not good. IMHO, the way OpenSC used to be organized one year ago was superior, because there was a central repository with all new features. More beta features, more testers, larger market and superior quality. This is no longer the case and each developers works in his corner. The only collaborative work is what you call "peer review". So my opinion would be to allow each developer to commit changes to the main GITHUB staging (developing) branch after discussion. Like it used to be the case using SVN. And make sure OpenSC is not only owned by one or two people. This cannot ever happen, we don't agree with this privatization. The organization should be like: * 4/5 committers * 10/20 code contributors and developers * 100 beta testers Kind regards, Jean-Michel
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
