[pytest-dev] on abolishing the feature branch concept

[Ronny Pfannschmidt]

Am 25.01.2016 um 15:04 schrieb Florian Bruhin:
> * Ronny Pfannschmidt <opensource at ronnypfannschmidt.de> [2016-01-25 14:36:12 +0100]:
>> i think we need to be much more strict on what a bugfix is
>> for example the regression in 2.8.6 was caused by the "feature"
>> of more detailed exceptions from monkeypatch
> I agree this particular PR should've gone to 'features'. IMHO it'd
> have been the responsibility of Bruno and you to tell the author to
> reopen it against features.
>
> But in general I think it's working pretty well, no?
>
in general its working well, but i also recall we had similar issues
with incremental changes in other releases as well,
i don't yet have hard data collected, but i believe we have a pattern
there of followup bugs happening too often,
and i'd like to see a process to reduce those
>> if we go to a __strict__ handling of bugfixes,
>> then much more of what had gone to the 2.8.6 release would have landed
>> in the features branch
> I reviewed the commits because I was curious about this.
> Other than the change above and another change which is debatable
> ("Make monkeypatch calls O(1)") all of those seem like bugfixes or
> trivial doc changes to me.
indeed, we have a lot of trivial looking changes,
the one that caused the regression in 2.8.6 also looked relatively simple.

Which is why i was making the point on more strictness wrt bugfix vs
feature :)
my impression is, that in the past few months we got a bit too accepting
of little "features"
in the bugfixing branch
>> another more and more apparent issue is, that our current testsuite
>> and style of testing in pytest can't provide sufficient branch
>> coverage in various situations, the regression that happened in
>> 2.8.6 should have been something the testsuite catches before.
> I was surprised this wasn't caught as well - then again pytest's
> coverage is at 93% according to coveralls, which doesn't seem too
> shabby to me.
unfortunately code coverage an entirely useless indicator,
whats needed is state and branch coverage

which is impossible to do with acceptance tests

>> to that effect it might even be sensible to change from master +
>> features to bugfix + master
> I thought we discussed this to death before already, and ended up with
> master/features :P
i'm aware, i'm bringing it up, because of the little details i noticed
over the last few months
it's much less problematic to have to backport/cherrypick a bugfix than
accidentally slipping in a feature change to a bugfix release

im also fine with keeping the branch names as is,
the important part is better discipline on our side :)
>
> Florian
>
-- Ronny