Re: mock 1.2 breaking tests
On 10/06/2015 05:26 PM, Ian Cordasco wrote:
> On Tue, Oct 6, 2015 at 8:53 AM, Jeremy Stanley <fungi@yuggoth.org> wrote:
>> On 2015-10-06 09:28:56 +0200 (+0200), Thomas Goirand wrote:
>>> Master != kilo. It still means that I have to do all of the backport
>>> work by myself.
>> [...]
>>> I know that it's the common assumption that, as the package maintainer
>>> in Debian, I should volunteer to fix any issue in the 6+ million lines
>>> of code in OpenStack ! :)
>>>
>>> I do try to fix things when I can. But unfortunately, this doesn't scale
>>> well enough... In this particular case, it was really too much work.
>>
>> That is the trade-off you make by choosing to maintain as many
>> packages as you do. You can obviously either spend time contributing
>> stable backports upstream or time packaging software. Just accept
>> that, as with Debian itself, "stable" means OpenStack upstream makes
>> the bare minimum alterations necessary. This includes, in some
>> cases, continuing to test the software in those branches with
>> dependencies which were contemporary to the corresponding releases
>> rather than chasing ever changing behavior in them. Sometimes it is
>> done for expediency due to lack of interested volunteer effort, and
>> sometimes out of necessity because dependencies may simply conflict
>> in unresolvable ways.
>
> And to be fair, this has been discussed many times on the mailing list
> with you Thomas. The ratio of cores to stable maintenance cores is
> probably something upwards of 5:1. Most of the latter group are also
> members of the former group which means they have double the
> responsibility (if not more, because stable maintenance is a lot more
> involved than a place on the regular core reviewer team). The reality
> is that stable packages relying on versions that were contemporary at
> the time of their release is very very reasonable (and that's how,
> e.g., stable linux distros work).
Yes. I agree, and I am very well aware of these facts. I was barely
pointing it out, thanks for writing it better than I ever would.
> After all "stable" is just the name
> for "broken in ways we know about", otherwise one would call it
> "perfect" for being forever in a working state under all unexpected
> conditions (which no piece of software really is).
:)
Reply to: