Re: [opensc-devel] How to deal with the gerrit backlog in an effective way?
Le dimanche 01 avril 2012 à 23:21 +0200, Ludovic Rousseau a écrit : No one volunteered to help. As I wrote in my initial email, I now do plan for option 3. Ludovic, please listen to us. There is also the option 4, proposed by Viktor: Anyway, now that you plan to reject ALL patches from Jerrit, nothing should stop you from moving SM branch to Gerrit. No? 4. Big part of the patches in backlog comes from SM branch. This branch was recently merged with the public 'staging'. So, my proposition is to: 4a. cherry-pick proposals from 'your staging' that are not related to SM and not yet present in 'public staging' ; 4b. switch the 'public staging' to 'SM' and use it as a principal development base and base for releases; 4c. reset official gerrit to the 'staging' at this moment; 4d. re-submit previously cherry-picked proposals. Viktor, your proposal is work to do for someone. I do not volunteer. Ludovic, then leave the community more freedom to organize. We are not asking you to volunteer and do not want to rely on your work to go forward. OpenSC should be organized on the same vein as tokend or libccid. Viktor and community, is there a way to agree to switch the 'public staging' to 'SM' and use it as a principal base for releases? 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] How to deal with the gerrit backlog in an effective way?
Jean-Michel Pouré - GOOZE wrote: community, is there a way to agree to switch the 'public staging' to 'SM' and use it as a principal base for releases? I don't think there is. //Peter pgpmvOdeyPmxt.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] How to deal with the gerrit backlog in an effective way?
I don't think there is. Here is the address of the secure messaging branch: https://github.com/viktorTarasov/OpenSC-SM/tree/secure-messaging We are using it, as it includes most fixes. Binaries are published in: http://www.opensc-project.org/downloads/nightly/sm/ Why not use Opensc-SM for OpenSC developing branch? 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] How to deal with the gerrit backlog in an effective way?
Le 2 avril 2012 10:34, Jean-Michel Pouré - GOOZE jmpo...@gooze.eu a écrit : Dear all, 1. rebase the SM branch over the OpenSC version in gerrit/staging You do not need extra power for that. It is just normal developer work. Okay. So all we need is a diff between SM and staging? No. What you need is to extract all the SM patches and apply them on the gerrit/staging branch. Of course some conflicts are expected and need to be fixed. What I would do (but I am not a git expert) on the SM branch use: git format-patch origin to get the changes in individual patch files. on the gerrit/staging use: git am my_patch for all the previously generated patches. Do not apply all the patches at once but one after the other (in the correct order) and rebuild after each patch. The source code shall compile after each change or gerrit will reject it. I had the problem yesterday: a compilation bug that was fixed by another patch. I had to merge the two patches. Bye, -- 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] How to deal with the gerrit backlog in an effective way?
Le lundi 02 avril 2012 à 10:46 +0200, Ludovic Rousseau a écrit : No. What you need is to extract all the SM patches and apply them on the gerrit/staging branch. Of course some conflicts are expected and need to be fixed. What I would do (but I am not a git expert) on the SM branch use: git format-patch origin to get the changes in individual patch files. on the gerrit/staging use: git am my_patch for all the previously generated patches. OK. I am getting in contact with Viktor. -- 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] How to deal with the gerrit backlog in an effective way?
Ludovic Rousseau wrote: 1. rebase the SM branch over the OpenSC version in gerrit/staging Okay. So all we need is a diff between SM and staging? No. What you need is to extract all the SM patches and apply them on the gerrit/staging branch. Of course some conflicts are expected and need to be fixed. What I would do (but I am not a git expert) You got it exactly right the first time. git rebase does exactly this. For this work it might make sense to do interactive rebase in order to avoid duplicate work, but in any case rebase is the right tool. on the SM branch use: git format-patch origin to get the changes in individual patch files. on the gerrit/staging use: git am my_patch for all the previously generated patches. I would avoid doing this manually. git rebase really is the way to go. Do not apply all the patches at once but one after the other (in the correct order) and rebuild after each patch. The source code shall compile after each change or gerrit will reject it. This can actually be automated pretty easily after the fact. I would first do the complete rebase and only after test each commit on the branch. I had the problem yesterday: a compilation bug that was fixed by another patch. I had to merge the two patches. Another solution may be to reorder the commits. Interactive rebase makes this very easy once the commits have been found. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] How to deal with the gerrit backlog in an effective way?
Le 2 avril 2012 12:12, Peter Stuge pe...@stuge.se a écrit : Ludovic Rousseau wrote: 1. rebase the SM branch over the OpenSC version in gerrit/staging Okay. So all we need is a diff between SM and staging? No. What you need is to extract all the SM patches and apply them on the gerrit/staging branch. Of course some conflicts are expected and need to be fixed. What I would do (but I am not a git expert) You got it exactly right the first time. git rebase does exactly this. For this work it might make sense to do interactive rebase in order to avoid duplicate work, but in any case rebase is the right tool. on the SM branch use: git format-patch origin to get the changes in individual patch files. on the gerrit/staging use: git am my_patch for all the previously generated patches. I would avoid doing this manually. git rebase really is the way to go. I am still lost when git rebase fails. I need to improve my git skills. Do not apply all the patches at once but one after the other (in the correct order) and rebuild after each patch. The source code shall compile after each change or gerrit will reject it. This can actually be automated pretty easily after the fact. I would first do the complete rebase and only after test each commit on the branch. How do you do that? I had the problem yesterday: a compilation bug that was fixed by another patch. I had to merge the two patches. Another solution may be to reorder the commits. Interactive rebase makes this very easy once the commits have been found. Reorder and merge the problematic change with the fix. I know who to do that :-) Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] OpenSC page down...
INPUT:
http://www.opensc-project.org/opensc/wiki/UsingOpensc
OUTPUT:
Traceback (most recent call last):
File build/bdist.linux-x86_64/egg/trac/web/api.py, line 440, in send_error
data, 'text/html')
File build/bdist.linux-x86_64/egg/trac/web/chrome.py, line 827, in
render_template
message = req.session.pop('chrome.%s.%d' % (type_, i))
File build/bdist.linux-x86_64/egg/trac/web/api.py, line 216, in __getattr__
value = self.callbacks[name](self)
File build/bdist.linux-x86_64/egg/trac/web/main.py, line 300, in
_get_session
return Session(self.env, req)
File build/bdist.linux-x86_64/egg/trac/web/session.py, line 198, in __init__
self.get_session(sid)
File build/bdist.linux-x86_64/egg/trac/web/session.py, line 219,
in get_session
super(Session, self).get_session(sid, authenticated)
File build/bdist.linux-x86_64/egg/trac/web/session.py, line 61, in
get_session
db = self.env.get_db_cnx()
File build/bdist.linux-x86_64/egg/trac/env.py, line 328, in get_db_cnx
return get_read_db(self)
File build/bdist.linux-x86_64/egg/trac/db/api.py, line 90, in get_read_db
return _transaction_local.db or DatabaseManager(env).get_connection()
File build/bdist.linux-x86_64/egg/trac/db/api.py, line 152, in
get_connection
return self._cnx_pool.get_cnx(self.timeout or None)
File build/bdist.linux-x86_64/egg/trac/db/pool.py, line 226, in get_cnx
return _backend.get_cnx(self._connector, self._kwargs, timeout)
File build/bdist.linux-x86_64/egg/trac/db/pool.py, line 146, in get_cnx
raise TimeoutError(errmsg)
TimeoutError: Unable to get database connection within 0 seconds.
(OperationalError('could not connect to server: No such file or
directory\n\tIs the server running locally and
accepting\n\tconnections on Unix domain socket
/var/run/postgresql/.s.PGSQL.5432?\n',))
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC page down...
Le 2 avril 2012 13:30, helpcrypto helpcrypto helpcry...@gmail.com a écrit : INPUT: http://www.opensc-project.org/opensc/wiki/UsingOpensc Now fixed. 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] How to deal with the gerrit backlog in an effective way?
Le 02/04/2012 10:01, Ludovic Rousseau a écrit : Le 2 avril 2012 09:56, Jean-Michel Pouré - GOOZE jmpo...@gooze.eu a écrit : I don't think there is. Here is the address of the secure messaging branch: https://github.com/viktorTarasov/OpenSC-SM/tree/secure-messaging We are using it, as it includes most fixes. Binaries are published in: http://www.opensc-project.org/downloads/nightly/sm/ Why not use Opensc-SM for OpenSC developing branch? The solution is very simple. 1. rebase the SM branch over the OpenSC version in gerrit/staging 2. submit the changes to gerrit 3. review the changes on gerrit (they should be OK) 4. someone (Martin/Viktor/me) will accept the changes in gerrit and they will be merged You do not need extra power for that. It is just normal developer work. How the 'staging', that you are working on, is related to the 'staging' branch of the OpenSC.git from github ? Looking onto the git workflow (https://www.opensc-project.org/opensc/wiki/DevelopmentPolicy) I do not quite understand the place of 'staging' on the opensc-project.org . Bye Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] How to deal with the gerrit backlog in an effective way?
Viktor Tarasov wrote: How the 'staging', that you are working on, is related to the 'staging' branch of the OpenSC.git from github ? Looking onto the git workflow (https://www.opensc-project.org/opensc/wiki/DevelopmentPolicy) I do not quite understand the place of 'staging' on the opensc-project.org . Output from gerrit must go into a local repository. This is the one on opensc-project.org. That repository is then pushed to GitHub every now and then. The GitHub repository should not introduce changes, but pull requests are fine, and will result in the commits in question being added into gerrit. Those commits will pass through gerrit and then be pushed over to GitHub. It's clearly possible to short-circuit gerrit and accept pull requests into the GitHub repository directly, but this should be avoided since it will cause unneccessary extra work, and because it means gerrit would not be used. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] How to deal with the gerrit backlog in an effective way?
Ludovic Rousseau wrote:
on the SM branch use: git format-patch origin to get the changes
in individual patch files.
on the gerrit/staging use: git am my_patch for all the previously
generated patches.
I would avoid doing this manually. git rebase really is the way to go.
I am still lost when git rebase fails. I need to improve my git skills.
You mean if there is a conflict somewhere along the way? Then the
rebase only pauses, and expects the conflict to be fixed manually,
then:
git add fixed files git rebase --continue
..which will continue with the following commits or instructions from
the interactive rebase script.
Do not apply all the patches at once but one after the other (in
the correct order) and rebuild after each patch. The source code
shall compile after each change or gerrit will reject it.
This can actually be automated pretty easily after the fact. I would
first do the complete rebase and only after test each commit on the
branch.
How do you do that?
for c in $(git rev-list gerrit/staging..HEAD); do
git checkout master
git branch -D test_$c
git checkout -b test_$c $c
# run test here
test $? -eq 0 {
git branch -D test_$c
continue
}
# tests failed
echo TEST FAILED
git log -1 | cat
done
I had the problem yesterday: a compilation bug that was fixed by
another patch. I had to merge the two patches.
Another solution may be to reorder the commits. Interactive rebase
makes this very easy once the commits have been found.
Reorder and merge the problematic change with the fix. I know who to
do that :-)
I meant that the changes can also be reordered without needing to
merge them. Sometimes that's preferable.
//Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
