On 2010-04-20T08:20:57, Florian Haas <[email protected]> wrote:
> > And the first two _are_ still used/maintained for the SLES10 > > packages. > Which means they'll _never_ even install a resource-agents package > without risking to lose support. Why do we need to carry those RAs in > future upstream releases of resource-agents then? Well, first, I'm entertaining the notion to upgrade SLES10 to a recent package build. Second, I was just pointing out that they are still being used by some, and I very much object to the notion to dropping RAs in minor releases with 1-6 months lead time. I find the policy per se inacceptable, sorry. This is _enterprise_ code, not J. Random Project people install for fun. Anything that is user-visible and has the potential to bring down configurations that work today but wouldn't after the update is a no-go. > > The LinuxSCSI RA is, to the best of my knowledge, not broken either, and > > does something entirely different from either SCSI reservations or sfex. > But is has BETA written all over it, and you were on the CC list of the > bug where we agreed that these should be deprecated and removed from > future releases. Why are you complaining now? > > See comment > http://developerbugs.linux-foundation.org/show_bug.cgi?id=2244#c1 > specifically. You could have corrected us _then_. I _miss_ things. People do. If even I missed it, what is your guess how many users will not have noticed anything? > > drbd - conceded, but shouldn't there then be a symlink to the new > > version (which will do work in 99% of all cases unless someone used my > > ill-conceived floating peer support)? > Fine with the idea of the distro doing that via RPM magic. This is _irresponsible_ to our users of the community packaging. I'm at a loss for words. > Aw c'mon, now don't _you_ start _me_ on rolling upgrades! Yes, I do. Because I it is extremely painful if it is not possible. Trust me; I'm on the receiving end of those scenarios. We got away with it once from SLES10 to SLE11, because the jump is too massive technically for anything else to work, but here we are talking "x.y.z vs x.y.z+1". Even pacemaker 0.6 to 1.0 is mostly automatic, unless the XSLT transform fails. (Which, except for one or two bugs, it hasn't.) Even then the cluster configuration was auto-converted. > Besides like the other Lars said: welcome to maintenance mode. If it is that simple, it should be automatic. We should not piss of our users. Regards, Lars -- Architect Storage/HA, OPS Engineering, Novell, Inc. SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
