Hello,
The staging branch has some nice changes, in particular I'm interested in Stef's mlock fixes. Would it be possible to have a new opensc tarball release off the staging branch, please? P.S. Why is the development happening on 'staging'? In most open source projects the 'master' branch is the development branch, which a lot of people have come to expect. -- Thanks, Kalev _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
Le dimanche 29 avril 2012 à 23:50 +0300, Kalev Lember a écrit :
> The staging branch has some nice changes, in particular I'm interested > in Stef's mlock fixes. Would it be possible to have a new opensc > tarball > release off the staging branch, please? Most of the development is happening in the secure messaging branch and installers are released from the compilation farm. You may download tarballs and installers from there: http://www.opensc-project.org/downloads/nightly/sm/ We will soon release a testing farm with smarcards and USB tokens attached. So you can safely go with the secure messaging branch. 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 |
On 04/30/2012 12:06 PM, Jean-Michel Pouré - GOOZE wrote:
> Most of the development is happening in the secure messaging branch and > installers are released from the compilation farm. [...] > We will soon release a testing farm with smarcards and USB tokens > attached. So you can safely go with the secure messaging branch. Hi Jean-Michel, Thanks for your reply. What I am looking for is an official release, something that Linux distributions could pick up. A snapshot of another development branch wouldn't really help me here, but I appreciate the suggestion. I'm sure there's a lot of nice work going into the secure messaging branch, but that shouldn't stop the 0.12.3 release. There will always be some great new stuff to merge, but it's also important to be able to get regular releases out, based on the already merged code. -- Thanks, Kalev _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
Le mardi 01 mai 2012 à 21:00 +0300, Kalev Lember a écrit :
> > What I am looking for is an official release, something that Linux > distributions could pick up. A snapshot of another development branch > wouldn't really help me here, but I appreciate the suggestion. At some point, the SM branch will deprecate other branches: * This is where most development is done. * We have a complete approach of a quality circle, starting with frequent updates and ending with package releases and automatic testing. OpenSC hackers are encouraged to switch to SM branch. 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 |
On 5/2/2012 8:22 AM, Jean-Michel Pouré - GOOZE wrote: > Le mardi 01 mai 2012 à 21:00 +0300, Kalev Lember a écrit : >> >> What I am looking for is an official release, something that Linux >> distributions could pick up. A snapshot of another development branch >> wouldn't really help me here, but I appreciate the suggestion. > > At some point, the SM branch will deprecate other branches: > * This is where most development is done. > * We have a complete approach of a quality circle, starting with > frequent updates and ending with package releases and automatic testing. > > OpenSC hackers are encouraged to switch to SM branch. That still does not answer the questions: What will be in the next "Official" release and when? Will SM be in it? The SM branch has pulled in many other changes (including my C_Derive changes) that I would like to see in the next release. If the SM branch is not going to be the bases for the next release, then we need to look at what change in the SM branch can be pulled in to the release. Martin, I would like to hear your comments. > > Kind regards, > > > > _______________________________________________ > 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 |
On Wed, May 2, 2012 at 4:31 PM, Douglas E. Engert <[hidden email]> wrote:
Also do I. I still propose to merge the SM branch into the github:OpenSC-staging and prepare it as candidate for release . It should not be difficult, recently both branches has been synchronized. One more argument is that the alternative CI server should soon be ready for the automatic packaging and later for the automatic testing. It could be useful when preparing new release. > Kind regards, Kind wishes, Viktor. _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
Viktor Tarasov wrote:
> I still propose to merge the SM branch into the github:OpenSC-staging > and prepare it as candidate for release . It should not be difficult, > recently both branches has been synchronized. The difficulty lies not in making something that builds, the difficulty lies in understanding every single changed line of code. There hasn't been very much review. //Peter _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
On Thu, May 3, 2012 at 12:35 AM, Peter Stuge <[hidden email]> wrote:
You've already told this months ago. Something has been changed? Have you something else to propose, taking into account the available human resources ?
Reviewer, the one that can review something more than 'trailing whitespaces', needs some motivation. This motivation is stimulated by responsiveness of the project to his aspirations.
There was unusual period of absence of dialogue in the OpenSC project, so, I suggest the unusual means to restore the normal dialogue.
_______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
> There hasn't been very much review.
Dear Peter. I hope that we will be switching from peer-review to community-assisted-review, which means automatic testing tools. As Viktor wrote, we have to take into account that there is limited Human Resources for OpenSC and that we need to go fast to reach a large audience. 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 Douglas E. Engert
Hello,
On Wed, May 2, 2012 at 5:31 PM, Douglas E. Engert <[hidden email]> wrote: > The SM branch has pulled in many other changes (including > my C_Derive changes) that I would like to see in the next release. > If the SM branch is not going to be the bases for the next release, > then we need to look at what change in the SM branch can be pulled in > to the release. > > Martin, I would like to hear your comments. Obviously Viktor and others have had way more time in their hands to work on OpenSC than me :) Also obvious is that the most active branch is supposed to be merged as the basis for next release, which was more or less the idea of Git in the first place. As the recovery option, the sync problem between Gerrit and github needs to be cleared. Too much integration is probably not a good idea, two-way syncing between github pull request and Gerrit has brought no obvious benefits... The most straightforward approach would probably be forcing the github tree into opensc-project.org and clearing Gerrit... Martin _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
On 5/25/2012 6:04 AM, Martin Paljak wrote: > Hello, > > On Wed, May 2, 2012 at 5:31 PM, Douglas E. Engert<[hidden email]> wrote: >> The SM branch has pulled in many other changes (including >> my C_Derive changes) that I would like to see in the next release. >> If the SM branch is not going to be the bases for the next release, >> then we need to look at what change in the SM branch can be pulled in >> to the release. >> >> Martin, I would like to hear your comments. > > Obviously Viktor and others have had way more time in their hands to > work on OpenSC than me :) > > Also obvious is that the most active branch is supposed to be merged > as the basis for next release, which was more or less the idea of Git > in the first place. > > As the recovery option, the sync problem between Gerrit and github > needs to be cleared. Too much integration is probably not a good idea, > two-way syncing between github pull request and Gerrit has brought no > obvious benefits... > > The most straightforward approach would probably be forcing the github > tree into opensc-project.org and clearing Gerrit... > > Martin Sounds reasonable, but how do we avoid these types of problems in the future? No two-way syncing, with Gerrit or GitHub as the master? > > -- 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 |
Le 25/05/2012 18:09, Douglas E. Engert a écrit :
> > On 5/25/2012 6:04 AM, Martin Paljak wrote: >> Hello, >> >> On Wed, May 2, 2012 at 5:31 PM, Douglas E. Engert<[hidden email]> wrote: >>> The SM branch has pulled in many other changes (including >>> my C_Derive changes) that I would like to see in the next release. >>> If the SM branch is not going to be the bases for the next release, >>> then we need to look at what change in the SM branch can be pulled in >>> to the release. >>> >>> Martin, I would like to hear your comments. >> Obviously Viktor and others have had way more time in their hands to >> work on OpenSC than me :) >> >> Also obvious is that the most active branch is supposed to be merged >> as the basis for next release, which was more or less the idea of Git >> in the first place. >> >> As the recovery option, the sync problem between Gerrit and github >> needs to be cleared. Too much integration is probably not a good idea, >> two-way syncing between github pull request and Gerrit has brought no >> obvious benefits... >> >> The most straightforward approach would probably be forcing the github >> tree into opensc-project.org and clearing Gerrit... Before, I propose to gather into the github staging all pending proposals. After use this branch as the base for the next release: test this branch as far as possible, firstly using the automated packaging and tests, then extended manual tests with number of cards. For the future use the github OpenSC as the main repository for development and packaging. Connected to CI service, GitHub gives similar possibilities to analyze and validate proposals as Gerrit do. (I do not yet tried to connect github pull request to Jenkins, but I think it's possible.) By the way, Martin, will it be possible to add to the github OpenSC/OpenSC the web-hook with URL of my jenkins service? I need it for the 'staging' of OpenSC/OpenSC, where I would like to use trigger by commit and also to try the build of pull requests. >> Martin > Sounds reasonable, but how do we avoid these types of problems in the future? > No two-way syncing, with Gerrit or GitHub as the master? Kind regards, Viktor. _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
Le samedi 26 mai 2012 à 23:13 +0200, Viktor Tarasov a écrit :
> Before, I propose to gather into the github staging all pending > proposals. > After use this branch as the base for the next release: > test this branch as far as possible, firstly using the automated > packaging and tests, > then extended manual tests with number of cards. I agree with that. Also: Sufficient privileges in GIThub should be granted to a group of people. Trust is enough to agree on commits. FOAS means "Free" and "Open". 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 |
2012/5/27 Jean-Michel Pouré - GOOZE <[hidden email]>:
> Sufficient privileges in GIThub should be granted to a group of people. > Trust is enough to agree on commits. FOAS means "Free" and "Open". FOAS = ? According to http://acronyms.thefreedictionary.com/FOAS we have: FOAS Future Offensive Air System FOAS Fiber Optic Acoustic Sensors (Northrop Grumman) FOAS First Order Abstract Syntax (computing) FOAS Fall of Autumn Skies (band; Australia) FOAS Friends of Albert Schweitzer (England, UK) FOAS Footsteps of a Stranger (song) FOAS Friends of the Animal Shelter of St. Bernard, Inc. (Chalmette, LA) Is it one of them? :-) Bye -- Dr. Ludovic Rousseau _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
Ludovic Rousseau wrote:
> 2012/5/27 Jean-Michel Pouré - GOOZE <[hidden email]>: > > Sufficient privileges in GIThub should be granted to a group of people. > > Trust is enough to agree on commits. FOAS means "Free" and "Open". > > FOAS = ? I guess FOSS. The "open" does however not mean that the entire world must have write access, it's about read access. "Trust is enough to agree on commits." makes no sense whatsoever to me. The closest that makes sense to me would be: Trust comes from agreeing on commits. Of course everyone has different priorities. It makes me sad that quality isn't the top priority for everyone in the project. //Peter _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
On Sun, May 27, 2012 at 7:38 PM, Peter Stuge <[hidden email]> wrote:
> Ludovic Rousseau wrote: >> 2012/5/27 Jean-Michel Pouré - GOOZE <[hidden email]>: >> > Sufficient privileges in GIThub should be granted to a group of people. >> > Trust is enough to agree on commits. FOAS means "Free" and "Open". >> >> FOAS = ? > > I guess FOSS. > > The "open" does however not mean that the entire world must have > write access, it's about read access. > > "Trust is enough to agree on commits." makes no sense whatsoever to me. > > The closest that makes sense to me would be: > > Trust comes from agreeing on commits. > > Of course everyone has different priorities. It makes me sad that > quality isn't the top priority for everyone in the project. Peter, quality is not absolute term. It can be mathematic definition of the best algorithm, which can lead to infinite theoretical discussion for each line of code. It might be physical definition of what is "good enough", and even then, the border is also not absolute, as what good enough for one is not good enough to other. And it can be the service provided to users and the responsive to user's issues. I, personally, for (3), providing a great service and responsiveness while perfecting the code as 2nd priority (exception are interfaces). I think this approach was taken at opensc in the past. I also like the (2) approach, while trusting the active core developers to define what is "good enough", and if someone thinks otherwise he is free to become core developer or show the code of his alternatives to the point it is accepted by the core developers. Agree on commits is not something that can become reality as without someone who can actually DECIDE, there can be non-ending arguments for each change. We have this exact issue at OpenVPN project, which also reached a complete stop as it does not have core developers and clear responsibility for subsystems. I am sad as this project (as it seems) reached a complete stop. Programming is human creative work, there can be N^^N ways to acquire a goal, very hard to evaluate what is "correct" or "better" in most of the cases, it depends on the people involved and the people who actually review at specific point in time... Same change can be accepted at week X and rejected at week Y as other people review. Because of that trust in the "core developers" of a project is essential, as it is the only constant factor in the process. Not sure what this discussion was, but I wanted to comment your statement. Regards, Alon. _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
Alon Bar-Lev wrote:
> Peter, quality is not absolute term. In computing I actually think it is; a high quality program does exactly what it is supposed to do and never anything else. Computers are very simple machines, so it is feasible for humans to create such programs. > best algorithm > "good enough" > service and responsive to user's issues > > I, personally, for (3), providing a great service and responsiveness > while perfecting the code as 2nd priority (exception are interfaces). > I think this approach was taken at opensc in the past. It doesn't work unless there's lots of feedback from users however. > I also like the (2) approach, while trusting the active core > developers to define what is "good enough", and if someone thinks > otherwise he is free to become core developer or show the code of his > alternatives to the point it is accepted by the core developers. Right, the real fun starts when the core developers actually don't agree on anything, or just have different areas of expertise. And pack mentality comes into play if the core developer pack is smaller than the opposition. Ideally the core developer pack is large enough to assimilate and mentor opposition before any conflicts, but personally I prefer to focus on code over trying to educate someone who insists on doing things their own way in any case. > Agree on commits is not something that can become reality as without > someone who can actually DECIDE, there can be non-ending arguments for > each change. The definition of agreement would be that multiple people decide the same thing. > We have this exact issue at OpenVPN project, which also reached a > complete stop as it does not have core developers and clear > responsibility for subsystems. I guess that perfect commits will still be included in the codebase? > Programming is human creative work, there can be N^^N ways to acquire > a goal, very hard to evaluate what is "correct" or "better" in most of > the cases, it depends on the people involved and the people who > actually review at specific point in time... I'd say that it must only ever depend on the users and never on the developers. But of course you are right in that developers must often try to judge what users want and need. > Same change can be accepted at week X and rejected at week Y as > other people review. Unfortunately yes, when there is not much agreement in the core developer pack. > Because of that trust in the "core developers" of a project is > essential, as it is the only constant factor in the process. But the trust doesn't materialize out of thin air. My point was that trust tends to come (at least for me) when there's also strong agreement. > Not sure what this discussion was, but I wanted to comment your > statement. Thanks for the comment - you make many valid points! It's a very interesting discussion, but of course we're already off topic for opensc since long. :) //Peter _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
On Sun, May 27, 2012 at 8:26 PM, Peter Stuge <[hidden email]> wrote:
> Alon Bar-Lev wrote: >> Peter, quality is not absolute term. > > In computing I actually think it is; a high quality program does > exactly what it is supposed to do and never anything else. > > Computers are very simple machines, so it is feasible for humans to > create such programs. :) Well, this is similar to what I thought ~20 years ago... and I know you are not young either... Although I think I can reach to this point near the one you refer to, over the years I meet a lot of people that in my view reached a father point which was not perfect but good enough for the use case. Perfecting anything derives infinite resources or very talented resources. I prefer to invest resources in finding the segments where the potential of side effect is high, and manage these ones, well, unless I am the developer my-self :) > >> best algorithm >> "good enough" >> service and responsive to user's issues >> >> I, personally, for (3), providing a great service and responsiveness >> while perfecting the code as 2nd priority (exception are interfaces). >> I think this approach was taken at opensc in the past. > > It doesn't work unless there's lots of feedback from users however. If nobody use the software, maybe the whole effort is void... >> I also like the (2) approach, while trusting the active core >> developers to define what is "good enough", and if someone thinks >> otherwise he is free to become core developer or show the code of his >> alternatives to the point it is accepted by the core developers. > > Right, the real fun starts when the core developers actually don't > agree on anything, or just have different areas of expertise. And > pack mentality comes into play if the core developer pack is smaller > than the opposition. Right. The core developers must be a group that shares the same vision and methods. If core developers do not agree, project should either fork or someone should resign. > Ideally the core developer pack is large enough to assimilate and > mentor opposition before any conflicts, but personally I prefer to > focus on code over trying to educate someone who insists on doing > things their own way in any case. I don't understand this statement. The code is only a mean to achieve a goal. If a group of people does not agree on the basics, such as modularity vs monolithic design, readability vs performance, customization vs pre-defined, interfaces methodology -- what help is in focusing at code? I do understand that there is value in focusing at code in stable maintenance mode, but I don't see this is possible when project need to evolve. >> Agree on commits is not something that can become reality as without >> someone who can actually DECIDE, there can be non-ending arguments for >> each change. > > The definition of agreement would be that multiple people decide the > same thing. Right. And what if this cannot be achieved? For example, let's take OpenVPN case... a patch was submitted in order to support the Android platform. This is a good cause indeed, I think everyone agree that supporting Android is required. There are about 5 possible integration methods achieve this goal, the quick and dirty which adds the code within #ifdef, there is more conservative way to add the required features of this specific platform to the common linux platform, even if it is unique to the UI implementation of this platform, <skipping some other>, and there is a way to perform this as external plugin provided we delegate some more functionality to the plugin. So the question is not about the code, the submitted code can be perfect. The discussion is about methodology, maintenance costs, and flexibility to solve similar issues in future. How do you decide which group of people should agree on what? My solution is to divide core developers by subsystems and assign small number of core developers (2) to he project as a whole, to be able to decide on issues that cannot reach to agreement. Example: OpenSC is divided into [at least] the following subsystems: build, PKCS#11, PKCS#15 core, {reader} interface, {card} driver, windows. For each one core developer should be assigned as accounted to any change in the subsystem, bug or improvement. In one scenario it can be the same core developer for all, but I there is advantage of allowing delegation. So if core developer X is in charge of card driver GPG, it has the full permission (trust) from the community to perfect this driver as he see fit. As a result you have different quality level of different drivers, that's true, and this is acceptable cost for open source which is based on volunteers, the larger the user base, the large the developer base, the better quality that can eventually reached. >> We have this exact issue at OpenVPN project, which also reached a >> complete stop as it does not have core developers and clear >> responsibility for subsystems. > > I guess that perfect commits will still be included in the codebase? I tried to provide a use case above, there are no perfect patch, except when project is in stable maintenance mode (stability, security, pin-point bugs). >> Programming is human creative work, there can be N^^N ways to acquire >> a goal, very hard to evaluate what is "correct" or "better" in most of >> the cases, it depends on the people involved and the people who >> actually review at specific point in time... > > I'd say that it must only ever depend on the users and never on the > developers. But of course you are right in that developers must often > try to judge what users want and need. True... about 20 years ago I saw an IBM platform for AS/400 which tried to provide the user with a graphic tool to develop his own database application, it was very impressive! I remembered I was so impressed, to a point I thought that we are at a verge of change. But then technology got even more complex. So users are still at the hands of the developers, and the quality of the solution users get depends upon the quality of the developers. >> Same change can be accepted at week X and rejected at week Y as >> other people review. > > Unfortunately yes, when there is not much agreement in the core > developer pack. >> Because of that trust in the "core developers" of a project is >> essential, as it is the only constant factor in the process. > > But the trust doesn't materialize out of thin air. My point was that > trust tends to come (at least for me) when there's also strong > agreement. Few "observers" of mine: 1. The average level of developers who are acting as core developer at open source is higher than the average in commercial companies. 2. The process of becoming a core developer usually involved in proving the quality of the work for some time, hence obtaining trust. 3. Whoever has time to act as core developer of open source project is entitled to some credit, he is donating something others not, even if it is not the perfect solution, it is progressing the ability to provide solution out of the commercial world. 4. Whoever who rejects a core developer's work should be prepared to show the code of his alternatives, and not expect someone else (core developer) to do the work for him. 5. ==> Core developers should be trusted as a group and as individuals in order to make things actually happen. >> Not sure what this discussion was, but I wanted to comment your >> statement. > > Thanks for the comment - you make many valid points! It's a very > interesting discussion, but of course we're already off topic for > opensc since long. :) Right. Sorry. I don't think it relates to opensc project. I follow quite large number of open source projects, I think that project without clear leadership such as opensc and openvpn tend to come to a complete stop after a short while of stable maintenance mode. Project with clear leadership such as KDE, xorg, bluez, linux do progress [=provide service to their users] even if their changes are not perfect. Alon. _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
Le dimanche 27 mai 2012 à 22:26 +0300, Alon Bar-Lev a écrit :
> >> I, personally, for (3), providing a great service and > responsiveness > >> while perfecting the code as 2nd priority (exception are > interfaces). > >> I think this approach was taken at opensc in the past. My definition for quality is that: * Quality is a circle: Quality works as a circle from the developers to a small group of beta testers to the public at large. For one developer, there are 10 people providing patches, 50 beta testers and 10.000 users at large. Quality arises from the ability to work in circle and get better: => publish first version of code, debug, find errors, provide patches, test and apply patches. Publish second version of code ... * Speed is quality As this is circle, speed is important. Not developing speed, but the speed of the circle at large. In the case of OpenSC, there are dozens of patches waiting. So not applying them is breaking the quality circle and killing the project. * Developers v.s. core developers The notion of core-developer is simple: it is someone with (1) technical skills and (2) communications skills who (3) is trusted by the community and (4) acts for the sake of the project (5) without asking for money or selling services (directly) linked to commits. In my opinion, Alon falls in this category and should be an OpenSC code developer. But there are many others as well. By the way, I have been working all day long on the QA farm and it is now accessible. I will post on a separate thread. It is very simple and needs some improvement. With the help of the community. What I suggest is that OpenSC should be hosted on GIThub with write access to core developers (at least 5/6 people). This is more or less the proposal of Martin. 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:
> What I suggest is that OpenSC should be hosted on GIThub with write > access to core developers (at least 5/6 people). Insisting on changing some hosting situation that has been set up is nothing but obnoxious protesting and spitting on the already established hosting. Centering development around github.com brings no benefits whatsoever over opensc-project.org. The latter allows the project to do nice integration and customization of all tools. Github not so much. //Peter _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc-project.org/mailman/listinfo/opensc-devel |
Free forum by Nabble | Edit this page |