[Pacemaker] Reminder: Pacemaker-1.1.10-rc5 is out there

[Lars Marowsky-Bree]

On 2013-06-26T21:31:14, Andrew Beekhof <andrew at beekhof.net> wrote:

> > Distributions can take care of them when they integrate them; basically
> > they'll trickle through until the whole stack the distributions ship
> > builds again.
> If we let 2.0.x be anything like 1.1.x, I suspect this would be rather difficult.

Not sure. With the sore exception of 1.1.8, the integration effort was
reasonable, even for an Enterprise distribution. Yes, for changes so
large and intrusive, a temporary branch (or a longer release cycle)
would probably be preferable.

> The change I'm thinking of (CPG codepaths and global variables) was becoming a major support overhead and all-round headache.
> I hadn't planned to make that change, but it was the best way to fix a bug that was holding up the release.

Yeah, that one. If it fixes a bug, it was probably unavoidable (though
the specific commit (953bedf8f7f54f91a76672aeee5f44dc465741e9) didn't
mention a bugzilla id).

But that trickles through all consumers here - OCFS2, DLM, sbd. Means we
have to do more validation than a -rc should normally need - normally,
during an rcX phase, I'd expect small, well-contained bugfixes for
regressions only.

But perhaps this was one such exception.

(Which bug did it fix, by the way? Can't immediately spot it from the
commit code.)

> Plus it is still my intention not to have API changes in 2.0.x, so better before than after.

I wonder how that will go ;-) I don't really mind the API changes much,
for me it's mostly a question of timing and how big the pile is at every
single release.

If you consider the API from a customer point of view, the things like
build or runtime dependencies on shared libraries aren't so much of an
issue - hopefully, the distribution provider hides that before they
release updates. Hence my "Oh well, I don't care" stance.

What's more troublesome are changes to existing commands (even something
minimal like "crm_resource -M" now generating a short location
constraint, which could potentially break scripts that interact with the
CIB), or major changes to log messages (since those do break customer's
scripts and monitoring environments).

> > Important is to of course keep the major/minor numbers of the libraries
> > updated so one doesn't get runtime problems.
> I have been quite diligent running ./bumplibs.sh in preparation for releases for a while now.

Yes. Didn't mean to say it isn't working, just wanted to mention it.
Because an update that fails to install until all dependencies are fixed
is (mostly) fine, but one that installs and then breaks really annoys
customers ;-)


Regards,
    Lars

-- 
Architect Storage/HA
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde