Open Stack

Hi Mark, thanks for your answer.

On 05/03/2012 10:25 AM, Mark McLoughlin wrote:
> Hi,
>
> On Wed, 2012-05-02 at 14:37 +0200, Ionuț Arțăriși wrote:
>> I recently submitted a few fixes to the test suite in various components
>> of openstack.
>
> Thanks for that!
>
>
>> These fixes are being merged in master, but the code remains broken in
>> the stable/essex branch. Review requests for  stable/essex either get
>> rejected or stuck in limbo because it seems that people don't know
>> what to do about them.
>
> We're talking about this?
>
>    https://review.openstack.org/#/c/6619/
>

and this: https://bugs.launchpad.net/keystone/+bug/983800/ (comment #2)


> The issue here is that "Swift is different" :)
>
> Swift's releases are intended to be stable updates and AFAIK the Swift
> team feels that they don't need to do separate stable update releases.
> So the stable branch process we've put in place for the other projects
> doesn't apply to Swift.
>
> I've added a note to the wiki page about this.
>

Ok, good to know. Thanks.

>> I am aware of the procedure for backporting fixes[1], but I think it
>> does not deal with this issue correctly.
>>
>> Fixes to test scripts are for our benefit, the developers'. They don't
>> affect the users in any way. I don't think test code should be thrown
>> together with application code when thinking about making changes to
>> it.
>>
>> Only making test changes to the master branches reflects a belief that
>> tests are only used during development. I don't think this is
>> true. Tests, especially functional tests, are also incredibly useful
>> during maintenance. e.g. They help us test against different library
>> versions/distro than the one that's used for development and using
>> different deployment configurations.
>>
>> I suspect we're not the only downstream running the various testsuites
>> against their own packaged versions of different openstack
>> branches. Backporting these changes not only spares the time of other
>> projects who might run into these bugs on the stable branches later, it
>> also gives all of us the benefit of not having to fork the project just
>> so we can attach our patches. OTOH blocking test backports removes the
>> incentive that downstream projects have for reporting those bugs and
>> sending fixes for them upstream.
>>
>> So can we talk about separating the tests from the application code at
>> least as far as the backports are concerned? What about having the
>> 'test/' directory as a git submodule?
>>
>> Or maybe I don't understand this problem enough. What are the downsides
>> to backporting test-only fixes? Do they really outweigh the advantages?
>
> I think you've misinterpreted the response to your review so I won't go
> into the specifics of your points, but here's how I think about the
> backporting of unit tests:
>
>    - Unit test's main value IMHO is preventing regressions during
>      development.
>
>      Adding new unit tests can occasionally find new bugs too but, if I
>      want to find bugs on a stable branch, it would be functional tests
>      I'd write.
>
>    - As such, I don't think a concerted effort across the project to
>      systematically backport unit tests from master to the stable branch
>      is time well spent.

I'm not advocating that someone spend time to look through all the 
patches to unittests in master and backport them to stable. What I'm 
asking for is that when someone submits a test fix backport it would be 
*accepted* in a stable branch after the proper review process.


>      However, anyone is welcome to maintain their own tree based off the
>      stable branch and use that as a venue for finding bugs with new
>      unit tests. I'd hope those tests would go into master first, though.
>
>    - Also, a worthwhile goal on a stable branch is to keep churn to a
>      minimum. You could argue that tests deserve a free pass because
>      changes to those can't introduce regressions but, when it comes to
>      a stable branch, I'm sceptical that any patch is "zero risk" never
>      mind a whole class of (generally quite large) patches.
>

I think you're again talking about backporting all test fixes here in 
bulk. But apart from that, I don't really see how testsuite-only patches 
which go through the same review process as normal patches can break 
anything in application code and be deemed "risky"?


>      Part of keeping churn to a minimum on a stable branch is that
>      reviewers default answer should be "no". Unless a patch meets the
>      "safe fix for a high-impact, user-visible issue" then it doesn't
>      belong in the stable branch.
>
>    - That said, if someone adds a new test to master and it uncovers a
>      significant user-visible bug (or uncovers a bug and adds a test for
>      it), then I think it makes sense to backport the unit test to master
>      along with the bug fix. It helps verify that the backported patch
>      does fix the bug.
>
>    - And finally, I think it's sane for downstreams to run the unit
>      tests. As you say, it can catch issues where downstream is using a
>      different version of a library than upstream. If a downstream
>      uncovers an issue like this, fixes it on master with a unit test
>      and backports the fix and unit test to stable, I think that's great
>      too.

Well you think it's great and I think it's great, but somehow we don't 
agree with one another? This is what I did. Uncovered a bug in the tests 
on a different version/configuration, submitted the fix to master -> it 
got accepted. Submitted the fix to stable -> it got rejected. Or are you 
saying that these fixes are not important because they're only testsuite 
fixes?

Finally, I'm fine with any attitude to backporting test fixes (though I 
strongly prefer backporting them), but let's please make it deliberate 
and clear and then document it on the wiki page. This is why I started 
this discussion.

-Ionuț