On 2013-06-27T14:28:19, Andrew Beekhof <and...@beekhof.net> wrote: > I wouldn't say the 6 months between 1.1.7 and 1.1.8 was a particularly > aggressive release cycle.
For the amount of changes in there, I think yes. And the intrusive ones didn't show up all at the beginning of that cycle, either. That just made integration difficult - basically, we ended up skipping 1.1.8/1.1.9 and went mostly with 1.1.10-rcx. > Generally though, it has always been hard/dangerous to backport > specific fixes because of the complexity of the interactions - > particularly in the PE. Yes, that's why we try to avoid backports ;-) > > Yeah, that one. If it fixes a bug, it was probably unavoidable > > (though the specific commit > > (953bedf8f7f54f91a76672aeee5f44dc465741e9) didn't mention a bugzilla > > id). > It has always been the case that I find and fix far more bugs than > people report. > I don't plan to start filing bugs for myself. True, I didn't mean that was necessary. A one liner about the fix would have been helpful, though. > In this case though, I made an exception because the plan is to NOT have > another 1.1.x and "it is still my intention not to have API changes in 2.0.x, > so better before than after". True. I admit I would probably have taken that as a reason for inserting one more 1.1.x release, but I understand you have your own scheduling requirements. > Granted I had completely forgotten about the plugin editions of ocfs2/dlm, > but I was told you'd already deep frozen what you were planning to ship, so I > don't understand the specific concern. We're already working towards the first maintenance update ;-) And it's not a specific concern (we'll delay that one until it's all settled again), but we were discussing changes and how to schedule releases for them; and from the point of view as a consumer/user, introducing such a change in what was supposed to be the "last" release candidate was a huge surprise. > There is never a good point to make these changes, even if I make them just > after a release people will just grumble when it comes time to look at the > next one - just like you did above for 1.1.8. No, that's not quite it. 1.1.8 *was* special. Also look at the impact it had on our users; LRM rewrite (which implies huge logging changes), crmsh split, changes to m/s ... 1.1.8 was an exception in what otherwise is a rather impressive track record of releases. Normally, integrating new releases has always been rather straightforward. But I don't want to dwell on that. > > 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. > I thought you wanted longer release cycles... wouldn't that make the > pile bigger? No, I generally tend to want shorter release cycles, with a more moderate flow of changes. (As far as that is concerned.) > And is it not better to batch them up and have one point of > incompatibility rather than a continuous stream of them? Well, that means we end up backporting the changes that can't wait. And the cliff to jump from to the next release just becomes larger and more deterring. > > 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. > Except if it affects ocf2/dlm/sbd? I don't care for the fact that the changes were made, much. The new interface looks like a win and code reduction. My comment was, as stated above, specifically about doing such a change in a late release candidate. > > What's more troublesome are changes to existing commands (even > > something minimal like "crm_resource -M" now generating a short > > location constraint, > I find it confusing how an contained 10 line change to a CLI tool is > troublesome Because it shows through to users. And it's then when I start having to worry about users complaining when their scripts break (that expected the tools to do something specific; though I hope that in this case it doesn't - we'll document it as an optimization). > but you're prepared to wear the overhead of holding back > API changes - which usually impact all sorts of code paths, sometimes > across multiple projects. We don't hold them back. We'll fix the dependencies before the release. It's my intention to keep being as close to a (tested) upstream version as possible, because everything else ends up being very costly. The difference is that the latter is a cost that is internal to us as developers, and not something that users/customers would possibly care about. (Unless they've written their own add-on code, which is truly rare.) > CLI output I can usually be convinced of, but log messages are most > definitely not something I will consider as a valid programming interface. Agreed. It's not an API, that's for sure. Yet it's one of the interfaces to *customers* and their system monitoring tools. Yes, one must be allowed to change them, but they need to be documented (by someone, not necessarily you). It's my hope that regression test suite for the crm shell history explorer will help catch them and thus help with documentation. 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 _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org