new release?

[Kalev Lember-2]

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

[Jean-Michel Pouré - GOOZE]

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

[Kalev Lember-2]

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

[Jean-Michel Pouré - GOOZE]

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

[Douglas E. Engert]

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
  [phone]
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Viktor Tarasov-3]

On Wed, May 2, 2012 at 4:31 PM, Douglas E. Engert <[hidden email]> wrote:

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.

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

[Peter Stuge-4]

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

[Viktor Tarasov-3]

On Thu, May 3, 2012 at 12:35 AM, Peter Stuge <[hidden email]> wrote:

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.

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.

//Peter

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Jean-Michel Pouré - GOOZE]

>         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

[Martin Paljak-4]

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

[Douglas E. Engert]

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
  [phone]
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Viktor Tarasov-3]

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

[Jean-Michel Pouré - GOOZE]

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

[Ludovic Rousseau]

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

[Peter Stuge-4]

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

[Alon Bar-Lev]

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

[Peter Stuge-4]

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

[Alon Bar-Lev]

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

[Jean-Michel Pouré - GOOZE]

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

[Peter Stuge-4]

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