Re: [opensc-devel] gerrit and "Project policy requires all submissions to be a fast-forward."

2012-03-14 Thread Ludovic Rousseau 
Le 14 mars 2012 18:56, Peter Stuge  a écrit :
> Ludovic Rousseau wrote:
>> So I used the OpenSC documentation at [2] and rebased my staging
>> branch (from [3]) onto gerrit/staging.
>
> Note that gerrit/staging is a so-called remote tracking branch, and
> it's best not to commit to those to avoid conflicts if other changes
> arrive from the remote than those you have made.
>
> It's best to do something like this before committing:
>
> git checkout -b staging gerrit/staging
>
> This creates a branch in the local repo called "staging" (the -b arg.)
> and then make new commits on that branch (or another, it's easy to
> make many of them). These branches are never touched by git unless
> of course it is specifically told to, but the remote tracking
> branches are used by git to synchronize with the remote, so it's
> better to not manually add commits to them.
>
>
>> The commit "pkcs15-profile.xml: remove empty SYNOPSIS section" is now
>> the first one on gerrit/staging.
>
> Ok, and git status says that you are 1 ahead?

No. Because I also have all the other patches from Opensc/staging that
need to be rebased.

$ git log --pretty=oneline --abbrev-commit  --graph --decorate
* 3196f95 (HEAD, staging) Display the flags argument of C_Initialize()
* 085e83c Fix extra spaces and tabs issues
* 5960efb pkcs15-init tool: fix for pin auth_type comparison
* 491ba2c Use the short form sc_log() instead of sc_debug()
* 285ca8e Remove extra spaces and tabs at end of lines
* b8de8f0 Fix compilation error on Windows
* c2003cf Add support for PACE-enabled readers
* 1b5fe75 Fix lookup_enum_spec() prototype
* 36f6733 pkcs11: coding style
* c1369d2 pkcs11: win32 compilation error
* 56cc676 Reformat: remove extra spaces and tabs
* e4a60ea libopensc: Add 'paranoid-memory' setting for behavior when
mlock() fails
* f938be6 libopensc: Don't fail to allocate memory when mlock fails
* 6e0f46b Adding default accessflags to the do_store_private_key
function in the same way do_generate_key has those accessflags This
seems the right thing to do, when you look at the initial commit which
added the flags in do_generate_key and the ticket
http://www.opensc-project.org/opensc/ticket/198
* 31e4ee2 Display the ASCII equivalent of a hex dump
* 26943ed Fix compiler warning and real problem
* c7d5436 Changing default usage from sign to verify, because verify
is the public key opposite of sign for the private key
* 5add841 Setting usage flags for the public key when storing a private key
* f25ca60 iso7816.c: clean up iso7816_restore_security_env()
* ae800db iso7816.c: slightly clean up iso7816_delete_file()
* 1296f86 westcos-tool.1.xml: sort options alphabetically
* 7ecc7a7 pkcs15-tool.1.xml: sort options alphabetically
* 7244bb4 pkcs15-init.1.xml: sort options alphabetically, slight rewording
* 833e389 pkcs11-tool.1.xml: sort options alphabetically
* 96832df opensc-tool.1.xml: sort options alphabetically
* a607e3b netkey-tool.1.xml: sort options & commands alphabetically
* b745fc4 eidenv.1.xml: sort options alphabetically
* f311d70 cryptoflex-tool.1.xml: sort options alphabetically
* c1ebdf7 cardos-tool.1.xml: sort options alphabetically
* 7cf22c4 westcos-tool.1.xml: slight rewording
* 5186e95 opensc-explorer.1.xml: sort options & commands alphabetically
* 0b7e75a pkcs15-crypt.1.xml: sort options alphabetically
* 34e050c piv-tool.1.xml: more harmonization, slight re-wording
* 0de1be6 opensc-explorer.1.xml: fix typos, more harmonization
* f2f37bb tools.xml: use 2 reference sections: tools & file formats
* 0ae8b37 doc/tools/*.xml: more consistent formatting
* 0717dac doc/tools/Makefile.am: substitute @pkgdatadir@
* d4fd70b doc/tools/Makefile.am: new Makefile template for autotools
* fe3dce9 doc/tools/*.xml: include manpage sections in file names
* fe48e96 doc/Makefile.am: get rid of "api.work" kludge
* 19e2c34 doc/tools/*.xml: add  class attributes
* e1356f1 doc/tools/*.xml: use  in "See also" sections
* 3cee29f doc/tools/*.xml: harmonize & complete  sections
* 796e604 doc/tools/*.xml: use  sections
* edabae1 piv-tool.xml: fix typo
* 9c1285f pkcs15-profile.xml: remove empty SYNOPSIS section
 <-- the patch I would like to push
* a2624e5 (gerrit/staging) Remove svnignore file which is not needed
with Git<-- gerrit is here

>> I edited the commit message to add a line:
>> Change-Id: Id824eb62bc41f8f714bd6d67b6333ea07a527d70
>> to tell gerrit it is the same patch.
>
> Sounds good.
>
>
>> Now I want to push this commit to gerrit. How do I do that?
>
> You can push the currently checked-out HEAD using:
>
> git push gerrit HEAD:refs/for/staging
>
> HEAD:refs/for/staging has local:remote format, so what is HEAD
> locally will be pushed into refs/for/staging remotely. HEAD locally
> always means "what is currently checked out" and refs/for/staging is
> gerrit magic that means proposed commit for the staging branch.
>
>
>> [2] only says:
>> "Push your changes to be included in the "staging" branch
>>
>>     git push  gerrit:refs/for/staging
>>     git push so

Re: [opensc-devel] gerrit and merge process: "Submitted, Merge Pending" state

2012-03-14 Thread Peter Stuge 
Ludovic Rousseau wrote:
> Change 2 now merged.

Ok!


> I also tried with change 3
> https://www.opensc-project.org/codereview/#change,3 but I get the
> error:
> "Gerrit Code Review   8:45 PM
> 
> Change cannot be merged due to unsatisfiable dependencies.
> 
> The following dependency errors were found:
> 
> Depends on patch set 1 of I8b483369, however the current patch set is 2.
> Depends on commit 3a8519eda2704eceb2d27bfbeaca44c6da7d51b2 which
> has no change associated with it.
> 
> Please rebase the change and upload a replacement commit."
> 
> Do we now have to rebase all the patches?

With the current gerrit configuration yes, unfortunately this is the
case. Gerrit can also be configured differently, but I'm not sure if
we want to.. In other projects where I use gerrit we do not have this
rather strict policy, but it does also force contributors to pay
attention to what they are doing, and if they rebase they should also
look at the result of that, before pushing to gerrit again.

In practise I don't know if it works; I didn't review the rebase of
change 2, only the one for change 1. And while rebasing is easy in
git I think it's bad that contributors are forced by gerrit to do it
so much.

On the other hand, changing gerrit to use submittype cherry-pick
makes all dependencies merely advisory, ie. humans using gerrit must
pay close attention so that nothing gets submitted out of order, or
changes will have to be rebased anyway.

What to choose depends on how the project will work with commits..

If we will generally have only very few very recent changes in gerrit
then the current configuration can work pretty well, except that it
must be clear already before pushing which commits will be submitted
in gerrit before the one(s) being pushed.

If we suspect that we will have some changes in gerrit which lay
around for a long time without getting attention from either
reviewers or contributors, and it was assumed by someone that those
commits would be submitted first, then the someone will have to
rebase, and everyone assuming that someone's change would go in will
have to rebase in turn, and so on.. Not so nice.


//Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] gerrit and "Project policy requires all submissions to be a fast-forward."

2012-03-14 Thread Peter Stuge 
Ludovic Rousseau wrote:
> So I used the OpenSC documentation at [2] and rebased my staging
> branch (from [3]) onto gerrit/staging.

Note that gerrit/staging is a so-called remote tracking branch, and
it's best not to commit to those to avoid conflicts if other changes
arrive from the remote than those you have made.

It's best to do something like this before committing:

git checkout -b staging gerrit/staging

This creates a branch in the local repo called "staging" (the -b arg.)
and then make new commits on that branch (or another, it's easy to
make many of them). These branches are never touched by git unless
of course it is specifically told to, but the remote tracking
branches are used by git to synchronize with the remote, so it's
better to not manually add commits to them.


> The commit "pkcs15-profile.xml: remove empty SYNOPSIS section" is now
> the first one on gerrit/staging.

Ok, and git status says that you are 1 ahead?


> I edited the commit message to add a line:
> Change-Id: Id824eb62bc41f8f714bd6d67b6333ea07a527d70
> to tell gerrit it is the same patch.

Sounds good.


> Now I want to push this commit to gerrit. How do I do that?

You can push the currently checked-out HEAD using:

git push gerrit HEAD:refs/for/staging

HEAD:refs/for/staging has local:remote format, so what is HEAD
locally will be pushed into refs/for/staging remotely. HEAD locally
always means "what is currently checked out" and refs/for/staging is
gerrit magic that means proposed commit for the staging branch.


> [2] only says:
> "Push your changes to be included in the "staging" branch
> 
> git push  gerrit:refs/for/staging
> git push some/branch gerrit:refs/for/staging
> git push  gerrit:refs/for/staging "

This is backwards. gerrit is the remote and comes after push. Then
there's the local:remote specifier where local can be a branch or a
commit or HEAD, and remote should always be refs/for/staging.


> What is the correct command to push only one patch?

I hope the above answers about the command, but this brings me to an
important point:

git push (and git in general) almost never operates on individual
commits, but always on the commit including all of it's history.

In practise this means that when you git push something you will not
push only the commit you identify (using HEAD, commit hash or branch
name) but in fact you will push also all ancestor commits which the
remote repository (gerrit) does not already have.

When pushing multiple commits at once gerrit records a dependency
between the commits, which (with the current gerrit config on
opensc-project.org) means that these commits must be submitted in
gerrit in the exact order and in the exact version that they were
orignally pushed to gerrit.

Keep this in mind, and create separate branches locally for making
changes which are unrelated.

The way gerrit is currently configured it is however neccessary to
serialize locally before pushing; before an unrelated change can be
submitted in gerrit it must be rebased onto the current latest state
of the gerrit repository. This is the awkward part I refered to
yesterday.


//Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] gerrit and "Project policy requires all submissions to be a fast-forward."

2012-03-14 Thread Ludovic Rousseau 
Hello git experts :-)

I try to update change 6 [1] so that gerrit is happy.

For now the error is:
"Gerrit Code Review 4:21 PM

Project policy requires all submissions to be a fast-forward.

Please rebase the change locally and upload again for review."

So I used the OpenSC documentation at [2] and rebased my staging
branch (from [3]) onto gerrit/staging.
The commit "pkcs15-profile.xml: remove empty SYNOPSIS section" is now
the first one on gerrit/staging.

I edited the commit message to add a line:
Change-Id: Id824eb62bc41f8f714bd6d67b6333ea07a527d70
to tell gerrit it is the same patch.

Now I want to push this commit to gerrit. How do I do that?

[2] only says:
"Push your changes to be included in the "staging" branch

git push  gerrit:refs/for/staging
git push some/branch gerrit:refs/for/staging
git push  gerrit:refs/for/staging "

So I tried:
$ git push 70852d9733e045df2dce4a85f3e50e66aa2195bc gerrit:refs/for/staging
fatal: '70852d9733e045df2dce4a85f3e50e66aa2195bc' does not appear to
be a git repository
fatal: The remote end hung up unexpectedly

What is the correct command to push only one patch?

I found "git - pushing specific commit" [4] but it looks a bit
overkill for now. Maybe something simpler is possible.

Thanks

[1] https://www.opensc-project.org/codereview/#change,6
[2] https://www.opensc-project.org/opensc/wiki/SourceCode
[3] git://github.com/LudovicRousseau/OpenSC.git
[4] http://stackoverflow.com/questions/3230074/git-pushing-specific-commit

-- 
 Dr. Ludovic Rousseau
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] gerrit and merge process: "Submitted, Merge Pending" state

2012-03-14 Thread Ludovic Rousseau 
Le 14 mars 2012 09:59, Viktor Tarasov  a écrit :
> Commit 51630a844e8e95e7108cb1966c5f3e21b93a463b is the last common commit
> for OpenSC/OpenSC.git(staging) and gerrit's repo.
> (By the way, this commit where not submitted to OpenSC.git by gerrit --
> there is no Change-Id in comments)
>
> Two last commits merged into the gerrit's repo are not replicated into
> OpenSC/OpenSC.git.
> Something wrong with replication configuration?
> GitHub refuses not ff merges?
> Have you an access to the gerrit's logs?

No, I do not have access to the gerrit's logs.

I also think something is broken.
Martin, can you have a look when you have some free time?

Thanks

-- 
 Dr. Ludovic Rousseau
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] gerrit and merge process: "Submitted, Merge Pending" state

2012-03-14 Thread Jean-Michel Pouré - GOOZE 
Le mercredi 14 mars 2012 à 10:36 -0500, Douglas E. Engert a écrit :
> Rather the stating from zero, or taking a very large branch with many
> little patches,
> would it be better to have the authors of these patches combine them
> into one or
> a hand full  of larger patches? For example my ECDH was 4 separate
> patches, but I have
> combined it ito one patch.  (But the ECDH is also in the SM branch so
> if it get in either
> way that is OK too.) 

Thank you all for your work.

Viktor explained that OpenSC-staging was merged into OpenSC-SM.
Switching to OpenSC-SM as the lead branch would fix all issues. 

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


smime.p7s
Description: S/MIME cryptographic signature
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] gerrit and merge process: "Submitted, Merge Pending" state

2012-03-14 Thread Douglas E. Engert 
Good to see Ludovic and Peter making progress, Thanks!"

Rather the stating from zero, or taking a very large branch with many little 
patches,
would it be better to have the authors of these patches combine them into one or
a hand full  of larger patches? For example my ECDH was 4 separate patches, but 
I have
combined it ito one patch.  (But the ECDH is also in the SM branch so if it get 
in either
way that is OK too.)

On 3/14/2012 3:59 AM, Viktor Tarasov wrote:
>
>
> On Tue, Mar 13, 2012 at 6:59 PM, Peter Stuge  > wrote:
>
> Peter Stuge wrote:
>  > I made an attempt to kick change 1 loose.
>
> Ok, so that worked. It would work fine to repeat this for each
> change, even if it is a bit labour intensive at least now, to clear
> the backlog. I've done it also for change 2 now.
>
> As you may recall, approving and submitting the change can be done
> also via ssh:
>
> ssh -P 8882 www.opensc-project.org  gerrit 
> review $commithash \
>   --code-review +2 -s
>
> I really like this interface to gerrit when patches need no comment
> but are good to go as-is.
>
> The way our Gerrit has been configured it enforces linear submission
> of commits to the repository, ie. everything must be submitted to the
> git repo in the same order changes were pushed to gerrit by
> contributors.
>
> This is in itself not a bad thing since it forces contributors to pay
> attention to changes in the codebase and what commits goes into the
> repository, but it does slightly raise the bar for less experienced
> git users. It's not really difficult, but it's one more thing to keep
> track of; make sure that your commit has the correct parent before
> you push.
>
>  >From practical experience with gerrit in several projects I tend to
> prefer the cherry-pick strategy when submitting changes. This means
> that stuff can be included into the git repository in a different
> order than was pushed to gerrit. It also means that humans need to
> pay more attention to not submitting changes in the wrong order when
> they are interdependent.
>
> The current config makes it impossible to do something wrong, but can
> in some cases create extra work for rebase and review. The
> cherry-pick merge strategy makes it very easy to do something wrong,
> but can save extra work with rebasing and reviewing+submitting of
> updated patch sets.
>
> The current config has strong arguments, even if it brings slightly
> more inconvenience. I actually favor not changing the config, even if
> we will have to rebase each and every change.
>
>
>
> Commit 51630a844e8e95e7108cb1966c5f3e21b93a463b is the last common commit for 
> OpenSC/OpenSC.git(staging) and gerrit's repo.
> (By the way, this commit where not submitted to OpenSC.git by gerrit -- there 
> is no Change-Id in comments)
>
> Two last commits merged into the gerrit's repo are not replicated into 
> OpenSC/OpenSC.git.
> Something wrong with replication configuration?
> GitHub refuses not ff merges?
> Have you an access to the gerrit's logs?
>
> I would propose to start from zero:
> - merge the OpenSC-SM branch into OpenSC-staging (or simply switch to -- 
> recently the OpenSC-staging was merged into OpenSC-SM).
> - pick from the current gerrit's changesets the useful proposals and apply 
> them to this branch.
> - re-install the Gerit's OpenSC project with the updated github repository.
> - limit direct commits to github's OpenSC-staging (or replicate these changes 
> to the gerrit's repo on the regular base)
> - update the list of the Jenkins admins, or install an alternative Jenkins 
> (like this one https://opensc.fr/jenkins/, https://opensc.fr/gerrit/ 
>  -- still under
> construction),  dedicated to the OpenSC-staging and OpenSC-master. It's 
> needed to implement the glaring lack of an actual jenkins -- the build of 
> OpenSC linux packages.
>
>
> //Peter
>
>
> Kind wishes,
> Viktor.
>
> ___
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org 
> 
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
>
>
>
> ___
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel

-- 

  Douglas E. Engert  
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] gerrit and merge process: "Submitted, Merge Pending" state

2012-03-14 Thread Viktor Tarasov 
On Tue, Mar 13, 2012 at 6:59 PM, Peter Stuge  wrote:

> Peter Stuge wrote:
> > I made an attempt to kick change 1 loose.
>
> Ok, so that worked. It would work fine to repeat this for each
> change, even if it is a bit labour intensive at least now, to clear
> the backlog. I've done it also for change 2 now.
>
> As you may recall, approving and submitting the change can be done
> also via ssh:
>
> ssh -P 8882 www.opensc-project.org gerrit review $commithash \
>  --code-review +2 -s
>
> I really like this interface to gerrit when patches need no comment
> but are good to go as-is.
>
> The way our Gerrit has been configured it enforces linear submission
> of commits to the repository, ie. everything must be submitted to the
> git repo in the same order changes were pushed to gerrit by
> contributors.
>
> This is in itself not a bad thing since it forces contributors to pay
> attention to changes in the codebase and what commits goes into the
> repository, but it does slightly raise the bar for less experienced
> git users. It's not really difficult, but it's one more thing to keep
> track of; make sure that your commit has the correct parent before
> you push.
>
> From practical experience with gerrit in several projects I tend to
> prefer the cherry-pick strategy when submitting changes. This means
> that stuff can be included into the git repository in a different
> order than was pushed to gerrit. It also means that humans need to
> pay more attention to not submitting changes in the wrong order when
> they are interdependent.
>
> The current config makes it impossible to do something wrong, but can
> in some cases create extra work for rebase and review. The
> cherry-pick merge strategy makes it very easy to do something wrong,
> but can save extra work with rebasing and reviewing+submitting of
> updated patch sets.
>
> The current config has strong arguments, even if it brings slightly
> more inconvenience. I actually favor not changing the config, even if
> we will have to rebase each and every change.
>


Commit 51630a844e8e95e7108cb1966c5f3e21b93a463b is the last common commit
for OpenSC/OpenSC.git(staging) and gerrit's repo.
(By the way, this commit where not submitted to OpenSC.git by gerrit --
there is no Change-Id in comments)

Two last commits merged into the gerrit's repo are not replicated into
OpenSC/OpenSC.git.
Something wrong with replication configuration?
GitHub refuses not ff merges?
Have you an access to the gerrit's logs?

I would propose to start from zero:
- merge the OpenSC-SM branch into OpenSC-staging (or simply switch to --
recently the OpenSC-staging was merged into OpenSC-SM).
- pick from the current gerrit's changesets the useful proposals and apply
them to this branch.
- re-install the Gerit's OpenSC project with the updated github repository.
- limit direct commits to github's OpenSC-staging (or replicate these
changes to the gerrit's repo on the regular base)
- update the list of the Jenkins admins, or install an alternative Jenkins
(like this one https://opensc.fr/jenkins/,
https://opensc.fr/gerrit/-- still under
construction),  dedicated to the OpenSC-staging and
OpenSC-master. It's needed to implement the glaring lack of an actual
jenkins -- the build of OpenSC linux packages.


>
> //Peter
>

Kind wishes,
Viktor.


> ___
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel