Re: [opensc-devel] OpenSC and gerrit
Martin, Le 23 mars 2012 18:17, Martin Paljak a écrit : > Hello, > > On Sun, Mar 18, 2012 at 00:30, Viktor Tarasov > wrote: >> - replication in gerrit do not working. >> Should we manually push the perfect commits from gerrit's repo to staging? >> (In the github's pull requests the commits are also perfects, almost >> perfect.) > Fetching github > Fetching gerrit > Fetching master > To g...@github.com:OpenSC/OpenSC.git > ! [rejected] master/staging -> staging (non-fast-forward) > error: failed to push some refs to 'g...@github.com:OpenSC/OpenSC.git' > To prevent you from losing history, non-fast-forward updates were rejected > Merge the remote changes (e.g. 'git pull') before pushing again. See the > 'Note about fast-forwards' section of 'git push --help' for details. > To g...@github.com:OpenSC/OpenSC.git > > > Github mirror was supposed to be a plain (one way) mirror, meaning > that things that go through gerrit are published on github and github > pull requests put to Gerrit, but merging both to gerrit and github > causes expected different trees. Fixing this requires some effort. I think I am the/one of responsible for this problem. Since gerrit was not working for me I merged new code on github. Sorry for the mess. Are pull request for OpenSC/OpenSC on github sent to gerrit automatically as documented in [1]? Regards, [1] https://www.opensc-project.org/opensc/wiki/SourceCode -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Hello, On Sun, Mar 18, 2012 at 00:30, Viktor Tarasov wrote: > - replication in gerrit do not working. > Should we manually push the perfect commits from gerrit's repo to staging? > (In the github's pull requests the commits are also perfects, almost perfect.) Fetching github Fetching gerrit Fetching master To g...@github.com:OpenSC/OpenSC.git ! [rejected]master/staging -> staging (non-fast-forward) error: failed to push some refs to 'g...@github.com:OpenSC/OpenSC.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. To g...@github.com:OpenSC/OpenSC.git Github mirror was supposed to be a plain (one way) mirror, meaning that things that go through gerrit are published on github and github pull requests put to Gerrit, but merging both to gerrit and github causes expected different trees. Fixing this requires some effort. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Hello, On Mon, Mar 19, 2012 at 13:08, Jean-Michel Pouré - GOOZE wrote: > OpenSC copyright belongs to the group of people who wrote OpenSC, > which is all of us. It does not belong to any company and an individual > granting rights to other individuals. In legal terms, *copyright* on OpenSC belongs to the authors who have contributed code, and/or marked it down in source code. The fact that other, unknown persons (not established in source code as copyright owners) have code in OpenSC source tree is also known, as there is no legal body (foundation, like Gnome or GNU or similar) that would govern licensing in OpenSC. This has also helped "free" some source code that has been grabbed by some companies and turned into their offerings, without giving source code. Thus everybody are free to use the source code on the same terms, which is mostly LGPL (there are exceptions, like the Tokend code wihich is not LGPL as it is derived from Apple source code etc etc) > To be more precise: > > Peter, Ludovic and Martin do not have any legal right to establish > rules over OpenSC project. Especially if these rules go > in the direction of more bureaucracy. We have to accept collaboration > whenever possible. The only "legal right" is what is written in LGPL or other licenses and I'm pretty sure that nobody wants to change that. But yes, you are right. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
On Wed, Mar 21, 2012 at 11:03 PM, Peter Stuge wrote: >> progress much faster, even in the price of committing not-the-best >> solutions, > Do you find this a desirable quality for a security-related project? I don't think that this thread was about a balance of quality against quantity. The issue was that the selected reviewing process was inefficient and became a bottleneck to adding any new features. Having code lying for several months unreviewed doesn't really improve quality, it just demotivates contributors. regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
On Thu, Mar 22, 2012 at 12:03 AM, Peter Stuge wrote: > Alon Bar-Lev wrote: >> I will try again. > > Thanks! It really helps! I am glad! Well, let's agree we do not agree... :) At no point in time I argue that the gerrit is not a good tool, I argue the methodology. Anyway, just last note I want to make... OpenSC is by far *NOT* a security project. Yes, that may sound surprising... :) OpenSC deals with security subject, that's true... hardware cryptography. But its origin mission was to provide access (USABILITY) to none Windows (+ none proprietary) users to hardware cryptography, PKCS#15 and partially by reverse engineering. If we want OpenSC to be security project, we should probably rewrite the whole thing from scratch. With different priorities, the code will probably be completely different feature set will be smaller, and the quality of the code will be higher, thus also the cost of implementation and maintenance. Few years back, when I tried to push OpenSC enabled tokens to enterprises, I found that I just cannot do that, mainly because of this reason. I don't see this happening without sponsor and some full time developers. Maybe this is another issue that differentiate our views. I think there is a great value in current state of OpenSC to allow people to [at least] use hardware cryptography, even if this is not the perfect implementation, keeping it flexible enough to enlarge the cycle of devices and users. Apart of the value of people can actually use their hardware, this implementation will allow in future the necessary low level details in order to do the rewrite. Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Le mercredi 21 mars 2012 à 23:54 +0100, Peter Stuge a écrit : > I find that quite offensive. Why don't you focus on the code? At present I focus on building a farm compiling packages. 10 days x 10 hours a day to set-up the hardware and software and this is far from complete. I admit to use sarcasm during this public discussion. You know, I am a big fan of Sheldon Cooper (http://en.wikipedia.org/wiki/Sheldon_Cooper) but I would not like to be part of his team for free software development. What you are proposing us is writing a pure software with zero bugs, one reviewer and probably (this is sarcasm) zero user. This will not succeed, because such an organization only exist in companies like Microsoft or in Deamland (this is sarcasm), not GNU/Linux. The only reason for locking OpenSC is that it is a security software. I don't believe this is relevant, as MOST security software are open and people collaborate without restriction. > This is an utter phallacy. An open source project can never be a > democracy, and trying to create democracy is nothing but feelgood > bureacracy. You focus too much on "code review", not "collaboration". This can only lead to a situation where code reviewers are flooded under too much work. Unless we pay them, this will not work. Or maybe getting paid someday is a goal of the new organization? The only alternative is to rely on the community at large, as always in a community project. In short: we want flexibility & freedom. There will be no paid work on reviewing code by "authorized people", like it is sometime the case at pcsc-lite project. Furthermore, we don't want organizations like Gemalto or PCSC group or any other company to decide whether the code quality is relevant enough to reach production. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Jean-Michel Pouré - GOOZE wrote: > > Please understand that whatever you try to organize democratically > > will indeed be a fork. Open source is not democracy. > > Peter, you are shooting yourself a bullet in the foot. This isn't about me. > As written before, some people really believe to own OpenSC. Something being written doesn't make it true. I further find it rather rich that you claim to know what someone else believes. > Do you mean OpenSC can be ruled with passwords and administrative > rigths? I mean that each and every open source project can be ruled by perfect patches! Democracy and passwords are equally irrelevant. Code is not. > Creating a non-profit organization will solve this isssue and make > sure OpenSC IS a democracy. This is an utter phallacy. An open source project can never be a democracy, and trying to create democracy is nothing but feelgood bureacracy. > When the project was handed over to Martin, there was no discussion > on governance and this needs to be fixed pretty soon. I find that quite offensive. Why don't you focus on the code? //Peter pgpEXC98lyj3F.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Le mercredi 21 mars 2012 à 23:03 +0100, Peter Stuge a écrit : > Thanks for taking the time! It really helped understand what you > mean! Peter, what I read in your previous post, you seem to be too picky. IMHO, quality is a circle: you write code, ask for review, commit a first version, ask for review, commit a second version, publish packages, reach thousands of users, get bug reports, fix in code and slowly the quality of code grows until it reaches perfection. At the same time, you have to convince people to join and give them some freedom, especially if they write code for free. What you are proposing us is a bureaucratic organization which might work in a company writing closed-source software, not free software. The way OpenSC is getting organized recently is using collaboration tools: Gerrit, Jenkins. But these tools are used to limit the freedom of developers. They are being used conversly to traditional goals. Setting-up collaboration tools with ONE or TWO admins and an army of developers is just a huge lost of time and efforts. Now from a personal point: why are you afraid of freedom in a Free software development? Can't you trust recognized developers who have a life and a family to make useful commits after having a discussion on a mailing list. And why do you need to set passwords to limit our freedom? Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Le mercredi 21 mars 2012 à 23:04 +0100, Peter Stuge a écrit : > Please understand that whatever you try to organize democratically > will indeed be a fork. Open source is not democracy. Peter, you are shooting yourself a bullet in the foot. As written before, some people really believe to own OpenSC. Do you mean OpenSC can be ruled with passwords and administrative rigths? Creating a non-profit organization will solve this isssue and make sure OpenSC IS a democracy. When the project was handed over to Martin, there was no discussion on governance and this needs to be fixed pretty soon. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Jean-Michel Pouré - GOOZE wrote: > > Jean-Michel, as I've said already, please stop the noise and go fork > > if that is what you want! I promise I'll stay far away. > > We don't want to fork, this would be stupid. Please understand that whatever you try to organize democratically will indeed be a fork. Open source is not democracy. //Peter pgpG4sexSJSop.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Alon Bar-Lev wrote: > I will try again. Thanks! It really helps! > > > The bureaucracy and lack of flexibility will inhibit contributions > > > and healthy *SMALL* community. > > > > What bureaucracy do you mean? Requiring no build failure and review > > in gerrit? I think those are acceptable requirements. They're also > > not exactly unique for OpenSC. > > Yes. That's exactly what I mean. Sure it is not exactly unique for > OpenSC, just that you compare it to different kind of dynamics, > different stability requirement and different amount of available > resources. Do you think they are unacceptable requirements? I don't. > > What lack of flexibility do you mean? Anyone in the whole world can > > clone the gerrit repo, make changes, and push them back to gerrit > > for review. > > Right, then wait 3 months in order to have his changes reviewed and > discussed, If review takes 3 months then I guess that's the pace of development for the project? Note that in addition to anyone being able to contribute changes it's also possible for anyone to contribute review. > and only then continue, Can always continue. But yes of course if there are significant discussions to be had before any code can be written then that code has to wait until that discussion is done. I don't think this scenario is very likely. And even if it would happen, I think that some code would be a great way to spark discussion. It is however important to remember that the code at that stage serves primarily as inspiration for the discussion. Just because some code was written doesn't mean that it should go into the main repository. > while doing about 10 times rebase and fix his 3 months old patch > set. As I've written several times I'm not sure about the current gerrit configuration. It's also possible to configure gerrit for different workflows than the current one, specifically the requirements that changes must be fast-forward. There are both pros and cons with requiring fast-forward, as I've discussed in other messages. The other options clearly allow more flexibility but that's not neccessarily a good thing. > Look, the model should be entirely different for small projects > without much resources, something that is more similar to what > we had before. > > There are 3, 4 or 5 core developers, they can do whatever they like, > commit, revert, fix - anything. In practise this is the case for all users in the integrators group in gerrit. > Each commit is sent to the mailing list, so peers and guests can > review changes and comment. This is of course also configurable in gerrit. > progress much faster, even in the price of committing not-the-best > solutions, Do you find this a desirable quality for a security-related project? > The guests' process can be replaced by the gerrit solution, which is > superior. Instead of sending patches to mailing list use the gerrit > interface to keep track and review. This is a great improvement, > which is unrelated to core developers process. Yes they are somehow separate processes, but they can still share infrastructure and workflow without issues. > What I basically saying is that in utopia you may be right, however, > the reality requires flexibility, especially when the numbers are low > (core developers, community size, allocated resources). I don't think I've advocated against flexibility, but I will if it means compromising on quality. Note that I'm not contributing much code, only speaking my mind on my preferences. > What the "new" process provides is a stable branch [most chances] at > every given time - this is its advantage and is suitable for software > that should be released in very short cycles, this is not the case of > this project. I don't know that gerrit is unsuitable even if longer cycles tend to be the norm. > > > Until now I did not notice gerrit to be so good solution > > > that all other methods should be dropped for of it. > > > > I'm afraid I don't understand what exactly you mean by this. Gerrit > > helps track patches. I'm not sure that the current configuration is > > completely ideal, but it is also not in any way causing a critical > > problem for further development. > > No, I meant there are other alternatives and solution for software > development. gerrit way (or patch way) is one of them. I don't rule > out the others just because the current trend of developing the Linux > kernel uses one. The point about gerrit is not that it is trendy, the point is that it adds fantastic functionality. > > Of course there is no replacement for testing, but I really can not > > agree if you are arguing that being unable to extend jenkins is a > > critical problem for further development. > > No, I am arguing that it is more important than the whole patch > method for core developers. Hmm? Can you be a bit more specific? Sorry, but I don't understand exactly. > > > I quite miss the previous method in which people could work on thi
Re: [opensc-devel] OpenSC and gerrit
Le mercredi 21 mars 2012 à 22:19 +0100, Peter Stuge a écrit : > Jean-Michel, as I've said already, please stop the noise and go fork > if that is what you want! I promise I'll stay far away. We don't want to fork, this would be stupid. Viktor and Alon wrote interesting text, I don't want to add anything. The project of an non-profit association is in the previous post. Bye. -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Jean-Michel Pouré - GOOZE wrote: > Unless you agree that by writing on the mailing list, we are going > to incorporate an association. Jean-Michel, as I've said already, please stop the noise and go fork if that is what you want! I promise I'll stay far away. //Peter pgprOilbqPvTj.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Le mercredi 21 mars 2012 à 09:21 -0500, Douglas E. Engert a écrit : > Before we incorporate, I have a few questions and comments: > What other open source projects have uses this French loi law? > Has this helped or hindered their project? Video Lan for example, the editor of VLC: http://www.videolan.org/videolan/ Loi 1901 stands for "Non-profit organization". Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
On 3/21/2012 5:32 AM, Jean-Michel Pouré - GOOZE wrote: > Dear all, > >> OK. What do you propose? > > I propose to incorporate OpenSC as a French association under the loi > 1901 law, under a general agreement. There are millions of associations > in France and the government provides a generic paper for incorporation. > I propose to use this paper without modification. Before we incorporate, I have a few questions and comments: What other open source projects have uses this French loi law? Has this helped or hindered their project? What appears to have happened over the last few months is that Martin has started to setup a complicated code review system using Git, GitHub, Gerrit and Jenkins then has not had the time (or lost interest) to complete the process. At the same time as a number of large changes have been submitted and are now stalled. I am assuming that all these systems are running on Martin's computers somewhere in Estonia and the Web site is on the ISP: Hetzner Online AG in Germany. Martin, we have not heard from you on what is going on, and if you can continue to support the infrastructure and effort needed for this project and if not, how do we transfer the administrative burden from you to someone who can handle it. I see Ludvoic is trying to do the best he can with the access and the understanding he has of Gerrit. Peter has been of great help with Git and Gerrit. Martin, we need to hear from you... > > In short: > > * All members are equal. > * Everyone can join the association, without filter. > * The executive board and president is elected every year. > * Recognized developers have an all-time right to join the board. > * We don't need any budget or funding as this is free software. > * I can handle the accounting as this is a bureaucratic issue. > * All information is public and available for download, including > accounting. > > Very important : the executive board would agree to let OpenSC > developers organize themselves according to an organization statement. > > The organisation statement should be one page, explaining the > development processes, close to Viktor proposal with the flexibility > proposed by Alon. i.e. : > > * OpenSC has a stable GIT branch which is the release, an unstable > branch called staging. > * All patches are discussed and committed fast to staging. All > recognized developers can make commits, without any obligation to join > the association, just as in old times. > * Packages on the build farm are released daily to help detecting and > fixing bugs. The quality process comes from flexibility, the fast > release of versions and bug detection. > * We should have date releases, i.e. every two months. The dates are > known in advance, so everyone gets organized for the release. > > In short, we want to give the power back to developers and contributors. > >>> Martin and Ludovic, please confirm on the mailing list each of >> these: >>> A. OpenSC is a self driven-community with several core-developers, >> no >>> leader/owner. >>> B. Martin and Ludovic are core developers, not owners of the >> project. >>> OpenSC is owned by the community. > >> Note that I do not administer any of the OpenSC resources/servers. So >> I can't do much. > > I think there is a misunderstanding in the way OpenSC is organized. I > begin to think that Martin considers himself as an owner, not an > administrator. > > So I am asking again to you Martin and Ludovic: 1) do you agree the > community to be the owner of OpenSC and 2) do you accept to serve the > community. > > Unless you agree that by writing on the mailing list, we are going to > incorporate an association. > >> And what if core developers to not want to join your association? :-) > > As written previously, to make commit to GIT there will be no obligation > to be part of the association. Everyone is free to contribute to GIT and > submit patches and we'll commit them with great pleasure. > > Kind regards, > > > > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Dear all, > OK. What do you propose? I propose to incorporate OpenSC as a French association under the loi 1901 law, under a general agreement. There are millions of associations in France and the government provides a generic paper for incorporation. I propose to use this paper without modification. In short: * All members are equal. * Everyone can join the association, without filter. * The executive board and president is elected every year. * Recognized developers have an all-time right to join the board. * We don't need any budget or funding as this is free software. * I can handle the accounting as this is a bureaucratic issue. * All information is public and available for download, including accounting. Very important : the executive board would agree to let OpenSC developers organize themselves according to an organization statement. The organisation statement should be one page, explaining the development processes, close to Viktor proposal with the flexibility proposed by Alon. i.e. : * OpenSC has a stable GIT branch which is the release, an unstable branch called staging. * All patches are discussed and committed fast to staging. All recognized developers can make commits, without any obligation to join the association, just as in old times. * Packages on the build farm are released daily to help detecting and fixing bugs. The quality process comes from flexibility, the fast release of versions and bug detection. * We should have date releases, i.e. every two months. The dates are known in advance, so everyone gets organized for the release. In short, we want to give the power back to developers and contributors. > > Martin and Ludovic, please confirm on the mailing list each of > these: > > A. OpenSC is a self driven-community with several core-developers, > no > > leader/owner. > > B. Martin and Ludovic are core developers, not owners of the > project. > > OpenSC is owned by the community. > Note that I do not administer any of the OpenSC resources/servers. So > I can't do much. I think there is a misunderstanding in the way OpenSC is organized. I begin to think that Martin considers himself as an owner, not an administrator. So I am asking again to you Martin and Ludovic: 1) do you agree the community to be the owner of OpenSC and 2) do you accept to serve the community. Unless you agree that by writing on the mailing list, we are going to incorporate an association. > And what if core developers to not want to join your association? :-) As written previously, to make commit to GIT there will be no obligation to be part of the association. Everyone is free to contribute to GIT and submit patches and we'll commit them with great pleasure. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Le 20 mars 2012 22:03, Jean-Michel Pouré - GOOZE a écrit : > Martin and Ludovic, can you open the door to a real collaboration and > allow more core developers? As OpenSC is a small community I think it is > preferable to come back to the old organization when the community was > driving itself. OK. What do you propose? I already added Viktor to gerrit as an integrator (to accept patches). What can I do next? > Martin and Ludovic, please confirm on the mailing list each of these: > A. OpenSC is a self driven-community with several core-developers, no > leader/owner. > B. Martin and Ludovic are core developers, not owners of the project. > OpenSC is owned by the community. Note that I do not administer any of the OpenSC resources/servers. So I can't do much. > Without direct answer, I will be obliged to incorporate a public OpenSC > association in France and ask core developers to join the association. And what if core developers to not want to join your association? :-) Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Le mardi 20 mars 2012 à 22:16 +0200, Alon Bar-Lev a écrit : > > I think that core developers (and I am not arguing I am one of them) > should have free access to repository, allowing them to progress the > fastest they can, we (the community) should trust them to fix whatever > issue they may cause, post review their changes and suggest > alternatives. Thanks for this post. OpenSC is really a small community relying on trust and it should be "self-managed". Now, IMHO: Martin and Ludovic, can you open the door to a real collaboration and allow more core developers? As OpenSC is a small community I think it is preferable to come back to the old organization when the community was driving itself. Martin and Ludovic, please confirm on the mailing list each of these: A. OpenSC is a self driven-community with several core-developers, no leader/owner. B. Martin and Ludovic are core developers, not owners of the project. OpenSC is owned by the community. Without direct answer, I will be obliged to incorporate a public OpenSC association in France and ask core developers to join the association. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
On Sun, Mar 18, 2012 at 2:17 AM, Peter Stuge wrote: > > Alon Bar-Lev wrote: > > I think you are trying to make opensc something it is not. > > I am not trying to do a single thing beyond pointing out that there > is alot of complaints and wasted time over no *actual* problem. First I want to write that I have no intention to manage this project, just to provide my own view regarding the process. The fact that I fail to present my argument so you understand is my own failure. I have no words beyond what I already wrote, but I will try again. > > > The bureaucracy and lack of flexibility will inhibit contributions > > and healthy *SMALL* community. > > What bureaucracy do you mean? Requiring no build failure and review > in gerrit? I think those are acceptable requirements. They're also > not exactly unique for OpenSC. Yes. That's exactly what I mean. Sure it is not exactly unique for OpenSC, just that you compare it to different kind of dynamics, different stability requirement and different amount of available resources. > What lack of flexibility do you mean? Anyone in the whole world can > clone the gerrit repo, make changes, and push them back to gerrit for > review. Right, then wait 3 months in order to have his changes reviewed and discussed, and only then continue, while doing about 10 times rebase and fix his 3 months old patch set. Look, the model should be entirely different for small projects without much resources, something that is more similar to what we had before. There are 3, 4 or 5 core developers, they can do whatever they like, commit, revert, fix - anything. Each commit is sent to the mailing list, so peers and guests can review changes and comment. As result of this post review, these people who are the trusted by the community and trust each other may progress much faster, even in the price of committing not-the-best solutions, while cooperating together based on each own free resources to achieve the-best solutions. Until now guests sent patches to mailing list for review, there was always the chance that the core developers missed specific patch or had no interest at that point in time. These patches were lost if the author did not resend it over and over until he got acknowledgment. The guests' process can be replaced by the gerrit solution, which is superior. Instead of sending patches to mailing list use the gerrit interface to keep track and review. This is a great improvement, which is unrelated to core developers process. What I basically saying is that in utopia you may be right, however, the reality requires flexibility, especially when the numbers are low (core developers, community size, allocated resources). > > That's true that it may eventually lead to more stable > > implementation, but the cost may be lack of progress, > > thus not able to achieve the stability goal as well. > > Quantity is IMO completely irrelevant without quality. Again, reality showed different behavior... There was a different process which worked and produced no less quality in releases. What the "new" process provides is a stable branch [most chances] at every given time - this is its advantage and is suitable for software that should be released in very short cycles, this is not the case of this project. > > Until now I did not notice gerrit to be so good solution > > that all other methods should be dropped for of it. > > I'm afraid I don't understand what exactly you mean by this. Gerrit > helps track patches. I'm not sure that the current configuration is > completely ideal, but it is also not in any way causing a critical > problem for further development. No, I meant there are other alternatives and solution for software development. gerrit way (or patch way) is one of them. I don't rule out the others just because the current trend of developing the Linux kernel uses one. > > However, a proper build server with multiple platforms and > > configurations is something that is vary useful to have in > > order to test branches before merging. > > Of course there is no replacement for testing, but I really can not > agree if you are arguing that being unable to extend jenkins is a > critical problem for further development. No, I am arguing that it is more important than the whole patch method for core developers. > > I quite miss the previous method in which people could work on this > > project progressing (and may do mistakes), but invest their time in > > proactive way. > > What is stopping that? Please be specific. Just look at the history, see how we cooperated in partial solutions, reaching gradually to complete solution within the tree during periods of weeks and different developers for separate issues. > > I don't think that in current process I [or anyone similar] could have > > contributed whatever I've done before, so I don't think it is going to > > a good place. > > Why not? Please be specific. I tried to explain above. As summary, Peter, I think you took
Re: [opensc-devel] OpenSC and gerrit
Hello, On Sat, Mar 17, 2012 at 23:01, Viktor Tarasov wrote: > Gerrit still has replication problem -- 'staging' of OpenSC/OpenSC.git do not > updated by merges of Gerrit's repository. > Certainly, gerrit is nice tool to play with, but, without replication it > looses much of it's utility. This was due to the "ruby github ssh" issue [1], after what all pubkeys were suspended on Github and needed validation. So was the key that did the syncing disabled. As the repostiroy did not seem to be out of sync, I assumed that the keys are still OK and re-enabled them. That should also bring the sync back (will verify). [1] https://github.com/blog/1068-public-key-security-vulnerability-and-mitigation Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
The message was sent before it was written. Correcting it: Dear Peter, > > The bureaucracy and lack of flexibility will inhibit contributions > > and healthy *SMALL* community. > > What bureaucracy do you mean? Requiring no build failure and review > in gerrit? I think those are acceptable requirements. They're also > not exactly unique for OpenSC. Come on! This is obvious. When we mean "bureaucracy", we mean a small group of people trying to privatize OpenSC. OpenSC copyright belongs to the group of people who wrote OpenSC, which is all of us. It does not belong to any company and an individual granting rights to other individuals. To be more precise: Peter, Ludovic and Martin do not have any legal right to establish rules over OpenSC project. Especially if these rules go in the direction of more bureaucracy. We have to accept collaboration whenever possible. If you still don't understand, we will go over an election process. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Dear Peter, > > The bureaucracy and lack of flexibility will inhibit contributions > > and healthy *SMALL* community. > > What bureaucracy do you mean? Requiring no build failure and review > in gerrit? I think those are acceptable requirements. They're also > not exactly unique for OpenSC. Come on! This is obvious. When we mean "bureaucracy", we mean a small group of people trying to privatize OpenSC. When the project was handed over a few months ago, there was no election. OpenSC copyright does not belong to you but to the group of people who wrote it. You have to right to stop us from developing OpenSC, making commits or publishing packages. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Alon Bar-Lev wrote: > I think you are trying to make opensc something it is not. I am not trying to do a single thing beyond pointing out that there is alot of complaints and wasted time over no *actual* problem. > The bureaucracy and lack of flexibility will inhibit contributions > and healthy *SMALL* community. What bureaucracy do you mean? Requiring no build failure and review in gerrit? I think those are acceptable requirements. They're also not exactly unique for OpenSC. What lack of flexibility do you mean? Anyone in the whole world can clone the gerrit repo, make changes, and push them back to gerrit for review. > That's true that it may eventually lead to more stable > implementation, but the cost may be lack of progress, > thus not able to achieve the stability goal as well. Quantity is IMO completely irrelevant without quality. > Until now I did not notice gerrit to be so good solution > that all other methods should be dropped for of it. I'm afraid I don't understand what exactly you mean by this. Gerrit helps track patches. I'm not sure that the current configuration is completely ideal, but it is also not in any way causing a critical problem for further development. > However, a proper build server with multiple platforms and > configurations is something that is vary useful to have in > order to test branches before merging. Of course there is no replacement for testing, but I really can not agree if you are arguing that being unable to extend jenkins is a critical problem for further development. > I quite miss the previous method in which people could work on this > project progressing (and may do mistakes), but invest their time in > proactive way. What is stopping that? Please be specific. > I don't think that in current process I [or anyone similar] could have > contributed whatever I've done before, so I don't think it is going to > a good place. Why not? Please be specific. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Hello Peter, I wrote this before, but I think I need to write again... I think you are trying to make opensc something it is not. The bureaucracy and lack of flexibility will inhibit contributions and healthy *SMALL* community. That's true that it may eventually lead to more stable implementation, but the cost may be lack of progress, thus not able to achieve the stability goal as well. Until now I did not notice gerrit to be so good solution that all other methods should be dropped for of it. However, a proper build server with multiple platforms and configurations is something that is vary useful to have in order to test branches before merging. I quite miss the previous method in which people could work on this project progressing (and may do mistakes), but invest their time in proactive way. I don't think that in current process I [or anyone similar] could have contributed whatever I've done before, so I don't think it is going to a good place. Alon. On Sun, Mar 18, 2012 at 1:39 AM, Peter Stuge wrote: > Viktor Tarasov wrote: >> > What is it that does not currently work and which is >> > critical for developing perfect commits? > .. >> - replication in gerrit > > If you mean the mirroring of commits to github.com I don't see how > that is critical. Work with the repo in gerrit instead. Many projects > have no other. > > >> Should we manually push the perfect commits from gerrit's repo to >> staging? > > Define staging? It's not at all clear which repository you refer to. > The staging branch in gerrit's repo gets updated when changes are > submitted in gerrit. > > >> - nobody from the active persons has an admin access to jenkins -- >> no possibility to extend the current jobs, create the new ones >> and to build linux packages in continuous manner. > > I also don't see how jenkins is critical. > > > //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
Re: [opensc-devel] OpenSC and gerrit
Viktor Tarasov wrote: > > What is it that does not currently work and which is > > critical for developing perfect commits? .. > - replication in gerrit If you mean the mirroring of commits to github.com I don't see how that is critical. Work with the repo in gerrit instead. Many projects have no other. > Should we manually push the perfect commits from gerrit's repo to > staging? Define staging? It's not at all clear which repository you refer to. The staging branch in gerrit's repo gets updated when changes are submitted in gerrit. > - nobody from the active persons has an admin access to jenkins -- > no possibility to extend the current jobs, create the new ones > and to build linux packages in continuous manner. I also don't see how jenkins is critical. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Le 17/03/2012 22:32, Peter Stuge a écrit : > Viktor Tarasov wrote: >> Could you explain here how can we 'move forward', preferably >> without appealing to the absent persons and to the non-working >> services? > No, a "move forward" idea is broken from the start. > > Be specific. What is it that does not currently work and which is > critical for developing perfect commits? I posit nothing. Probably you have not read my mail. - replication in gerrit do not working. Should we manually push the perfect commits from gerrit's repo to staging? (In the github's pull requests the commits are also perfects, almost perfect.) - nobody from the active persons has an admin access to jenkins -- no possibility to extend the current jobs, create the new ones and to build linux packages in continuous manner. For these two points there is no visibility on when they could be resolved. This situation is lasting for months. Personally I would prefer to develop the OpenSC's card middleware, but in the current situation do not see the possibility. That's why I'm spending my time to get knowledge of jenkins and gerrit and to install an alternative way of 'moving forward'. > //Peter Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Viktor Tarasov wrote: > Could you explain here how can we 'move forward', preferably > without appealing to the absent persons and to the non-working > services? No, a "move forward" idea is broken from the start. Be specific. What is it that does not currently work and which is critical for developing perfect commits? I posit nothing. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Le 17/03/2012 22:03, Peter Stuge a écrit : > Viktor Tarasov wrote: >> I still propose to temporarily use the alternatives jenkins & gerrit. > It's IMO really stupid to fork anything, regardless if it is code or > infrastructure. You are amazedly brief. Could you explain here how can we 'move forward', preferably without appealing to the absent persons and to the non-working services? > > //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
Re: [opensc-devel] OpenSC and gerrit
Viktor Tarasov wrote: > I still propose to temporarily use the alternatives jenkins & gerrit. It's IMO really stupid to fork anything, regardless if it is code or infrastructure. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Le 17/03/2012 19:13, Jean-Michel Pouré - GOOZE a écrit : > Le vendredi 16 mars 2012 à 23:36 +0100, Ludovic Rousseau a écrit : >> I finally succeeded in rebasing and approving some patched in the >> backlog. I still do not understand everything. I subscribed to the >> OpenSC project on gerrit so I should receive a email for any submitted >> patch. >> >> I also added Viktor Tarasov as a member of the Integrators group. >> Viktor, you should be able to approve patches now. > Thanks a lot for your work and adding Viktor in the group. Thanks. Gerrit still has replication problem -- 'staging' of OpenSC/OpenSC.git do not updated by merges of Gerrit's repository. Certainly, gerrit is nice tool to play with, but, without replication it looses much of it's utility. More important, from my point of view, is jenkins. Somebody has to administrate jenkins to extend the existing jobs, create the new ones and include the build of Linux packages in continuous manner. Anybody can do it? I do not have such rights. That's why I still propose to temporarily use the alternatives jenkins & gerrit. Both were tested with 'staging' of OpenSC and 'secure-messaging' of OpenSC-SM on Debian, Win32 and Win64. With the graceful cooperation of Jean-Michel this jenkins should include the MacOS and other slaves and to build the linux packages. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Le vendredi 16 mars 2012 à 23:36 +0100, Ludovic Rousseau a écrit : > I finally succeeded in rebasing and approving some patched in the > backlog. I still do not understand everything. I subscribed to the > OpenSC project on gerrit so I should receive a email for any submitted > patch. > > I also added Viktor Tarasov as a member of the Integrators group. > Viktor, you should be able to approve patches now. Thanks a lot for your work and adding Viktor in the group. -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
