Re: [opensc-devel] FOSS development
Insisting on changing some hosting situation that has been set up is nothing but obnoxious protesting and spitting on the already established hosting. Peter, do you mean that moving OpenSC to GIThub and opening administration to a group of core developers would be obnoxious and spitting on established hosting. Can you elaborate on that and be more precise? 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] FOSS development
On Sun, May 27, 2012 at 11:59 PM, Peter Stuge pe...@stuge.se wrote: 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. Peter, probably it useless, but may I bring once more to your attention the fact that github is set into the center for Development Policy by Martin himself. Look onto the diagram in https://www.opensc-project.org/opensc/wiki/DevelopmentPolicy . 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. What integration do you mean? On opensc-project.org the tarball, MSI and DMG are built. No RPMs, DEB, no automated tests, ... 'Customization of all tools' -- what tools do you mean ? Effectively, it would be nice to build and publish Linux packages, connect automated tests, include other OpenSC sub-projects, ... But who will do all this on opensc-project.org? Martin have no time, no one else can/allowed to do something. Beside the necessity of the perfect commits, can you propose something else? Kind regards, Viktor. //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] FOSS development
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 opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] FOSS development
On Sun, May 27, 2012 at 8:26 PM, Peter Stuge pe...@stuge.se 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
Re: [opensc-devel] FOSS development
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 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] FOSS development
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 opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
