Imagine:
Some guy wants to deploy extension to Jamaican wikiversity and test it on labs for 2 months before deploying to production. He create a patch of config files and submit to gerrit. We merge it to test and extension is immediately deployed on beta.
Another guy wants to test configuration change of Korean wikisource, he submit a patch, we merge it to test and he can test it on labs. Both tests are running together.
Once any of tests are over, we can merge them to master. This isn't possible with gerrit-review, or I don't know how
On Fri, Jun 29, 2012 at 2:28 PM, Petr Bena benapetr@gmail.com wrote:
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