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 <pe...@stuge.se > <mailto:pe...@stuge.se>> 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 <http://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/ > <https://opensc.fr/jenkins/> -- 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 > <mailto: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 <deeng...@anl.gov> 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
