On Tue, Apr 16, 2013 at 03:46:34PM +0200, Miklos Vajna wrote: > On Tue, Apr 16, 2013 at 08:08:20AM -0500, Norbert Thiebaud > <nthieb...@gmail.com> wrote:
>> humm... with moving of 1000's of headers... I wonder what the limit >> will then be needed ? >> also, that must impact gerrit too. iow I would need to increase that >> parameter on the gerrit side so that cherry-picking works ? >> or do we want to consider that for these few transient patch that >> will need cherry picking accross the move, people should manually >> rebase theses patch are re-push them to gerrit ? > I thought our current workflow is: > - devA cherry-picks a commit from master to -4-0 > - devA pushes to refs/for/4-0 > - devB fetches from gerrit, tests, review, then pushes the button if it > looks OK (or pushes to refs/heads/4-0) > In this workflow no adjustment on the gerrit side is needed, I > guess. I think Norbert meant: - devA prepares patch *before* the headers move - devA pushes to refs/for/master - devB fetches from gerrit, tests, review, then pushes the button - gerrit does a rebase (automatically) OR - devA prepares patch *before* the headers move - devA pushes to refs/for/master - devB pushes the "rebase" button in gerrit IMHO, ideally we would: - increase the setting massively in gerrit - move the headers - wait for all the patches in gerrit made before the move to be treated - wait for a reasonable "nobody will push patches from older master anymore" time - put the setting in gerrit lower (back to default?) -- Lionel _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
