Re: mock 1.2 breaking tests (was: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental)
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). 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: