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