marvin master changes in 4.4-forward

[Marcus <sh...@gmail.com>]

I was troubleshooting some marvin issues today, and noticed that
deployDataCenter.py is completely rewritten in master. That's fine, but
then I went to make a 4.4-specific patch for an issue, and found that the
rewrite is in 4.4-forward, so I can't really create a commit anywhere to be
cherrypicked into 4.4.

I wondered why this commit was put into 4.4-forward when it seems like a
refactor (should be bugfixes only, right?), but the commit doesn't say much:

commit 404ac549bfd84e97c756009f214e74cdb73548de
Author: SrikanteswaraRao Talluri <ta...@apache.org>
Date:   Mon Apr 28 14:55:11 2014 +0530

    Marvin + test changes from master Signed-off-by: SrikanteswaraRao
Talluri <ta...@apache.org>

    Signed-off-by: SrikanteswaraRao Talluri <ta...@apache.org>

RE: marvin master changes in 4.4-forward

[Santhosh Edukulla <sa...@citrix.com>]

1. The changes were first listed, implemented and then merged from topic branch to master after a call for merge was made on the list. The changes were later merged to 4.4-forward branch as it was mentioned that, daily automation and regular runs were done using 4.4-forward branch.  One thing for sure we can make a note here is that the 4.4-forward code is run on regular basis for regression\bvt and has no issues related to these changes for marvin\test suites.

2. The fixes and commits we see under 4.4-forward either to tests or marvin are either because of new test suite additions, test suite fixes and get the pass percentage for it to be up, so fix any suite issues and if not, raise a product issue. This is happening regularly.

3. There was a proposal to merge test and marvin changes to 4.4 branch as well from 4.4-forward branch, i believe with this both 4.4-forward and 4.4 branch will be in sync if we merge. So, 4.4 will have latest new test suites, test suite fixes with better coverage,  We can merge that or as it is get the test suite and marvin changes to 4.4. We need some help to merge, if there were no issues raised with this approach. 


Regards,
Santhosh


________________________________________
From: Daan Hoogland [daan.hoogland@gmail.com]
Sent: Tuesday, May 27, 2014 5:32 PM
To: dev
Subject: Re: marvin master changes in 4.4-forward

I share that last concern. I have seen a lot of commits on the branch
not matched by cherry-pick requests.

On Tue, May 27, 2014 at 11:16 PM, Marcus <sh...@gmail.com> wrote:
> My impression was that we should change as little as possible once a
> release is cut. We fix bugs, but we don't change code just to make it more
> maintainable, for fear of introducing more bugs or regressing the known
> state of the release.
>
> That aside, this fix is fairly minor so I'll probably just drop it. The
> only question that remains is what people should do going forward when a
> change needs to be made to an RC branch that is incompatible with its
> "-forward" branch.
>
>
> On Tue, May 27, 2014 at 2:23 PM, Daan Hoogland <da...@gmail.com>wrote:
>
>> Marcus,
>>
>> I don't see why only fixes should go in 4.4. It should have been
>> announced before feature freeze but there might be good reasons to
>> refactor if it improves maintainability or removes bugs. You can
>> revert the related commit and apply yours. or mix them.
>>
>> regards
>>



--
Daan

Re: marvin master changes in 4.4-forward

[Daan Hoogland <da...@gmail.com>]

I share that last concern. I have seen a lot of commits on the branch
not matched by cherry-pick requests.

On Tue, May 27, 2014 at 11:16 PM, Marcus <sh...@gmail.com> wrote:
> My impression was that we should change as little as possible once a
> release is cut. We fix bugs, but we don't change code just to make it more
> maintainable, for fear of introducing more bugs or regressing the known
> state of the release.
>
> That aside, this fix is fairly minor so I'll probably just drop it. The
> only question that remains is what people should do going forward when a
> change needs to be made to an RC branch that is incompatible with its
> "-forward" branch.
>
>
> On Tue, May 27, 2014 at 2:23 PM, Daan Hoogland <da...@gmail.com>wrote:
>
>> Marcus,
>>
>> I don't see why only fixes should go in 4.4. It should have been
>> announced before feature freeze but there might be good reasons to
>> refactor if it improves maintainability or removes bugs. You can
>> revert the related commit and apply yours. or mix them.
>>
>> regards
>>



-- 
Daan

Re: marvin master changes in 4.4-forward

[Marcus <sh...@gmail.com>]

My impression was that we should change as little as possible once a
release is cut. We fix bugs, but we don't change code just to make it more
maintainable, for fear of introducing more bugs or regressing the known
state of the release.

That aside, this fix is fairly minor so I'll probably just drop it. The
only question that remains is what people should do going forward when a
change needs to be made to an RC branch that is incompatible with its
"-forward" branch.


On Tue, May 27, 2014 at 2:23 PM, Daan Hoogland <da...@gmail.com>wrote:

> Marcus,
>
> I don't see why only fixes should go in 4.4. It should have been
> announced before feature freeze but there might be good reasons to
> refactor if it improves maintainability or removes bugs. You can
> revert the related commit and apply yours. or mix them.
>
> regards
>

Re: marvin master changes in 4.4-forward

[Daan Hoogland <da...@gmail.com>]

Marcus,

I don't see why only fixes should go in 4.4. It should have been
announced before feature freeze but there might be good reasons to
refactor if it improves maintainability or removes bugs. You can
revert the related commit and apply yours. or mix them.

regards