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(a)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(a)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(a)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(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l