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 |
On 2/15/2012 5:39 AM, Jean-Michel Pouré - GOOZE wrote: > 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? The question is not so much who is on the commiter list, but do commits get made when needed, and who decides a commit is ready and should be made. There are minor fixes, like 389 that is 4 months old with an additional fix 2 months ago, and looks like it needs to be made, as well as major changes such as the SM, ePass2003, and the ECDH modifications. Personally, I am quite interested in getting the ECDH in to the next release with or without the SM code and am willing to rebase the modifications as needed. I believe the ECDH has been ready for months. Viktor pulled the ECDH modifications into his SM on October 4, 2011 and he also pulled in the ePass2003 on January 29. The way forward is not necessarily more commiters, but a plan for the next release and some action. So can we consider adding ePass2003, SM, and ECDH to the next release as these are already being tested together. If giving Viktor commit authority would speed up the inclusion of both small and larger modifications, it would be OK with me. If we can get these included without giving him commit authority, that would be OK with me too. But we need action. > > Community, please advice and discuss this issue. > > Kind regards, > Jean-Michel > > > > > _______________________________________________ > opensc-devel mailing list > [hidden email] > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Douglas E. Engert <[hidden email]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
Hello,
On Thu, Feb 16, 2012 at 11:53 PM, Douglas E. Engert <[hidden email]> wrote: > The way forward is not necessarily more commiters, but a plan > for the next release and some action. Well, once there was maintainer for each subject, so if maintainer of (in this case) ePass2003 decides to put a specific implementation it should be OK. If another one is working on SM and it effects only specific drivers, why not? For example, I don't think I need to beg to include the removal of the libltdl dependency should be trivial even if I got this only 99%. This project loses its flexibility, this is not an advantage. You can decide which feature goes to which milestone, and cooperate with people within different branches. Alon. _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
Alon Bar-Lev wrote:
> This project loses its flexibility, this is not an advantage. I disagree. I find that Git allows all the flexibility developers could ask for. 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 is if a project will insist on perfect patches (e.g. Linux) or if anyone should be allowed to commit anything to the main repo. Inkscape apparently did the latter, and it resulted in a massive janitorial workload to clean up the horrible mess that had been created. No fun. Consider also that addition of commits without review will quite likely introduce bugs which would have been discovered by peers. I think this fact alone is reason enough for OpenSC to not include a single line which hasn't been reviewed rather thoroughly. The review process could even be formalized and made into a strict requirement before writes to the main repo are possible. I understand that Gooze and others have strong interest in inclusion of changes into OpenSC. The only way to make that happen is what Douglas described; put in the work, and create perfect patches. Write access to some repository is not the issue. The whole world already has Git write access. If someone needs help with publishing a repository then feel free to let me know. If you have prepared a patch which you think is perfect but noone is responding then give it a thorough review yourself, and try again. Also try discussing the change, explaining it in an email can be a great way to produce a better commit message, which is very important for anyone who is doing review. Note that review does not mean to browse through the change and say "looks ok", but it means to understand the effects of every changed line. This can require a lot of context and/or research. You can help by that commit be included by doing review. You doing review is infinitely more important than you having write access to some repository. //Peter _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
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 |
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 |
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 |
On 02/17/2012 10:58 PM, Jean-Michel Pouré - GOOZE wrote:
> 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. [disclaimer I'm not experienced with opensc internals and comment might be wrong] This sounds pretty similar to the situation in hardware drivers which often evolve faster than the linux kernel's pace. It might be better to have a module approach for such development so that cutting edge drivers can be used with opensc without recompilation or waiting for a new opensc release. I don't know though, whether the size of the projectjustifies something like that. > 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. In cases it might be good. We rejected Alon's PKCS #11 patches on gnutls as well. You can say it was the wrong decision or so, but in the end of day the few developers responsible for the project will have to maintain it. If it is code they cannot maintain, or does not agree with the longer term plans of the project maybe the feature should be postponed. regards, Nikos _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
In reply to this post by Douglas E. Engert
Le 16/02/2012 22:53, Douglas E. Engert a écrit :
> > On 2/15/2012 5:39 AM, Jean-Michel Pouré - GOOZE wrote: >> 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? > The question is not so much who is on the commiter list, but do commits > get made when needed, and who decides a commit is ready and should be made. > > There are minor fixes, like 389 that is 4 months old with an additional > fix 2 months ago, and looks like it needs to be made, as well as major > changes such as the SM, ePass2003, and the ECDH modifications. > > Personally, I am quite interested in getting the ECDH in to the next > release with or without the SM code and am willing to rebase the > modifications as needed. I believe the ECDH has been ready for months. > > Viktor pulled the ECDH modifications into his SM on October 4, 2011 and > he also pulled in the ePass2003 on January 29. > > The way forward is not necessarily more commiters, but a plan > for the next release and some action. 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'. 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. Martin has pushed to Gerrit part of SM branch. What are the intentions for the rests? What about next release? What should be included into? How can be tested the compatibility of different proposals? Personally I do not look for additional rights, as Douglas, I'm interested in some action and ready to help to move the things forward. And so, would like to have this possibility. Also Jenkins is dead for some time already. What shall we do? Wait? Mount temporary service of limited volume -- at least for OpenSC/'staged' and few other branches ? > So can we consider adding ePass2003, SM, and ECDH to the next release > as these are already being tested together. > > If giving Viktor commit authority would speed up the inclusion of both small > and larger modifications, it would be OK with me. If we can get these > included without giving him commit authority, that would be OK > with me too. But we need action. > >> Community, please advice and discuss this issue. >> >> Kind regards, >> Jean-Michel >> >> >> >> >> _______________________________________________ >> opensc-devel mailing list >> [hidden email] >> http://www.opensc-project.org/mailman/listinfo/opensc-devel _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
Le 18 février 2012 04:59, Viktor Tarasov <[hidden email]> a écrit :
> Le 16/02/2012 22:53, Douglas E. Engert a écrit : >> >> On 2/15/2012 5:39 AM, Jean-Michel Pouré - GOOZE wrote: >>> 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? >> The question is not so much who is on the commiter list, but do commits >> get made when needed, and who decides a commit is ready and should be made. >> >> There are minor fixes, like 389 that is 4 months old with an additional >> fix 2 months ago, and looks like it needs to be made, as well as major >> changes such as the SM, ePass2003, and the ECDH modifications. >> >> Personally, I am quite interested in getting the ECDH in to the next >> release with or without the SM code and am willing to rebase the >> modifications as needed. I believe the ECDH has been ready for months. >> >> Viktor pulled the ECDH modifications into his SM on October 4, 2011 and >> he also pulled in the ePass2003 on January 29. >> >> The way forward is not necessarily more commiters, but a plan >> for the next release and some action. > > 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'. > > 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. I don't know why only Martin and myself are integrators on Gerrit. I reviewed some patches but don't know what to do next. It looks like the patches are not moved to github/staging. Maybe a configuration problem? Note: this is my first use of Gerrit. > Martin has pushed to Gerrit part of SM branch. What are the intentions for the rests? > What about next release? What should be included into? > How can be tested the compatibility of different proposals? > > Personally I do not look for additional rights, > as Douglas, I'm interested in some action and ready to help to move the things forward. > And so, would like to have this possibility. > > > Also Jenkins is dead for some time already. Exact. I did not noticed. > What shall we do? > Wait? Mount temporary service of limited volume -- at least for OpenSC/'staged' and few other branches ? Martin, what do you plan to do? Regards, -- Dr. Ludovic Rousseau _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
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 |
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 |
In reply to this post by Peter Stuge-4
Le 17/02/2012 17:52, Peter Stuge a écrit :
> Jean-Michel Pouré - GOOZE wrote: >> * 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. Nobody doubts that review in critical. But what shall we do now, how can we 'move forward', if the review/acceptance process is stopped at the Gerrit level and the only person that is capable and has authority to do something is absent for a long time already ? ... >> * 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. I agree, compilation farm is extremely useful. But it has to be adapted/configured in accordance with the available human and other resources. There has to be no definitive obstacle for 'moving forward', otherwise this 'compilation farm' stuff loose it's sense of being. > >> 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. Probably you have a reason -- 'whitespace', 'commit messages', 'undoes unrelated changes', ... But from my point of view: - commit history do not needs to be perfect for the new driver, before it's commited into one of the official branches; - personally, I'm ready to correct myself the limited number of the coding style ot other issues when merging newbie commits, but to not make the 'ping-pong' last for ages; - historically, afais, driver authors where relatively free in coding style, implementation particularities, etc. in the part that concerns it's 'own space' . (It's the module approach, that Nikos Mavrogiannopoulos talking about in his mail in this thread.) Certainly, the 'newbies' have to be 'educated' in the 'right' direction, but the process could not be so rigorous and finally to not block the 'moving forward'. ... > //Peter Kind regards, Viktor. _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
Viktor Tarasov wrote:
> Nobody doubts that review in critical. > But what shall we do now, how can we 'move forward', > if the review/acceptance process is stopped at the Gerrit level > and the only person that is capable and has authority to do > something is absent for a long time already ? I suggest to iterate over proposed patches until they are perfect. That way, those who can submit commits in Gerrit (this is the Gerrit term for including a commit into the main repository) will need to spend close to zero time on doing so. Their job becomes so easy that it is a no-op. Then it also gets done quickly and frequently. This must be the goal. > Probably you have a reason -- 'whitespace', 'commit messages', > 'undoes unrelated changes', ... > But from my point of view: > - commit history do not needs to be perfect for the new driver, > before it's commited into one of the official branches; Work in progress will always exist. Beta testing of work in progress is good and important, and Git makes this extremely easy. Anyone in the world can publish their work in progress. Proposing a commit for inclusion in the main repo is something quite different. Whenever something is pushed to Gerrit it must indeed be perfect, or it is just some lazy or sloppy developer wasting the time of others. I think we are all busy and want to avoid wasted time. > - personally, I'm ready to correct myself the limited number of the > coding style ot other issues when merging newbie commits, but to > not make the 'ping-pong' last for ages; This is a trade-off. It's fine to do this once or twice for a new developer. It's however quite hopeless when the developer whose work you review consistently makes the same mistakes that you have corrected and possibly even pointed out several times before. It is a waste of time for humans to do such work. Static analysis of commits, e.g. using checkpatch.pl from Linux possibly with som modifications, can and must be automated. Gerrit is the perfect place to do it. > - historically, afais, driver authors where relatively free in > coding style, implementation particularities, etc. in the part > that concerns it's 'own space' . I find this problematic since it leads to low reusability. Even just visual style differences are not really helpful. A uniform codebase is more coherent and easier to deal with for everyone involved. The coding style rules do not have to be very many, but having project wide rules is a good thing. > Certainly, the 'newbies' have to be 'educated' in the 'right' > direction, but the process could not be so rigorous and finally to > not block the 'moving forward'. Until newbies can demonstrate that they have learned the right things they are by definition not moving forward. //Peter _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
IMO the core problem with OpenSC is a that all cards seem to require
a tweak, profile or similar. For government IDs which are driven by politics rather than reason there is no problem to solve; the governments simply have to pay the price for demanding "uniqueness". For non-government tokens like the excellent Feitian Epass2003 I would consider another approach: Updating the firmware to emulate PIV so that we can put the middleware aside once and for all. That is, HW vendors should qualify their products against middleware rather than running never-ending projects that only creates frustration and exuberant costs. Anders _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
Anders Rundgren wrote:
> For non-government tokens like the excellent Feitian Epass2003 > I would consider another approach: Updating the firmware to > emulate PIV so that we can put the middleware aside once and > for all. I agree completely that all the legacy involved in tokens and cards is horrendous waste of engineering resources, time and life. I'm excited about the gnuk project, it's a nice platform to play with the PKCS#11 over USB idea, which I refuse to give up on before having attempted to implement it and failed. :) //Peter _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
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 |
In reply to this post by Peter Stuge-4
Le 19/02/2012 11:23, Peter Stuge a écrit :
> Viktor Tarasov wrote: >> Nobody doubts that review in critical. >> But what shall we do now, how can we 'move forward', >> if the review/acceptance process is stopped at the Gerrit level >> and the only person that is capable and has authority to do >> something is absent for a long time already ? > I suggest to iterate over proposed patches until they are perfect. Iterate with who? There is nobody on the other side of the wire. For months the only person that is capable to do/answer something is absent. > That way, those who can submit commits in Gerrit (this is the Gerrit > term for including a commit into the main repository) will need to > spend close to zero time on doing so. Their job becomes so easy that > it is a no-op. Then it also gets done quickly and frequently. This > must be the goal. I'm completely agree with you, and admire the beauty of your abstract considerations, but what have we do here & now, in our current situation -- Jenkins is dead, Gerrit is in mute coma. ... >> - personally, I'm ready to correct myself the limited number of the >> coding style ot other issues when merging newbie commits, but to >> not make the 'ping-pong' last for ages; > This is a trade-off. It's fine to do this once or twice for a new > developer. It's however quite hopeless when the developer whose work > you review consistently makes the same mistakes that you have > corrected and possibly even pointed out several times before. It is a > waste of time for humans to do such work. Believe me, I have other interesting things to do. But for months I'm looking the way to help to 'move OpenSC forward' and but had no answers -- there is no activity on the other side. Decision to pull the ECDH, the ePass2003 into SM branch is my isolated desperate attempt to 'move forward'. > Static analysis of commits, > e.g. using checkpatch.pl from Linux possibly with som modifications, > can and must be automated. Gerrit is the perfect place to do it. Please, come back to earth -- Gerrit is not actually functional. >> - historically, afais, driver authors where relatively free in >> coding style, implementation particularities, etc. in the part >> that concerns it's 'own space' . > I find this problematic since it leads to low reusability. Even just > visual style differences are not really helpful. A uniform codebase > is more coherent and easier to deal with for everyone involved. The > coding style rules do not have to be very many, but having project > wide rules is a good thing. Completely on you side. But that's the current state of art. To change something we need more resources. >> Certainly, the 'newbies' have to be 'educated' in the 'right' >> direction, but the process could not be so rigorous and finally to >> not block the 'moving forward'. > Until newbies can demonstrate that they have learned the right things > they are by definition not moving forward. ... > //Peter Kind regards, Viktor. _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
In reply to this post by Peter Stuge-4
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 > [hidden email] > http://www.opensc-project.org/mailman/listinfo/opensc-devel _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
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 |