Le 21 février 2012 21:21, Douglas E. Engert a écrit :
> Ludovic,
> change,44 below is Vicktor's, not mine. I should not have said
> "I think I have to rebase the code, and do another pull request?"
>
> I was hopping you would try a +2 on:
> https://www.opensc-project.org/codereview/#change,237
Douglas E. Engert wrote:
> change,44 below is Vicktor's, not mine. I should not have said
> "I think I have to rebase the code, and do another pull request?"
You can also do it!
//Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-projec
Ludovic,
change,44 below is Vicktor's, not mine. I should not have said
"I think I have to rebase the code, and do another pull request?"
I was hopping you would try a +2 on:
https://www.opensc-project.org/codereview/#change,237
Its parent is:
6f8dcc9172277799011d88fdbe2fabfcf3a897
On 2/21/2012 2:34 AM, Ludovic Rousseau wrote:
> Le 20 février 2012 22:31, Peter Stuge a écrit :
>> Douglas E. Engert wrote:
>>> I am new to Gerrit too,
>>
>> All right! I'm by no means an expert, but I have been using it in
>> several projects for a while, where I also helped with issues during
Le 20 février 2012 22:31, Peter Stuge a écrit :
> Douglas E. Engert wrote:
>> I am new to Gerrit too,
>
> All right! I'm by no means an expert, but I have been using it in
> several projects for a while, where I also helped with issues during
> the migration, so please feel free to ask any questio
Le 20 février 2012 22:08, Douglas E. Engert a écrit :
> Ludovic,
> Can you verify if you are in the Gerrit Administrator's group?
> and are any of the other people listed on the "GetInvolved" page
> listed as integrators, or admins?
I only see 2 groups in the admin section:
- Integrators: Martin
Le lundi 20 février 2012 à 22:31 +0100, Peter Stuge a écrit :
> Integrators is only Martin and Ludovic, hence those are the ones who
> can currently include Gerrit changes into OpenSC on GitHub.
>
> Now for the third time, I'm sure that everyone who used to have
> repository write access will also
Douglas E. Engert wrote:
> I am new to Gerrit too,
All right! I'm by no means an expert, but I have been using it in
several projects for a while, where I also helped with issues during
the migration, so please feel free to ask any questions.
> but it looks like if 2 code reviews give a +1, the
[Ludovic, Please see below.]
On 2/19/2012 7:30 AM, Peter Stuge wrote:
> Peter Stuge wrote:
>>> Please advise:
>>> 1) How to push a patch from GITHUB to OpenSC staging directory.
>>> In two or three sentences.
>>
>> I would do:
>>
>> One-time setup:
>> a. Create Gerrit account and add username and
Peter Stuge wrote:
> > Please advise:
> > 1) How to push a patch from GITHUB to OpenSC staging directory.
> > In two or three sentences.
>
> I would do:
>
> One-time setup:
> a. Create Gerrit account and add username and public SSH key
> b. git clone from github which has the patch
> c. cd into c
Jean-Michel Pouré - GOOZE wrote:
> I created an account on Gerrit and looked at this URL:
> https://www.opensc-project.org/codereview/#q,status:open,n,z
>
> Some issues are marked 18 February 2012 with "Jenkins" user.
> So it seems we have GITHUB, Jenkins and Gerrit ...
>
> All this seems complic
Jean-Michel Pouré - GOOZE wrote:
> > We are also not in a democracy. We are in a security related open
> > source project.
>
> Don't get me wrong. This is an organization issue. I am not talking
> about forking OpenSC, this would be stupid.
Not neccessarily - if there is critical mass I think it
Le dimanche 19 février 2012 à 13:06 +0100, Peter Stuge a écrit :
> Jenkins may have a problem, but Gerrit looks like it is functioning
> fine, at least now. It is trying to merge commits which have been
> pushed, reviewed and submitted for merge, but where the commits have
> been pushed with depend
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
> We are also not in a democracy. We are in a security related open
> source project.
Don't get me wrong. This is an organization issue. I am not talking
about forking OpenSC, this would be stupid. The website, teams and tools
should remain. But we need a simplier and more effective approach.
Re
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 proj
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, becau
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
>> s
> 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 su
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 hor
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 li
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 su
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 hierar
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
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'.
Th
Le 18 février 2012 04:59, Viktor Tarasov 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.
>>>
>>>
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 modu
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
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, d
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 flexibilit
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
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
Hello,
On Thu, Feb 16, 2012 at 11:53 PM, Douglas E. Engert 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 imple
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.opens
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
35 matches
Mail list logo
