Jean-Michel Pouré - GOOZE wrote: > > With Git, anyone and everyone is a committer. > > The question here is flexibility:
What flexibility is needed? My point is that everyone can easily create perfect patches, and given perfect patches which have been peer reviewed there is no need for flexibility as in lots of people with write access to the main repository. Even just one person can easily handle that effort, like Linus shows in the much larger kernel project. > * OpenSC used to have a very flexible approach. OpenSC is NOT > kernel.org with thousands of developers and no need for hierarchy. OpenSC is smaller, but I do not agree that there is no need for any kind of hierarchy. Now, please understand that this is not about power hierarchy as in politics, but it is about technical experience with the code and with the problem domain. I am personally familiar with the smart card domain but I haven't spent much time with the OpenSC codebase and therefore I absolutely do not want some patch I create to be included without being reviewed first. The review is criticial. Especially in a codebase like OpenSC, to which I might indeed delegate my legal authority, I want the review to be merciless. Don't make the mistake of believing that only people with write access can do review. It is quite the opposite. I have been trying to make this point many times before, but it seems difficult for many to grasp that all peer review is helpful and important for the codebase, regardless of who is doing it. Everyone who cares about a software can and should help with review. A side effect of doing review is of course that knowledge about the codebase increases in the community. After having done some amount of review, people might even get write access, because they have demonstrated that they can be trusted. This is demonstrated by finding difficult-to-spot problems in others' patches. It is not demonstrated by quickly giving every patch a thumbs-up. Some say that it feels pointless to do review for someone who does not have write access. I disagree with this, and I think this is a very dangerous, almost complacent, attitude. If you do not believe that your review is worth anything to those with write access, why should you yourself have write access? This becomes a negative spiral where in the end a project has no resources to do review, simply because people do not have enough self-esteem to believe that the review they can contribute matters. I don't know what the answer is. I've tried time and time again to convince people that doing review is helpful and important and a significant contribution to any project, but it often doesn't really stick. > * Setting-up a compilation farm is no reason for closing write access > to historical developers of OpenSC. I agree, but I don't think one has anything to do with the other, even if they happened at the same time. I guess that anyone who had write access to the repository earlier can get it again if they just send a public ssh key and their prefered username. > * Discussions are the base of Free Software. Once discussions have > occurred, there should be several people with write access. You > have to trust people. No need to lock write access to the main GIT. I disagree about having to trust people out of the blue. Generally, people write really shitty software, and the poor way that a lot of open source software works is all the proof we need. I love open source, not neccessarily because it is technically superior, but because it allows *me* to fix things which are broken. I believe that open source is as good as it is primarily thanks to the practise of peer review. The purpose of more write access as far as I can see is to have faster, ie. less well reviewed and thus less well understood, changes in the main repo. I do not agree at all with that goal. > From my point of view, OpenSC is becoming a semi-private project > with two people in charge: Ludovic and Martin. Personally, I don't > want OpenSC to be organized the same way as libccid. I find both Martin and Ludovic to be quite reasonable people. I've never had any problem discussing any issue with them, actually quite the opposite. If there are perfect patches (well reviewed, well understood) then I am convinced that they would race each other to add those patches into the repository. I have no experience from libccid development, but I'm happy with it as a user, so Ludovic must be doing something right. > We demand more freedom and transparency or this can only lead to > endless flamewars. Let's focus on a concrete problem. Have you created a patch which has been peer reviewed and is well understood, but has been rejected by Martin and Ludovic? If yes, let's try to find a solution. If no, you can't really demand more freedom and transparency, because you haven't exercised the freedom to create perfect patches yet. I did review the epass2003 commits when their availability was announced, and I've looked at the entersafe github account again just now. Here is some feedback: There are three branches; ePass2003_1, epass2003 and ep2k3. These names are non-descript. Commit 902e637c is quite long with over 2k lines added for the card driver. That seems much to me. It's infeasible for me as careful programmer but OpenSC internals newbie to review this code. My gut feeling is that much of the code could be factored out. The commits are not very well described in the commit messages. The commits include unrelated changes. The commits include whitespace changes mixed with actual code changes. The following commit undoes some of the unrelated changes in the previous one. This is what was immediately obvious to me just by looking at one and a half commits in one of the branches. The things I point out above are all things which do not belong in a perfect patch, and do not beling in the OpenSC codebase that I want to use. All these things, and probably more!, must be obvious to any other programmer who has looked at the commits. I do not believe that I have some special vision and only I can see these things. It seems to me that the commits have been created without self-review, which is of course the very first thing to do before proposing any change for inclusion. > Keep in mind that before doing business, I have been a politician > fighting during 4 years for more freedom. I did not know - that is quite commendable! Thank you for working on making the world a better place! Keep in mind that open source is not a democracy. > Now I am retired, but if need be, we will create a charity for > OpenSC and organize a duly elected board. I am not talking about > a fork, which will never happen, but about elections. But elections do not increase code quality. I think software quality is more important than flat democracy. The meritocracy that is open source *is* a hierarchy. I don't think this is bad. //Peter
pgpjJRbJWhQzz.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
