OpenSC write access to main trunk, discussion
Locked
123
123
OpenSC write access to main trunk, discussion
 
|
Dear all,
I just got in contact with Stef Walter, who is integrating libp11-glue into Gnome and Gnome keyring. He outlines that libp11-glue needs this patch: PKCS#11 module shouldn't fail if mlock doesn't work http://www.opensc-project.org/opensc/ticket/389 This patch and other waiting patches raise the question of OpenSC guidance and the need to have more commiters to OpenSC main GIT. Martin, would you agree to add Viktor as a major OpenSC GIT member with power to apply patches to main GIT trunk? I don't want to be paranoid, but we need a more flexible approach rather than just Martin and Ludovic applying and reviewing patches. We discussed that at FOSDEM in a small audience, but I would like to discuss that issue in public and have your own opinion. Who would like OpenSC GITHUB to be REALLY in control of the community? Martin and Ludovic, could you agree to open your group to other members of the community? Community, please advice and discuss this issue. Kind regards, Jean-Michel -- Jean-Michel Pouré - Gooze - http://www.gooze.eu _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
smime.p7s (8K)
Re: OpenSC write access to main trunk, discussion
|
|
Re: OpenSC write access to main trunk, discussion
|
|
Re: OpenSC write access to main trunk, discussion
|
|
Re: OpenSC write access to main trunk, discussion
|
|
Le vendredi 17 février 2012 à 02:07 +0100, Peter Stuge a écrit :
> The cry for more committers is misguided. With Git, anyone and > everyone is a committer. If commits exist but are not being included > in the main repository then it is most likely because they need more > work. The effort required to include a perfect patch is next to zero. The question here is flexibility: * OpenSC used to have a very flexible approach. OpenSC is NOT kernel.org with thousands of developers and no need for hierarchy. * Setting-up a compilation farm is no reason for closing write access to historical developers of OpenSC. * 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. 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. We demand more freedom and transparency or this can only lead to endless flamewars. Keep in mind that before doing business, I have been a politician fighting during 4 years for more freedom. 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. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
Re: OpenSC write access to main trunk, discussion
|
|
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 _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
Re: OpenSC write access to main trunk, discussion
|
|
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 _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
Re: OpenSC write access to main trunk, discussion
|
|
Re: OpenSC write access to main trunk, discussion
|
|
Re: OpenSC write access to main trunk, discussion
|
|
Re: OpenSC write access to main trunk, discussion
|
|
In reply to this post by Viktor Tarasov-3
Dear all,
> As I understand the current policy, the patch acceptance policy is > resumed in: > - fixes for crying bugs go to 'master'; > - little fixes, evident limited patch goes to 'staged'; > - more consequent proposals pass to Gerrit and here waits for approval > to be applied to 'staged'. This seems relevant and superior to the previous SVN process. > Current problem is that the process is stagnated on the Gerrit level. > For some obscure reasons Martin do not participates in Gerrit > review/acceptance procedures, as well as Ludovic. > Nobody else have sufficient authority to do it. From Gerrit webpage: "Gerrit simplifies Git based project maintainership by permitting any authorized user to submit changes to the master Git repository, rather than requiring all approved changes to be merged in by hand by the project maintainer." YES, this is what is needed. -- Jean-Michel Pouré - Gooze - http://www.gooze.eu _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
Re: OpenSC write access to main trunk, discussion
|
|
In reply to this post by Jean-Michel Pouré - GOOZE
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 _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
Re: OpenSC write access to main trunk, discussion
|
|
Re: OpenSC write access to main trunk, discussion
|
|
Re: OpenSC write access to main trunk, discussion
|
|
Re: OpenSC write access to main trunk, discussion
|
|
Re: OpenSC write access to main trunk, discussion
|
|
In reply to this post by Peter Stuge-4
> Until newbies can demonstrate that they have learned the right things
> they are by definition not moving forward. Come-on, we are not in a class-room or in an administration. We all agree that Gerrit is the solution. So let's make it work and open accounts for recognized developers to make sure simple patches are committed. If this is not done within a reasonable time frame, I will create a Charity under French law open to everyone and we will have elections. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
Re: OpenSC write access to main trunk, discussion
|
|
Re: OpenSC write access to main trunk, discussion
|
|
Re: OpenSC write access to main trunk, discussion
|
|
In reply to this post by Jean-Michel Pouré - GOOZE
Jean-Michel Pouré - GOOZE wrote:
> > Until newbies can demonstrate that they have learned the right things > > they are by definition not moving forward. > > Come-on, we are not in a class-room or in an administration. We are also not in a democracy. We are in a security related open source project. > We all agree that Gerrit is the solution. So let's make it work and > open accounts for recognized developers to make sure simple patches > are committed. Everyone can register an account, which then allows to push commits into Gerrit, and to comment on and perform +1/-1 review of other commits. An OpenID is neccessary. If someone does not have an OpenID and would like me to provide one, feel free to send me your prefered username, md5(yourpassword) and your full name and email address, and I will create an identity for you on my OpenID provider. You then add two <meta> tags to any web page that you control, and the URL of that web page is your OpenID identifier. Note that many sites such as SourceForge, Google, Yahoo, etc. already have OpenID providers, so if you have an account there you can look around to find your OpenID identifier, which you then use to register with Gerrit. > If this is not done within a reasonable time frame, I will create a > Charity under French law open to everyone and we will have elections. Create as many charities as you like, I don't think it will make any difference. Working on code is unrelated to holding elections. I suggest that those who want to contribute to OpenSC start flooding Gerrit with perfect patches that are so obviously perfect and that are approved by so many contributors that they require nearly zero attention from Martin and Ludovic, and thus can be submitted (again, the Gerrit term for including in the main repo) very quickly. The only alternative to that is IMO for those who want to do development with a different goal and/or a different method than Martin and Ludovic to create a fork. Actually this is already what happens when using Git. Every repository is already a fork. Forking isn't neccessarily bad, but keep in mind that you will have to work very hard to be able to replace the de-facto standard. It will be significantly easier to focus on working with the existing project, on the terms of the existing project. Whenever a fork is created, it is important to decide right at the start what the purpose will be. If the purpose is to get changes back into the original codebase then it is obviously critical to follow the procedures and practises of that codebase, otherwise the effort will be wasted, since the forked codebase is unmergeable. Maybe someone wants to spend time fixing it up. This is very painful, and a complete waste of time. The alternative is to go full steam ahead and decide to never look back. Only with this attitude does it really make sense to fork. You already indicated that you don't really want to fork, so I guess your choice is made. This is all politics. Let's disregard the politics. That leaves code. It is impossible to argue against a perfect patch. //Peter _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
| Free forum by Nabble | Edit this page |