OpenSC write access to main trunk, discussion

classic Classic list List threaded Threaded
60 messages Options
123
Reply | Threaded
Open this post in threaded view
|

OpenSC write access to main trunk, discussion

Jean-Michel Pouré - GOOZE
Dear all,

I just got in contact with Stef Walter, who is integrating libp11-glue
into Gnome and Gnome keyring.

He outlines that libp11-glue needs this patch:
PKCS#11 module shouldn't fail if mlock doesn't work
http://www.opensc-project.org/opensc/ticket/389

This patch and other waiting patches raise the question of OpenSC
guidance and the need to have more commiters to OpenSC main GIT.

Martin, would you agree to add Viktor as a major OpenSC GIT member with
power to apply patches to main GIT trunk? I don't want to be paranoid,
but we need a more flexible approach rather than just Martin and Ludovic
applying and reviewing patches.

We discussed that at FOSDEM in a small audience, but I would like to
discuss that issue in public and have your own opinion. Who would like
OpenSC GITHUB to be REALLY in control of the community? Martin and
Ludovic, could you agree to open your group to other members of the
community?

Community, please advice and discuss this issue.

Kind regards,
Jean-Michel

--
                  Jean-Michel Pouré - Gooze - http://www.gooze.eu

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

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC write access to main trunk, discussion

Douglas E. Engert


On 2/15/2012 5:39 AM, Jean-Michel Pouré - GOOZE wrote:

> Dear all,
>
> I just got in contact with Stef Walter, who is integrating libp11-glue
> into Gnome and Gnome keyring.
>
> He outlines that libp11-glue needs this patch:
> PKCS#11 module shouldn't fail if mlock doesn't work
> http://www.opensc-project.org/opensc/ticket/389
>
> This patch and other waiting patches raise the question of OpenSC
> guidance and the need to have more commiters to OpenSC main GIT.
>
> Martin, would you agree to add Viktor as a major OpenSC GIT member with
> power to apply patches to main GIT trunk? I don't want to be paranoid,
> but we need a more flexible approach rather than just Martin and Ludovic
> applying and reviewing patches.
>
> We discussed that at FOSDEM in a small audience, but I would like to
> discuss that issue in public and have your own opinion. Who would like
> OpenSC GITHUB to be REALLY in control of the community? Martin and
> Ludovic, could you agree to open your group to other members of the
> community?

The question is not so much who is on the commiter list, but do commits
get made when needed, and who decides a commit is ready and should be made.

There are minor fixes, like 389 that is 4 months old with an additional
fix 2 months ago, and looks like it needs to be made, as well as major
changes such as the SM, ePass2003, and the ECDH modifications.

Personally, I am quite interested in getting the ECDH in to the next
release with or without the SM code and am willing to rebase the
modifications as needed.  I believe the ECDH has been ready for months.

Viktor pulled the ECDH modifications into his SM on October 4, 2011 and
he also pulled in the ePass2003 on January 29.

The way forward is not necessarily more commiters, but a plan
for the next release and some action.

So can we consider adding ePass2003, SM, and ECDH to the next release
as these are already being tested together.

If giving Viktor commit authority would speed up the inclusion of both small
and larger modifications, it would be OK with me. If we can get these
included without giving him commit authority, that would be OK
with me too. But we need action.

>
> Community, please advice and discuss this issue.
>
> Kind regards,
> Jean-Michel
>
>
>
>
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC write access to main trunk, discussion

Alon Bar-Lev
Hello,

On Thu, Feb 16, 2012 at 11:53 PM, Douglas E. Engert <[hidden email]> wrote:
> The way forward is not necessarily more commiters, but a plan
> for the next release and some action.

Well, once there was maintainer for each subject, so if maintainer of
(in this case) ePass2003 decides to put a specific implementation it
should be OK.

If another one is working on SM and it effects only specific drivers, why not?

For example, I don't think I need to beg to include the removal of the
libltdl dependency should be trivial even if I got this only 99%.

This project loses its flexibility, this is not an advantage.

You can decide which feature goes to which milestone, and cooperate
with people within different branches.

Alon.
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC write access to main trunk, discussion

Peter Stuge-4
Alon Bar-Lev wrote:
> This project loses its flexibility, this is not an advantage.

I disagree. I find that Git allows all the flexibility developers
could ask for.

The cry for more committers is misguided. With Git, anyone and
everyone is a committer. If commits exist but are not being included
in the main repository then it is most likely because they need more
work. The effort required to include a perfect patch is next to zero.

The question is if a project will insist on perfect patches (e.g.
Linux) or if anyone should be allowed to commit anything to the main
repo. Inkscape apparently did the latter, and it resulted in a
massive janitorial workload to clean up the horrible mess that had
been created. No fun.

Consider also that addition of commits without review will quite
likely introduce bugs which would have been discovered by peers. I
think this fact alone is reason enough for OpenSC to not include a
single line which hasn't been reviewed rather thoroughly. The review
process could even be formalized and made into a strict requirement
before writes to the main repo are possible.

I understand that Gooze and others have strong interest in inclusion
of changes into OpenSC. The only way to make that happen is what
Douglas described; put in the work, and create perfect patches.

Write access to some repository is not the issue. The whole world
already has Git write access. If someone needs help with publishing a
repository then feel free to let me know.

If you have prepared a patch which you think is perfect but noone is
responding then give it a thorough review yourself, and try again.
Also try discussing the change, explaining it in an email can be a
great way to produce a better commit message, which is very important
for anyone who is doing review.

Note that review does not mean to browse through the change and say
"looks ok", but it means to understand the effects of every changed
line. This can require a lot of context and/or research.

You can help by that commit be included by doing review. You doing
review is infinitely more important than you having write access to
some repository.


//Peter
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC write access to main trunk, discussion

Jean-Michel Pouré - GOOZE
Le vendredi 17 février 2012 à 02:07 +0100, Peter Stuge a écrit :
> The cry for more committers is misguided. With Git, anyone and
> everyone is a committer. If commits exist but are not being included
> in the main repository then it is most likely because they need more
> work. The effort required to include a perfect patch is next to zero.

The question here is flexibility:

* OpenSC used to have a very flexible approach. OpenSC is NOT kernel.org
with thousands of developers and no need for hierarchy.

* Setting-up a compilation farm is no reason for closing write access to
historical developers of OpenSC.

* Discussions are the base of Free Software. Once discussions have
occurred, there should be several people with write access. You have to
trust people. No need to lock write access to the main GIT.

From my point of view, OpenSC is becoming a semi-private project with
two people in charge: Ludovic and Martin. Personally, I don't want
OpenSC to be organized the same way as libccid.

We demand more freedom and transparency or this can only lead to endless
flamewars.

Keep in mind that before doing business, I have been a politician
fighting during 4 years for more freedom. Now I am retired, but if need
be, we will create a charity for OpenSC and organize a duly elected
board. I am not talking about a fork, which will never happen, but about
elections.

Kind regards,
--
                  Jean-Michel Pouré - Gooze - http://www.gooze.eu

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

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC write access to main trunk, discussion

Peter Stuge-4
Jean-Michel Pouré - GOOZE wrote:
> > With Git, anyone and everyone is a committer.
>
> The question here is flexibility:

What flexibility is needed? My point is that everyone can easily
create perfect patches, and given perfect patches which have been
peer reviewed there is no need for flexibility as in lots of people
with write access to the main repository. Even just one person can
easily handle that effort, like Linus shows in the much larger
kernel project.


> * OpenSC used to have a very flexible approach. OpenSC is NOT
> kernel.org with thousands of developers and no need for hierarchy.

OpenSC is smaller, but I do not agree that there is no need for any
kind of hierarchy. Now, please understand that this is not about
power hierarchy as in politics, but it is about technical experience
with the code and with the problem domain.

I am personally familiar with the smart card domain but I haven't
spent much time with the OpenSC codebase and therefore I absolutely
do not want some patch I create to be included without being reviewed
first.

The review is criticial. Especially in a codebase like OpenSC, to
which I might indeed delegate my legal authority, I want the review
to be merciless.

Don't make the mistake of believing that only people with write
access can do review. It is quite the opposite. I have been trying
to make this point many times before, but it seems difficult for many
to grasp that all peer review is helpful and important for the
codebase, regardless of who is doing it. Everyone who cares about a
software can and should help with review.

A side effect of doing review is of course that knowledge about the
codebase increases in the community. After having done some amount of
review, people might even get write access, because they have
demonstrated that they can be trusted. This is demonstrated by
finding difficult-to-spot problems in others' patches. It is not
demonstrated by quickly giving every patch a thumbs-up.

Some say that it feels pointless to do review for someone who does
not have write access. I disagree with this, and I think this is a
very dangerous, almost complacent, attitude. If you do not believe
that your review is worth anything to those with write access, why
should you yourself have write access? This becomes a negative spiral
where in the end a project has no resources to do review, simply
because people do not have enough self-esteem to believe that the
review they can contribute matters. I don't know what the answer is.
I've tried time and time again to convince people that doing review
is helpful and important and a significant contribution to any
project, but it often doesn't really stick.


> * Setting-up a compilation farm is no reason for closing write access
> to historical developers of OpenSC.

I agree, but I don't think one has anything to do with the other,
even if they happened at the same time. I guess that anyone who had
write access to the repository earlier can get it again if they just
send a public ssh key and their prefered username.


> * Discussions are the base of Free Software. Once discussions have
> occurred, there should be several people with write access. You
> have to trust people. No need to lock write access to the main GIT.

I disagree about having to trust people out of the blue. Generally,
people write really shitty software, and the poor way that a lot of
open source software works is all the proof we need.

I love open source, not neccessarily because it is technically
superior, but because it allows *me* to fix things which are broken.

I believe that open source is as good as it is primarily thanks to
the practise of peer review.

The purpose of more write access as far as I can see is to have
faster, ie. less well reviewed and thus less well understood, changes
in the main repo. I do not agree at all with that goal.


> From my point of view, OpenSC is becoming a semi-private project
> with two people in charge: Ludovic and Martin. Personally, I don't
> want OpenSC to be organized the same way as libccid.

I find both Martin and Ludovic to be quite reasonable people. I've
never had any problem discussing any issue with them, actually quite
the opposite.

If there are perfect patches (well reviewed, well understood) then I
am convinced that they would race each other to add those patches
into the repository.

I have no experience from libccid development, but I'm happy with it
as a user, so Ludovic must be doing something right.


> We demand more freedom and transparency or this can only lead to
> endless flamewars.

Let's focus on a concrete problem. Have you created a patch which has
been peer reviewed and is well understood, but has been rejected by
Martin and Ludovic? If yes, let's try to find a solution. If no, you
can't really demand more freedom and transparency, because you
haven't exercised the freedom to create perfect patches yet.

I did review the epass2003 commits when their availability was
announced, and I've looked at the entersafe github account
again just now. Here is some feedback:

There are three branches; ePass2003_1, epass2003 and ep2k3. These
names are non-descript.

Commit 902e637c is quite long with over 2k lines added for the card
driver. That seems much to me. It's infeasible for me as careful
programmer but OpenSC internals newbie to review this code. My gut
feeling is that much of the code could be factored out.

The commits are not very well described in the commit messages.

The commits include unrelated changes.

The commits include whitespace changes mixed with actual code
changes.

The following commit undoes some of the unrelated changes in the
previous one.

This is what was immediately obvious to me just by looking at one and
a half commits in one of the branches. The things I point out above
are all things which do not belong in a perfect patch, and do not
beling in the OpenSC codebase that I want to use.

All these things, and probably more!, must be obvious to any other
programmer who has looked at the commits. I do not believe that I
have some special vision and only I can see these things.

It seems to me that the commits have been created without
self-review, which is of course the very first thing to do before
proposing any change for inclusion.


> Keep in mind that before doing business, I have been a politician
> fighting during 4 years for more freedom.

I did not know - that is quite commendable! Thank you for working on
making the world a better place!

Keep in mind that open source is not a democracy.


> Now I am retired, but if need be, we will create a charity for
> OpenSC and organize a duly elected board. I am not talking about
> a fork, which will never happen, but about elections.

But elections do not increase code quality. I think software quality
is more important than flat democracy. The meritocracy that is open
source *is* a hierarchy. I don't think this is bad.


//Peter

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

attachment0 (197 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC write access to main trunk, discussion

Jean-Michel Pouré - GOOZE
Dear Peter,

Thank you for your time. In organization theory, there is no perfect
solution. There are several ways to achieve success.

Let us take two examples to see how OpenSC can be improved:

1) The ePass2003 code was reviewed by Viktor and included in his branch.
You probably did not know, did not compile, did not test and therefore
Viktor's work is ignored.

He needs and deserves write access to OpenSC main GIT to speed up
development. The reasons is that we need more new features, more beta
testers.

2) Take the example of Alon developments around PKCS#11. A lot of them
were ignored by OpenSSH. The reason is that when a small number of
people have a grasp on a project, strange things sometimes happen. I
would not like this to happen with OpenSC. Locking a project to a small
number of developers is not good.

IMHO, the way OpenSC used to be organized one year ago was superior,
because there was a central repository with all new features. More beta
features, more testers, larger market and superior quality.

This is no longer the case and each developers works in his corner. The
only collaborative work is what you call "peer review".

So my opinion would be to allow each developer to commit changes to the
main GITHUB staging (developing) branch after discussion. Like it used
to be the case using SVN. And make sure OpenSC is not only owned by one
or two people. This cannot ever happen, we don't agree with this
privatization.

The organization should be like:
* 4/5 committers
* 10/20 code contributors and developers
* 100 beta testers

Kind regards,
Jean-Michel

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

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC write access to main trunk, discussion

Nikos Mavrogiannopoulos
On 02/17/2012 10:58 PM, Jean-Michel Pouré - GOOZE wrote:

> Let us take two examples to see how OpenSC can be improved: 1) The
> ePass2003 code was reviewed by Viktor and included in his branch. You
> probably did not know, did not compile, did not test and therefore
> Viktor's work is ignored. He needs and deserves write access to
> OpenSC main GIT to speed up development. The reasons is that we need
> more new features, more beta testers.


[disclaimer I'm not experienced with opensc internals and comment might
be wrong]
This sounds pretty similar to the situation in hardware drivers which
often evolve faster than the linux kernel's pace. It might be better to
have a module approach for such development so that cutting edge drivers
can be used with opensc without recompilation or waiting for a new
opensc release. I don't know though, whether the size of the
projectjustifies something like that.

> 2) Take the example of Alon developments around PKCS#11. A lot of
> them were ignored by OpenSSH. The reason is that when a small number
> of people have a grasp on a project, strange things sometimes happen.
> I would not like this to happen with OpenSC. Locking a project to a
> small number of developers is not good.


In cases it might be good. We rejected Alon's PKCS #11 patches on gnutls
as well. You can say it was the wrong decision or so, but in the end of
day the few developers responsible for the project will have to maintain
it. If it is code they cannot maintain, or does not agree with the
longer term plans of the project maybe the feature should be postponed.

regards,
Nikos
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC write access to main trunk, discussion

Viktor Tarasov-3
In reply to this post by Douglas E. Engert
Le 16/02/2012 22:53, Douglas E. Engert a écrit :

>
> On 2/15/2012 5:39 AM, Jean-Michel Pouré - GOOZE wrote:
>> Dear all,
>>
>> I just got in contact with Stef Walter, who is integrating libp11-glue
>> into Gnome and Gnome keyring.
>>
>> He outlines that libp11-glue needs this patch:
>> PKCS#11 module shouldn't fail if mlock doesn't work
>> http://www.opensc-project.org/opensc/ticket/389
>>
>> This patch and other waiting patches raise the question of OpenSC
>> guidance and the need to have more commiters to OpenSC main GIT.
>>
>> Martin, would you agree to add Viktor as a major OpenSC GIT member with
>> power to apply patches to main GIT trunk? I don't want to be paranoid,
>> but we need a more flexible approach rather than just Martin and Ludovic
>> applying and reviewing patches.
>>
>> We discussed that at FOSDEM in a small audience, but I would like to
>> discuss that issue in public and have your own opinion. Who would like
>> OpenSC GITHUB to be REALLY in control of the community? Martin and
>> Ludovic, could you agree to open your group to other members of the
>> community?
> The question is not so much who is on the commiter list, but do commits
> get made when needed, and who decides a commit is ready and should be made.
>
> There are minor fixes, like 389 that is 4 months old with an additional
> fix 2 months ago, and looks like it needs to be made, as well as major
> changes such as the SM, ePass2003, and the ECDH modifications.
>
> Personally, I am quite interested in getting the ECDH in to the next
> release with or without the SM code and am willing to rebase the
> modifications as needed.  I believe the ECDH has been ready for months.
>
> Viktor pulled the ECDH modifications into his SM on October 4, 2011 and
> he also pulled in the ePass2003 on January 29.
>
> The way forward is not necessarily more commiters, but a plan
> for the next release and some action.

As I understand the current policy, the patch acceptance policy is resumed in:
- fixes for crying bugs go to 'master';
- little fixes, evident limited patch goes to 'staged';
- more consequent proposals pass to Gerrit and here waits for approval to be applied to 'staged'.

Current problem is that the process is stagnated on the Gerrit level.
For some obscure reasons Martin do not participates in Gerrit review/acceptance procedures, as well as Ludovic.
Nobody else have sufficient authority to do it.

Martin has pushed to Gerrit part of SM branch. What are the intentions for the rests?
What about next release? What should be included into?
How can be tested the compatibility of different proposals?

Personally I do not look for additional rights,
as Douglas, I'm interested in some action and ready to help to move the things forward.
And so, would like to have this possibility.


Also Jenkins is dead for some time already.
What shall we do?
Wait? Mount temporary service of limited volume -- at least for OpenSC/'staged' and few other branches ?


> So can we consider adding ePass2003, SM, and ECDH to the next release
> as these are already being tested together.
>
> If giving Viktor commit authority would speed up the inclusion of both small
> and larger modifications, it would be OK with me. If we can get these
> included without giving him commit authority, that would be OK
> with me too. But we need action.
>
>> Community, please advice and discuss this issue.
>>
>> Kind regards,
>> Jean-Michel
>>
>>
>>
>>
>> _______________________________________________
>> opensc-devel mailing list
>> [hidden email]
>> http://www.opensc-project.org/mailman/listinfo/opensc-devel

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC write access to main trunk, discussion

Ludovic Rousseau
Le 18 février 2012 04:59, Viktor Tarasov <[hidden email]> a écrit :

> Le 16/02/2012 22:53, Douglas E. Engert a écrit :
>>
>> On 2/15/2012 5:39 AM, Jean-Michel Pouré - GOOZE wrote:
>>> Dear all,
>>>
>>> I just got in contact with Stef Walter, who is integrating libp11-glue
>>> into Gnome and Gnome keyring.
>>>
>>> He outlines that libp11-glue needs this patch:
>>> PKCS#11 module shouldn't fail if mlock doesn't work
>>> http://www.opensc-project.org/opensc/ticket/389
>>>
>>> This patch and other waiting patches raise the question of OpenSC
>>> guidance and the need to have more commiters to OpenSC main GIT.
>>>
>>> Martin, would you agree to add Viktor as a major OpenSC GIT member with
>>> power to apply patches to main GIT trunk? I don't want to be paranoid,
>>> but we need a more flexible approach rather than just Martin and Ludovic
>>> applying and reviewing patches.
>>>
>>> We discussed that at FOSDEM in a small audience, but I would like to
>>> discuss that issue in public and have your own opinion. Who would like
>>> OpenSC GITHUB to be REALLY in control of the community? Martin and
>>> Ludovic, could you agree to open your group to other members of the
>>> community?
>> The question is not so much who is on the commiter list, but do commits
>> get made when needed, and who decides a commit is ready and should be made.
>>
>> There are minor fixes, like 389 that is 4 months old with an additional
>> fix 2 months ago, and looks like it needs to be made, as well as major
>> changes such as the SM, ePass2003, and the ECDH modifications.
>>
>> Personally, I am quite interested in getting the ECDH in to the next
>> release with or without the SM code and am willing to rebase the
>> modifications as needed.  I believe the ECDH has been ready for months.
>>
>> Viktor pulled the ECDH modifications into his SM on October 4, 2011 and
>> he also pulled in the ePass2003 on January 29.
>>
>> The way forward is not necessarily more commiters, but a plan
>> for the next release and some action.
>
> As I understand the current policy, the patch acceptance policy is resumed in:
> - fixes for crying bugs go to 'master';
> - little fixes, evident limited patch goes to 'staged';
> - more consequent proposals pass to Gerrit and here waits for approval to be applied to 'staged'.
>
> Current problem is that the process is stagnated on the Gerrit level.
> For some obscure reasons Martin do not participates in Gerrit review/acceptance procedures, as well as Ludovic.
> Nobody else have sufficient authority to do it.

I don't know why only Martin and myself are integrators on Gerrit.

I reviewed some patches but don't know what to do next. It looks like
the patches are not moved to github/staging. Maybe a configuration
problem?
Note: this is my first use of Gerrit.

> Martin has pushed to Gerrit part of SM branch. What are the intentions for the rests?
> What about next release? What should be included into?
> How can be tested the compatibility of different proposals?
>
> Personally I do not look for additional rights,
> as Douglas, I'm interested in some action and ready to help to move the things forward.
> And so, would like to have this possibility.
>
>
> Also Jenkins is dead for some time already.

Exact. I did not noticed.

> What shall we do?
> Wait? Mount temporary service of limited volume -- at least for OpenSC/'staged' and few other branches ?

Martin, what do you plan to do?

Regards,

--
 Dr. Ludovic Rousseau
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC write access to main trunk, discussion

Jean-Michel Pouré - GOOZE
In reply to this post by Viktor Tarasov-3
Dear all,

> As I understand the current policy, the patch acceptance policy is
> resumed in:
> - fixes for crying bugs go to 'master';
> - little fixes, evident limited patch goes to 'staged';
> - more consequent proposals pass to Gerrit and here waits for approval
> to be applied to 'staged'.

This seems relevant and superior to the previous SVN process.

> Current problem is that the process is stagnated on the Gerrit level.
> For some obscure reasons Martin do not participates in Gerrit
> review/acceptance procedures, as well as Ludovic.
> Nobody else have sufficient authority to do it.

From Gerrit webpage: "Gerrit simplifies Git based project maintainership
by permitting any authorized user to submit changes to the master Git
repository, rather than requiring all approved changes to be merged in
by hand by the project maintainer."

YES, this is what is needed.
--
                  Jean-Michel Pouré - Gooze - http://www.gooze.eu

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

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC write access to main trunk, discussion

Peter Stuge-4
In reply to this post by Jean-Michel Pouré - GOOZE
Jean-Michel Pouré - GOOZE wrote:
> 1) The ePass2003 code was reviewed by Viktor and included in his branch.
> You probably did not know, did not compile, did not test and therefore
> Viktor's work is ignored.

This is appropriate in my opinion, because I do not think that the
commits are ready for inclusion in the main OpenSC repository,
regardless of the fact that Viktor has included them in his.


> He needs and deserves write access to OpenSC main GIT to speed up
> development.

I disagree, if he considers the epass2003 commits I looked at to be
of acceptable quality.


> The reasons is that we need more new features, more beta testers.

You disregard the topic of code quality, which I think that is
unacceptable in particular for a security related project.


> 2) Take the example of Alon developments around PKCS#11. A lot of them
> were ignored by OpenSSH. The reason is that when a small number of
> people have a grasp on a project, strange things sometimes happen.

What? The reason is that, as you may know, OpenSSH is developed in
the OpenBSD project, and their plans for PKCS#11 did not align with
Alon's plans for OpenSSH PKCS#11 outside OpenBSD.


> Locking a project to a small number of developers is not good.

There is no locking. Please get that idea out of your mind. Everyone
can create commits. But as I have tried to give several examples of,
obviously not every commit should automatically be included in the
main repository - which is in principle what you advocate.


> IMHO, the way OpenSC used to be organized one year ago was superior,
> because there was a central repository with all new features. More beta
> features, more testers, larger market and superior quality.

More code = more bugs.


> This is no longer the case and each developers works in his corner.

If that is the case, it is so because the active developers do not
communicate with each other. As you've mentioned, communicating is
important. Committing to the main repository is never the start of
communication, it is what concludes communication.


> The only collaborative work is what you call "peer review".

I'm not sure how much review actually happens.


> So my opinion would be to allow each developer to commit changes to the
> main GITHUB staging (developing) branch after discussion. Like it used
> to be the case using SVN.

Replace branch with repository and I see no problem. But sharing a
sandbox is significantly less convenient than each developer having
their own repository/ies, while also exchanging commits with each
other. It is perfectly fine for each developer to have one or even
more repositories. Please understand that this is the nature of git,
and actually the nature of development work. One person has focus on
one thing at a time, in their corner. After they finish, it is of
course important to do show and tell, get review comments, rework the
code, and repeat until consensus.


> And make sure OpenSC is not only owned by one or two people. This
> cannot ever happen, we don't agree with this privatization.

Who are "we" ?  I don't care if OpenSC has just one committer, as
long as code quality is a high, if not the highest, priority.


> The organization should be like:
> * 4/5 committers
> * 10/20 code contributors and developers
> * 100 beta testers

The problem with this organizational diagram is that neither you nor
anyone else can magically generate competent developers with lots of
spare time. People contribute what they can when they can. You can of
course hire developers, but if your recruitment process is strict, so
as to find only really competent developers, you will discover
quickly that they are quite rare.


//Peter

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

attachment0 (197 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC write access to main trunk, discussion

Viktor Tarasov-3
In reply to this post by Peter Stuge-4
Le 17/02/2012 17:52, Peter Stuge a écrit :

> Jean-Michel Pouré - GOOZE wrote:
>> * OpenSC used to have a very flexible approach. OpenSC is NOT
>> kernel.org with thousands of developers and no need for hierarchy.
> OpenSC is smaller, but I do not agree that there is no need for any
> kind of hierarchy. Now, please understand that this is not about
> power hierarchy as in politics, but it is about technical experience
> with the code and with the problem domain.
>
> I am personally familiar with the smart card domain but I haven't
> spent much time with the OpenSC codebase and therefore I absolutely
> do not want some patch I create to be included without being reviewed
> first.
>
> The review is criticial. Especially in a codebase like OpenSC, to
> which I might indeed delegate my legal authority, I want the review
> to be merciless.

Nobody doubts that review in critical.
But what shall we do now, how can we 'move forward',
if the review/acceptance process is stopped at the Gerrit level
and the only person that is capable and has authority to do something is absent for a long time already ?

...

>> * Setting-up a compilation farm is no reason for closing write access
>> to historical developers of OpenSC.
> I agree, but I don't think one has anything to do with the other,
> even if they happened at the same time. I guess that anyone who had
> write access to the repository earlier can get it again if they just
> send a public ssh key and their prefered username.

I agree, compilation farm is extremely useful.
But it has to be adapted/configured in accordance with the available human and other resources.
There has to be no definitive obstacle for 'moving forward', otherwise this 'compilation farm' stuff loose it's sense of being.



>
>> We demand more freedom and transparency or this can only lead to
>> endless flamewars.
> Let's focus on a concrete problem. Have you created a patch which has
> been peer reviewed and is well understood, but has been rejected by
> Martin and Ludovic? If yes, let's try to find a solution. If no, you
> can't really demand more freedom and transparency, because you
> haven't exercised the freedom to create perfect patches yet.
>
> I did review the epass2003 commits when their availability was
> announced, and I've looked at the entersafe github account
> again just now. Here is some feedback:
>
> There are three branches; ePass2003_1, epass2003 and ep2k3. These
> names are non-descript.
>
> Commit 902e637c is quite long with over 2k lines added for the card
> driver. That seems much to me. It's infeasible for me as careful
> programmer but OpenSC internals newbie to review this code. My gut
> feeling is that much of the code could be factored out.
>
> The commits are not very well described in the commit messages.
>
> The commits include unrelated changes.
>
> The commits include whitespace changes mixed with actual code
> changes.
>
> The following commit undoes some of the unrelated changes in the
> previous one.
>
> This is what was immediately obvious to me just by looking at one and
> a half commits in one of the branches. The things I point out above
> are all things which do not belong in a perfect patch, and do not
> beling in the OpenSC codebase that I want to use.
>
> All these things, and probably more!, must be obvious to any other
> programmer who has looked at the commits. I do not believe that I
> have some special vision and only I can see these things.
>
> It seems to me that the commits have been created without
> self-review, which is of course the very first thing to do before
> proposing any change for inclusion.


Probably you have a reason -- 'whitespace', 'commit messages', 'undoes unrelated changes', ...
But from my point of view:
- commit history do not needs to be perfect for the new driver, before it's commited into one of the official branches;
- personally, I'm ready to correct myself the limited number of the coding style ot other issues when merging newbie commits,
but to not make the 'ping-pong' last for ages;
- historically, afais, driver authors where relatively free in coding style, implementation particularities, etc. in the part that concerns it's 'own space' .
(It's the module approach, that Nikos Mavrogiannopoulos talking about in his mail in this thread.)
Certainly, the 'newbies' have to be 'educated' in the 'right' direction, but the process could not be so rigorous
and finally to not block the 'moving forward'.


...

> //Peter

Kind regards,
Viktor.

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC write access to main trunk, discussion

Peter Stuge-4
Viktor Tarasov wrote:
> Nobody doubts that review in critical.
> But what shall we do now, how can we 'move forward',
> if the review/acceptance process is stopped at the Gerrit level
> and the only person that is capable and has authority to do
> something is absent for a long time already ?

I suggest to iterate over proposed patches until they are perfect.

That way, those who can submit commits in Gerrit (this is the Gerrit
term for including a commit into the main repository) will need to
spend close to zero time on doing so. Their job becomes so easy that
it is a no-op. Then it also gets done quickly and frequently. This
must be the goal.


> Probably you have a reason -- 'whitespace', 'commit messages',
> 'undoes unrelated changes', ...
> But from my point of view:
> - commit history do not needs to be perfect for the new driver,
>   before it's commited into one of the official branches;

Work in progress will always exist. Beta testing of work in progress
is good and important, and Git makes this extremely easy. Anyone in
the world can publish their work in progress.

Proposing a commit for inclusion in the main repo is something quite
different. Whenever something is pushed to Gerrit it must indeed be
perfect, or it is just some lazy or sloppy developer wasting the time
of others. I think we are all busy and want to avoid wasted time.


> - personally, I'm ready to correct myself the limited number of the
>   coding style ot other issues when merging newbie commits, but to
>   not make the 'ping-pong' last for ages;

This is a trade-off. It's fine to do this once or twice for a new
developer. It's however quite hopeless when the developer whose work
you review consistently makes the same mistakes that you have
corrected and possibly even pointed out several times before. It is a
waste of time for humans to do such work. Static analysis of commits,
e.g. using checkpatch.pl from Linux possibly with som modifications,
can and must be automated. Gerrit is the perfect place to do it.


> - historically, afais, driver authors where relatively free in
>   coding style, implementation particularities, etc. in the part
>   that concerns it's 'own space' .

I find this problematic since it leads to low reusability. Even just
visual style differences are not really helpful. A uniform codebase
is more coherent and easier to deal with for everyone involved. The
coding style rules do not have to be very many, but having project
wide rules is a good thing.


> Certainly, the 'newbies' have to be 'educated' in the 'right'
> direction, but the process could not be so rigorous and finally to
> not block the 'moving forward'.

Until newbies can demonstrate that they have learned the right things
they are by definition not moving forward.


//Peter
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC write access to main trunk, discussion

Anders Rundgren
IMO the core problem with OpenSC is a that all cards seem to require
a tweak, profile or similar.   For government IDs which are driven
by politics rather than reason there is no problem to solve; the
governments simply have to pay the price for demanding "uniqueness".

For non-government tokens like the excellent Feitian Epass2003
I would consider another approach: Updating the firmware to
emulate PIV so that we can put the middleware aside once and
for all.  That is, HW vendors should qualify their products
against middleware rather than running never-ending projects
that only creates frustration and exuberant costs.

Anders
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC write access to main trunk, discussion

Peter Stuge-4
Anders Rundgren wrote:
> For non-government tokens like the excellent Feitian Epass2003
> I would consider another approach: Updating the firmware to
> emulate PIV so that we can put the middleware aside once and
> for all.

I agree completely that all the legacy involved in tokens and cards
is horrendous waste of engineering resources, time and life.

I'm excited about the gnuk project, it's a nice platform to play with
the PKCS#11 over USB idea, which I refuse to give up on before having
attempted to implement it and failed. :)


//Peter
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC write access to main trunk, discussion

Jean-Michel Pouré - GOOZE
In reply to this post by Peter Stuge-4
> Until newbies can demonstrate that they have learned the right things
> they are by definition not moving forward.

Come-on, we are not in a class-room or in an administration.

We all agree that Gerrit is the solution. So let's make it work and open
accounts for recognized developers to make sure simple patches are
committed.

If this is not done within a reasonable time frame, I will create a
Charity under French law open to everyone and we will have elections.

Kind regards,
--
                  Jean-Michel Pouré - Gooze - http://www.gooze.eu

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

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC write access to main trunk, discussion

Viktor Tarasov-3
In reply to this post by Peter Stuge-4
Le 19/02/2012 11:23, Peter Stuge a écrit :
> Viktor Tarasov wrote:
>> Nobody doubts that review in critical.
>> But what shall we do now, how can we 'move forward',
>> if the review/acceptance process is stopped at the Gerrit level
>> and the only person that is capable and has authority to do
>> something is absent for a long time already ?
> I suggest to iterate over proposed patches until they are perfect.

Iterate with who?  There is nobody on the other side of the wire.
For months the only person that is capable to do/answer something is absent.


> That way, those who can submit commits in Gerrit (this is the Gerrit
> term for including a commit into the main repository) will need to
> spend close to zero time on doing so. Their job becomes so easy that
> it is a no-op. Then it also gets done quickly and frequently. This
> must be the goal.

I'm completely agree with you, and admire the beauty of your abstract considerations,
but what have we do here & now, in our current situation -- Jenkins is dead, Gerrit is in mute coma.


 ...

>> - personally, I'm ready to correct myself the limited number of the
>>   coding style ot other issues when merging newbie commits, but to
>>   not make the 'ping-pong' last for ages;
> This is a trade-off. It's fine to do this once or twice for a new
> developer. It's however quite hopeless when the developer whose work
> you review consistently makes the same mistakes that you have
> corrected and possibly even pointed out several times before. It is a
> waste of time for humans to do such work.

Believe me, I have other interesting things to do.
But for months I'm looking the way to help to 'move OpenSC forward' and but had no answers -- there is no activity on the other side.
Decision to pull the ECDH, the ePass2003 into SM branch is my isolated desperate attempt to 'move forward'.


> Static analysis of commits,
> e.g. using checkpatch.pl from Linux possibly with som modifications,
> can and must be automated. Gerrit is the perfect place to do it.

Please, come back to earth -- Gerrit is not actually functional.



>> - historically, afais, driver authors where relatively free in
>>   coding style, implementation particularities, etc. in the part
>>   that concerns it's 'own space' .
> I find this problematic since it leads to low reusability. Even just
> visual style differences are not really helpful. A uniform codebase
> is more coherent and easier to deal with for everyone involved. The
> coding style rules do not have to be very many, but having project
> wide rules is a good thing.

Completely on you side. But that's the current state of art.
To change something we need more resources.



>> Certainly, the 'newbies' have to be 'educated' in the 'right'
>> direction, but the process could not be so rigorous and finally to
>> not block the 'moving forward'.
> Until newbies can demonstrate that they have learned the right things
> they are by definition not moving forward.

...

> //Peter

Kind regards,
Viktor.

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC write access to main trunk, discussion

Viktor Tarasov-3
In reply to this post by Peter Stuge-4
Le 19/02/2012 10:50, Peter Stuge a écrit :

> Jean-Michel Pouré - GOOZE wrote:
>> 1) The ePass2003 code was reviewed by Viktor and included in his branch.
>> You probably did not know, did not compile, did not test and therefore
>> Viktor's work is ignored.
> This is appropriate in my opinion, because I do not think that the
> commits are ready for inclusion in the main OpenSC repository,
> regardless of the fact that Viktor has included them in his.
>
>> He needs and deserves write access to OpenSC main GIT to speed up
>> development.
> I disagree, if he considers the epass2003 commits I looked at to be
> of acceptable quality.

The ePass2003 commit has been re-factored before creating the SM+ePass2003 branch,
to make it compatible with the general SM framework and to correct some of the coding style issues.
https://github.com/viktorTarasov/OpenSC/commits/include-ePass2003



>> The reasons is that we need more new features, more beta testers.
> You disregard the topic of code quality, which I think that is
> unacceptable in particular for a security related project.


Just to remind,
the overwhelming part of the ePass2003 commit is concentrated in it's own new module (card driver) .



>> Locking a project to a small number of developers is not good.
> There is no locking. Please get that idea out of your mind. Everyone
> can create commits. But as I have tried to give several examples of,
> obviously not every commit should automatically be included in the
> main repository - which is in principle what you advocate.

>> IMHO, the way OpenSC used to be organized one year ago was superior,
>> because there was a central repository with all new features. More beta
>> features, more testers, larger market and superior quality.
> More code = more bugs.
>
>
>> This is no longer the case and each developers works in his corner.
> If that is the case, it is so because the active developers do not
> communicate with each other. As you've mentioned, communicating is
> important. Committing to the main repository is never the start of
> communication, it is what concludes communication.
>
>
>> The only collaborative work is what you call "peer review".
> I'm not sure how much review actually happens.
>
>
>> So my opinion would be to allow each developer to commit changes to the
>> main GITHUB staging (developing) branch after discussion. Like it used
>> to be the case using SVN.
> Replace branch with repository and I see no problem. But sharing a
> sandbox is significantly less convenient than each developer having
> their own repository/ies, while also exchanging commits with each
> other. It is perfectly fine for each developer to have one or even
> more repositories. Please understand that this is the nature of git,
> and actually the nature of development work. One person has focus on
> one thing at a time, in their corner. After they finish, it is of
> course important to do show and tell, get review comments, rework the
> code, and repeat until consensus.
>
>
>> And make sure OpenSC is not only owned by one or two people. This
>> cannot ever happen, we don't agree with this privatization.
> Who are "we" ?  I don't care if OpenSC has just one committer, as
> long as code quality is a high, if not the highest, priority.
>
>
>> The organization should be like:
>> * 4/5 committers
>> * 10/20 code contributors and developers
>> * 100 beta testers
> The problem with this organizational diagram is that neither you nor
> anyone else can magically generate competent developers with lots of
> spare time. People contribute what they can when they can. You can of
> course hire developers, but if your recruitment process is strict, so
> as to find only really competent developers, you will discover
> quickly that they are quite rare.
>
>
> //Peter
>
>
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC write access to main trunk, discussion

Peter Stuge-4
In reply to this post by Jean-Michel Pouré - GOOZE
Jean-Michel Pouré - GOOZE wrote:
> > Until newbies can demonstrate that they have learned the right things
> > they are by definition not moving forward.
>
> Come-on, we are not in a class-room or in an administration.

We are also not in a democracy. We are in a security related open
source project.


> We all agree that Gerrit is the solution. So let's make it work and
> open accounts for recognized developers to make sure simple patches
> are committed.

Everyone can register an account, which then allows to push commits
into Gerrit, and to comment on and perform +1/-1 review of other
commits. An OpenID is neccessary. If someone does not have an OpenID
and would like me to provide one, feel free to send me your prefered
username, md5(yourpassword) and your full name and email address, and
I will create an identity for you on my OpenID provider. You then add
two <meta> tags to any web page that you control, and the URL of that
web page is your OpenID identifier.

Note that many sites such as SourceForge, Google, Yahoo, etc. already
have OpenID providers, so if you have an account there you can look
around to find your OpenID identifier, which you then use to register
with Gerrit.


> If this is not done within a reasonable time frame, I will create a
> Charity under French law open to everyone and we will have elections.

Create as many charities as you like, I don't think it will make any
difference. Working on code is unrelated to holding elections.

I suggest that those who want to contribute to OpenSC start flooding
Gerrit with perfect patches that are so obviously perfect and that
are approved by so many contributors that they require nearly zero
attention from Martin and Ludovic, and thus can be submitted (again,
the Gerrit term for including in the main repo) very quickly.

The only alternative to that is IMO for those who want to do
development with a different goal and/or a different method than
Martin and Ludovic to create a fork. Actually this is already what
happens when using Git. Every repository is already a fork.

Forking isn't neccessarily bad, but keep in mind that you will have
to work very hard to be able to replace the de-facto standard. It
will be significantly easier to focus on working with the existing
project, on the terms of the existing project.

Whenever a fork is created, it is important to decide right at the
start what the purpose will be. If the purpose is to get changes back
into the original codebase then it is obviously critical to follow
the procedures and practises of that codebase, otherwise the effort
will be wasted, since the forked codebase is unmergeable. Maybe
someone wants to spend time fixing it up. This is very painful, and a
complete waste of time. The alternative is to go full steam ahead and
decide to never look back. Only with this attitude does it really
make sense to fork. You already indicated that you don't really want
to fork, so I guess your choice is made.

This is all politics. Let's disregard the politics. That leaves code.


It is impossible to argue against a perfect patch.


//Peter

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

attachment0 (197 bytes) Download Attachment
123