On 10/06/2015 05:26 PM, Ian Cordasco wrote: > On Tue, Oct 6, 2015 at 8:53 AM, Jeremy Stanley <fu...@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). :)
