Open Stack

Ah! Now we're getting right on the spot, where it hurts, and we're
finding the root cause. That's a very good thing. Let's dig ! :)

On 04/19/2016 05:26 PM, Chris Dent wrote:
> I, in project A, don't want to limit my requirements because project B
> has not yet upgraded itself to be able to use the new features in
> library X.

Solution: if given a reasonable time for project B, ignore project B,
declare it bad, and point fingers at the contributors of project B for
not doing the needed maintenance work.

But by the way, what is that bad library X that you're talking about,
which is constantly breaking backward compatibility? Isn't *that* the
source of the issues to begin with? Shouldn't we then just avoid library
X and find a better replacement, which does *not* break the API every
odd weeks?

> At the same time, people in project B don't want to have to upgrade
> themselves, when they are not ready, simply because project A wants
> to upgrade.

They are wrong. They *must* upgrade, because upstream for library X will
anyway supporting the old deprecated version next week.

That's a simple easy rule: the very latest version of *any* component
should always be the winner. Everyone should adapt.

Oh... and did I mention backward compatibility? Yes I did, and yet
everyone understand why the Linux kernel never breaks userland... :)

> That's an actual problem.

Which is due to bad upstream breaking compat.

> All the rest of the discussion is coming

... as ways to avoid issues due to bad code. Let's fix the code, or
avoid the bad one.

Cheers,

Thomas Goirand (zigo)