On Tue, Mar 13, 2012 at 6:59 PM, Peter Stuge <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 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 > 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
