[opensc-devel] How to deal with the gerrit backlog in an effective way?
On Tue, Apr 3, 2012 at 8:36 AM, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: Le 3 avril 2012 00:30, Viktor Tarasov viktor.tara...@gmail.com a écrit : 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 . The official repository should be on opensc-project.org. github should be a mirror. So, the presented schema of the git workflow is invalid, and you are going to redesign it, isn't it? But gerrit was not working (or I did not know how to use it) so I merged pull request on github, that was a mistake. Then the two repositories diverged in incompatible ways. Maybe OpenSC on github should be deleted and recreated as a copy of opensc-project.org repository. Why to not do the same with the opensc-project.org repository and to recreate it as a copy of github ? This way looks more respective to the number of people who have forked the github OpenSC.git project. It's the opensc-project.org repository could be the mirror of the github's one -- the main development base. Or maybe we can achieve the same result in a soft way and make the 2 repos to converge again. Maybe. If someone will have the time and motivation. Bye Kind regards, Viktor. -- Dr. Ludovic Rousseau ___ 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
Re: [opensc-devel] How to deal with the gerrit backlog in an effective way?
Le 4 avril 2012 09:49, Viktor Tarasov viktor.tara...@gmail.com a écrit : On Tue, Apr 3, 2012 at 8:36 AM, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: Le 3 avril 2012 00:30, Viktor Tarasov viktor.tara...@gmail.com a écrit : 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 . The official repository should be on opensc-project.org. github should be a mirror. So, the presented schema of the git workflow is invalid, and you are going to redesign it, isn't it? But gerrit was not working (or I did not know how to use it) so I merged pull request on github, that was a mistake. Then the two repositories diverged in incompatible ways. Maybe OpenSC on github should be deleted and recreated as a copy of opensc-project.org repository. Why to not do the same with the opensc-project.org repository and to recreate it as a copy of github ? This way looks more respective to the number of people who have forked the github OpenSC.git project. It's the opensc-project.org repository could be the mirror of the github's one -- the main development base. That may be the best solution: to restart from a synchronised state. I hope Martin will have more free time in a few days to implement that. 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?
Dear Ludovic, That may be the best solution: to restart from a synchronised state. I hope Martin will have more free time in a few days to implement that. As written several times before, we need more people with admin rights on OpenSC projects. There is no reason to limit to two people: Ludovic and Martin. What happens if one falls into cold water or does not show up as this happened before. OpenSC looks more and more like tokend or pcsc-lite: one admin and no collaboration. We are asking you to ease the collaboration process quickly or the community will set-up its own tools. We already have an independent build farm, this is a clear information that our next to-do on the list would be to wipe OpenSC project and open it to collaboration. -- 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: ease the collaboration process quickly or the community will set-up its own tools. Please stop blowing smoke. You want to fork so GO AND DO IT ALREADY! You clearly have no desire to work together with all members of the community. You've decided that only your own philosophy is the correct one, and you only want to work with those who follow you. All this while not sending an overwhelming amount of perfect patches, even for documentation, meaning that you have zero technical credibility. You are not in any position to make demands. You do not want to work within the established opensc-project.org structure, even though it allows you and everyone else to work quite freely thanks to Martin's effort of setting up gerrit and jenkins. Please go do your thing, but you obviously need to use a different name for your project. //Peter pgpwUiC0bQdin.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?
Peter. If you were a book editor waiting for a perfect book, you could be waiting for ages and as a result would NOT edit ANY book. This is what is happening to OpenSC, with dozens of patch waiting for the perfect developer. The perfect patch just does not exist. Quality is a continuous process of people working together and you have to let them the necessary freedom. As for my current work, I am setting-up an independent compilation farm. The first Debian packages are coming out in a few days: https://opensc.fr/jenkins/job/OpenSC-SM-Debian/ https://opensc.fr/jenkins/job/OpenSC-SM-Ubuntu-1/ https://opensc.fr/jenkins/job/OpenSC-SM-Ubuntu-2/ RPM distros are coming next. When this is done in around 1 week, we will call for clarification of the OpenSC project. This call for a clarification will allow us to discuss on release dates and the project goals. Don't think we are going to fork, this will not happen. You clearly have no desire to work together with all members of the community. You've decided that only your own philosophy is the correct one, and you only want to work with those who follow you. All this while not sending an overwhelming amount of perfect patches, even for documentation, meaning that you have zero technical credibility. You are not in any position to make demands. -- 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 3 avril 2012 00:30, Viktor Tarasov viktor.tara...@gmail.com a écrit : 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 . The official repository should be on opensc-project.org. github should be a mirror. But gerrit was not working (or I did not know how to use it) so I merged pull request on github, that was a mistake. Then the two repositories diverged in incompatible ways. Maybe OpenSC on github should be deleted and recreated as a copy of opensc-project.org repository. Or maybe we can achieve the same result in a soft way and make the 2 repos to converge again. 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 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
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
Re: [opensc-devel] How to deal with the gerrit backlog in an effective way?
Le 29 mars 2012 09:55, Viktor Tarasov viktor.tara...@gmail.com a écrit : Hello, On Wed, Mar 28, 2012 at 11:05 PM, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: Gerrit has more than 200 patches still waiting the the backlog. Many of them can't be merge since they do not 'fast-forward' and must be rebased by hand. Since the git commits were created without a Change-Id: we have 3 options (I think): 1. edit each commit message to add the missing Change-Id: and resubmit a rebased patch 2. reject all the patches rebase all the patches resubmit them as new gerrit entries 3. reject all the patches ask for new submission 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. Peter, I do not want to play with the gerrit configuration to remove the fast-forward requirement. I do not want to break something. Viktor, your proposal is work to do for someone. I do not volunteer. I tried to merge the changes from github and gerrit by rebasing github/staging on gerrit/staging. Many patches failed and I rejected them. I committed 5 of them after some rework. No one volunteered to help. As I wrote in my initial email, I now do plan for option 3. Dear contributors, please rebase your changes against the current gerrit/staging branch. Regards, -- 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?
Hello, On Wed, Mar 28, 2012 at 11:05 PM, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: Gerrit has more than 200 patches still waiting the the backlog. Many of them can't be merge since they do not 'fast-forward' and must be rebased by hand. Since the git commits were created without a Change-Id: we have 3 options (I think): 1. edit each commit message to add the missing Change-Id: and resubmit a rebased patch 2. reject all the patches rebase all the patches resubmit them as new gerrit entries 3. reject all the patches ask for new submission 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. I did option 1 for some patches. It is very borring and time consuming. Without help (man power) I do plan for option 3. I do not know if a creating a french OpenSC association to deal with the project governance will help here. But people with some free time can surely help move OpenSC. 'French OpenSC association' ? I saw it has been mentioned in the mailing thread but do not understood what for ? The process is simple. Select a patch and go to its oldest unmerged ancestor. Then do: # a. create a merge branch git branch merge # b. go inside local merge branch git checkout merge # c. get cherry-pick a patch from gerrit git fetch ... # d. add Change-Id: git rebase -i HEAD~1 # e. push git push gerrit HEAD:refs/for/staging # f. go inside staging git checkout staging # g. resync git pull The real command for step c. is given at the gerrit interface for a given patch. Example with https://www.opensc-project.org/codereview/#/c/45/ The command is git fetch https://www.opensc-project.org/codereview/p/OpenSC refs/changes/45/45/1 git cherry-pick FETCH_HEAD In step d. the missing Change-Id: line must be added in the commit message. In the git rebase in interactive mode replace pick by reword Then add the Change-Id: given by gerrit. In this case Change-Id: Ifc3b467d8a299897bb7417c8dfd09873f24e46f6 as the last line of the commit message. You can loop on steps c, d, e, c, d, e, ... Any volunteer? -- Dr. Ludovic Rousseau ___ 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
Re: [opensc-devel] How to deal with the gerrit backlog in an effective way?
Le 29 mars 2012 09:55, Viktor Tarasov viktor.tara...@gmail.com a écrit : Hello, On Wed, Mar 28, 2012 at 11:05 PM, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: I do not know if a creating a french OpenSC association to deal with the project governance will help here. But people with some free time can surely help move OpenSC. 'French OpenSC association' ? I saw it has been mentioned in the mailing thread but do not understood what for ? That was ironic. I should have used a :-) I do not know either why a 'French OpenSC association' could help. But some people (hello Jean-Michel) think it is the solution to all our problems. 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] How to deal with the gerrit backlog in an effective way?
Hello, Gerrit has more than 200 patches still waiting the the backlog. Many of them can't be merge since they do not 'fast-forward' and must be rebased by hand. Since the git commits were created without a Change-Id: we have 3 options (I think): 1. edit each commit message to add the missing Change-Id: and resubmit a rebased patch 2. reject all the patches rebase all the patches resubmit them as new gerrit entries 3. reject all the patches ask for new submission I did option 1 for some patches. It is very borring and time consuming. Without help (man power) I do plan for option 3. I do not know if a creating a french OpenSC association to deal with the project governance will help here. But people with some free time can surely help move OpenSC. The process is simple. Select a patch and go to its oldest unmerged ancestor. Then do: # a. create a merge branch git branch merge # b. go inside local merge branch git checkout merge # c. get cherry-pick a patch from gerrit git fetch ... # d. add Change-Id: git rebase -i HEAD~1 # e. push git push gerrit HEAD:refs/for/staging # f. go inside staging git checkout staging # g. resync git pull The real command for step c. is given at the gerrit interface for a given patch. Example with https://www.opensc-project.org/codereview/#/c/45/ The command is git fetch https://www.opensc-project.org/codereview/p/OpenSC refs/changes/45/45/1 git cherry-pick FETCH_HEAD In step d. the missing Change-Id: line must be added in the commit message. In the git rebase in interactive mode replace pick by reword Then add the Change-Id: given by gerrit. In this case Change-Id: Ifc3b467d8a299897bb7417c8dfd09873f24e46f6 as the last line of the commit message. You can loop on steps c, d, e, c, d, e, ... Any volunteer? -- 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?
Ludovic Rousseau wrote: Gerrit has more than 200 patches still waiting the the backlog. Many of them can't be merge since they do not 'fast-forward' and must be rebased by hand. Since the git commits were created without a Change-Id: we have 3 options (I think): 1. edit each commit message to add the missing Change-Id: and resubmit a rebased patch 2. reject all the patches rebase all the patches resubmit them as new gerrit entries 3. reject all the patches ask for new submission I did option 1 for some patches. It is very borring and time consuming. Without help (man power) I do plan for option 3. There's also an option 4, to decide that we want to change the configuration of gerrit to not require fast-forward, and work as if that change has already been done. This means reviewing existing changes and pushing new changes. When review is done and the change is good it gets +2 and may or may not be marked for submit. Once gerrit config has been changed all +2 changes would be applied in order, and a script could pick all up which haven't been explicitly submitted. The problem with this is of course that verification by jenkins will no longer be done for exactly the code that would end up in the repository. jenkins would run with $change added on top of current staging, but the actual inclusion of the change into staging may happen much later. Even if there is no conflict the code could still have changed in a way that jenkins does not catch. Requiring fast-forward completely avoids this problem. I think it might be a sane compromise to temporarily change the configuration, in order to more easily clear the backlog. But if we are to do so I think that there must under no circumstances be any new changes added (into staging) during that time. They can of course still be pushed to gerrit like always. I do not know if a creating a french OpenSC association to deal with the project governance will help here. Obviously not. But people with some free time can surely help move OpenSC. Yes, working on code is always the best way to help a project. The process is simple. Select a patch and go to its oldest unmerged ancestor. Then do: # a. create a merge branch git branch merge # b. go inside local merge branch git checkout merge Suggest combine the above a. and b. into: git checkout -b change123 staging Where change123 is the name for the new branch that will be created. # c. get cherry-pick a patch from gerrit git fetch ... # d. add Change-Id: git rebase -i HEAD~1 The above can be simplified to: git fetch ... git cherry-pick -e FETCH_HEAD ..which allows editing the commit message directly before doing the cherry-pick. If the message needs to be edited again, run: git commit --amend The command is git fetch https://www.opensc-project.org/codereview/p/OpenSC refs/changes/45/45/1 git cherry-pick FETCH_HEAD Instead of the URL it's also fine to put the name of the remote, in your example that's gerrit. # e. push git push gerrit HEAD:refs/for/staging # f. go inside staging git checkout staging Note that for the pull below to have any effect, it's important to submit the updated change in gerrit first. This means waiting for the verification, and then giving review +2 and finally submitting. In step d. the missing Change-Id: line must be added in the commit message. In the git rebase in interactive mode replace pick by reword Then add the Change-Id: given by gerrit. In this case Change-Id: Ifc3b467d8a299897bb7417c8dfd09873f24e46f6 as the last line of the commit message. Yes, very important. Thanks for the guide! //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
