On Jun 29, 2012, at 2:11 PM, Petr Bena wrote: > Current idea: > > someone submit a config change > this change is merged to testing branch > we git pull on labs > people test if change works ok and submit review to gerrit > we merge to master branch or reject it > > On Fri, Jun 29, 2012 at 2:07 PM, Petr Bena <benap...@gmail.com> wrote: >> Yes but that would probably overwrite any previous tests
No, git-review checks out the the remote ref/changeset in a local branch, preserving the proper context/history of that change set. These branches are not removed or overwritten. It does mean, however, that you can't randomly stack different tests upon eachother, but that's a good thing and avoids common errors. Herein lies also immediately the advantage: If a series of commits is submitted that depend on eachother, git-review'ing the top one will give you all, just like in mediawiki/core.git. Because we'd checkout a commit pointer with its parent tree, not a single commit on top of the previous test state (which what a testing branch would enforce). And it saves maintenance by not having to continously reset test to master – after (re-)submission and merging it for the second time. I'm not (yet) very active in the "beta" project on labs, but I imagine it would make sense not to introduce an neccecary double-review process here. They are in gerrit pending merge to master, and they can be checked out on labs as it is, that's a main feature of git-review. And afterwards checkout master again and leave your comments on gerrit and/or review, merge it. I'm not a big fan of Gerrit's overal design, but one the great aspects is that each change proposal is a branch by design. So in a way, every time a merge request is pushed to gerrit, you've got a branch new "testing" branch ready to be checked out. I agree with Chad, there is no problem with an actual "testing" branch, but if we can avoid it with an (what could be) a better workflow with less overhead of rebasing, dependency manipulation and double-merging etc. then.. -- Krinkle >> >> On Fri, Jun 29, 2012 at 1:23 PM, Krinkle <krinklem...@gmail.com> wrote: >>> On Jun 29, 2012, at 1:04 PM, Chad wrote: >>> >>>> On Fri, Jun 29, 2012 at 6:58 AM, Petr Bena <benap...@gmail.com> wrote: >>>>> Can we create a new branch which would be speedily merged when changes >>>>> were done to it, so that we could check out on labs and apply the >>>>> change there in order to test if patches submitted by devs works ok? >>>>> Thanks to Antoine we use the same repository on beta project, but >>>>> right now it's really hard to test stuff submitted to gerrit because >>>>> we need to merge stuff by hand. >>>>> >>>> >>>> I don't see any problem with this really, as long as the branches >>>> don't get wildly out of sync like the puppet repo did. >>>> >>>> -Chad >>>> >>> >>> Note that one can also use git-review in labs (if not, lets install it >>> then). >>> >>> I'm not sure if this sounds crazy, but you could do git review -d 1234 >>> and test it that way. >>> >>> -- Krinkle >>> _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
