Re: mock 1.2 breaking tests (was: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental)

[Ian Cordasco]

On Tue, Oct 6, 2015 at 8:53 AM, Jeremy Stanley  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).

Re: mock 1.2 breaking tests (was: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental)

[Thomas Goirand]

On 10/06/2015 02:49 AM, Jeremy Stanley wrote:
> On 2015-10-05 23:45:57 +0200 (+0200), Thomas Goirand wrote:
> [...]
>> Upstream will *not* fix the issue, because you know, they "fixed" it in
>> their CI by adding an upper version bound in the pip requirements, which
>> is fine for them in the gate. It is fixed in OpenStack Liberty though,
>> which I will soon upload to Sid.
> [...]
> 
> It's a bit of a mischaracterization to say that "upstream will not
> fix the issue." In fact as you indicate it was fixed within a couple
> days in the master branches of affected projects.

Master != kilo. It still means that I have to do all of the backport
work by myself. Or are you suggesting that I package from trunk in Sid?
Or that backports of such fixes were available? If the later, then I
missed it.

> The mock pin in
> stable/kilo branches is a temporary measure and can be removed if
> all the broken tests are either removed or corrected (the assumption
> being that distro package maintainers who have an interest in that
> branch may volunteer to backport those patches from master if this
> is important to them).

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.

Thomas Goirand (zigo)

Re: mock 1.2 breaking tests (was: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental)

[Jeremy Stanley]

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.
-- 
Jeremy Stanley