If we are testing multiple items in same moment, replacing one test with another is actually problem. That's what we need to somehow merge right now. I hoped that gerrit could do it for us.
And we test multiple items there almost all time :) On Fri, Jun 29, 2012 at 2:22 PM, Krinkle <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> wrote: >>>> On Jun 29, 2012, at 1:04 PM, Chad wrote: >>>> >>>>> On Fri, Jun 29, 2012 at 6:58 AM, Petr Bena <[email protected]> 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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
