Jean-Michel Pouré - GOOZE wrote: > 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.
This is appropriate in my opinion, because I do not think that the commits are ready for inclusion in the main OpenSC repository, regardless of the fact that Viktor has included them in his. > He needs and deserves write access to OpenSC main GIT to speed up > development. I disagree, if he considers the epass2003 commits I looked at to be of acceptable quality. > The reasons is that we need more new features, more beta testers. You disregard the topic of code quality, which I think that is unacceptable in particular for a security related project. > 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. What? The reason is that, as you may know, OpenSSH is developed in the OpenBSD project, and their plans for PKCS#11 did not align with Alon's plans for OpenSSH PKCS#11 outside OpenBSD. > Locking a project to a small number of developers is not good. There is no locking. Please get that idea out of your mind. Everyone can create commits. But as I have tried to give several examples of, obviously not every commit should automatically be included in the main repository - which is in principle what you advocate. > 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. More code = more bugs. > This is no longer the case and each developers works in his corner. If that is the case, it is so because the active developers do not communicate with each other. As you've mentioned, communicating is important. Committing to the main repository is never the start of communication, it is what concludes communication. > The only collaborative work is what you call "peer review". I'm not sure how much review actually happens. > 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. Replace branch with repository and I see no problem. But sharing a sandbox is significantly less convenient than each developer having their own repository/ies, while also exchanging commits with each other. It is perfectly fine for each developer to have one or even more repositories. Please understand that this is the nature of git, and actually the nature of development work. One person has focus on one thing at a time, in their corner. After they finish, it is of course important to do show and tell, get review comments, rework the code, and repeat until consensus. > And make sure OpenSC is not only owned by one or two people. This > cannot ever happen, we don't agree with this privatization. Who are "we" ? I don't care if OpenSC has just one committer, as long as code quality is a high, if not the highest, priority. > The organization should be like: > * 4/5 committers > * 10/20 code contributors and developers > * 100 beta testers The problem with this organizational diagram is that neither you nor anyone else can magically generate competent developers with lots of spare time. People contribute what they can when they can. You can of course hire developers, but if your recruitment process is strict, so as to find only really competent developers, you will discover quickly that they are quite rare. //Peter
pgpBy0XBht722.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
