Le 19/02/2012 10:50, Peter Stuge a écrit : > 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 ePass2003 commit has been re-factored before creating the SM+ePass2003 branch, to make it compatible with the general SM framework and to correct some of the coding style issues. https://github.com/viktorTarasov/OpenSC/commits/include-ePass2003 >> 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. Just to remind, the overwhelming part of the ePass2003 commit is concentrated in it's own new module (card driver) . >> 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 > > > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
