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 krinklemail@gmail.com 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 benapetr@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 krinklemail@gmail.com wrote:
On Jun 29, 2012, at 1:04 PM, Chad wrote:
On Fri, Jun 29, 2012 at 6:58 AM, Petr Bena benapetr@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