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(a)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(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