[Linux-HA] Re: [Linux-ha-dev] Release testing with CTS
lmb at suse.de
Mon Jul 16 14:30:25 MDT 2007
On 2007-07-16T12:20:42, David Lang <david.lang at digitalinsight.com> wrote:
> this did not read as a put-down to someone who hasn't been intimatly
> involved over the last seveal months. remember that e-mail doesn't show
> experessions or tone of voice, don't assume the worst intentions unless
> they are completely clear.
Well ... Man, I can't pass that opportunity up if you put it like this,
but you're spot on - that the project leader was not intimately involved
in the project is part of the problem ;-) Besides, I tire of pretending
that no emotions are involved. I'll remain courteous and mostly
friendly, but I will allow myself to show that I care.
> >releasing substandard packages. Particularly given that I am the author of
> >the majority of the HAv2 code and therefor have arguably the most interest
> >in its quality.
> the inferance was that you are releasing packages that haven't gone through
> some of the testing that has proven valuble in the past history of the
Yes, but why would one make such an inference, and at the same time
remove the pointers to these packages from the channel topic on IRC and
rearrange the wiki DownloadSoftware page - including a change from "are
stable" to "may be stable"?
It's a matter of fact that Andrew, Dejan and I have jobs which mostly
revolve around heartbeat full-time. Which is not going to change soon.
Novell customers are probably the single largest source of heartbeat
deployments. We're in an _excellent_ position to judge the quality of a
given heartbeat release.
Implying, or even hinting at the mere idea that we might be putting out
substandard releases while not just our _reputation_ but our _business_
is at stake, is just wrong.
> what I (as a long time user of heartbeat) would prefer to competeing
> releases and project fragmentation is instead some more discussion about
> what needs to be done to have more official releases.
We've had those discussions in the last years. Sorry. I'm not willing to
head down there again and discuss details.
And it is not as if Alan doesn't know. Alan is an _excellent_ engineer.
He is an _excellent_ social person and brilliant speaker. (If you're not
trying to get a word in yourself, that is ;-) I have nothing but the
highest respect for him in those roles. He knows what it takes to put
out a great release, as you can see right now.
But any project needs _continuous_ attention by its leader to be and
remain successful. It needs a certain set of policies which are
followed, and not bypassed. It requires some coherency in the technical
design, which requires on-going attention to what it does and how. A
project leader needs to _support_ all that, not hinder it.
That's perfectly fine. We all have different jobs which allow (or force)
us to focus on different things. We all have different personalities -
some of us excel at high reward short-term projects, others are fine
with taking on-going grunt work and like to think more long-term.
Problem is: project leadership is a lot of grunt work.
> Due to the fact that people's involvement does wax and wane this should
> probably have some way of allowing multiple people to make a release, but
> all releases should go through what the project determins are the minimum
> set of tests.
That would be wonderful, but it doesn't address the above issue.
> going the route that the kernel has gone with each distro patching the base
> version and distributing slightly different things, but all named the same
> version numbers is not the way I would want to see this project go. please
> try to avoid this.
This will be hard to avoid. There'll always be slightly different
releases with at least minor different patches. It's close to
impossible, and at least not feasible, to _exactly_ align release
schedules. So there'll always be a few patches difference.
It's not as if the Novell version completely diverges. It has, with one
exception, always been based on a version taken from the upstream code
stream, just from a slightly different point of view.
(And, of course, we had to change the build process, because heartbeat's
build logic is totally screwed for most distribution build systems;
which is why Alan calls our packages "not official", but we CANNOT use
it, and he knows why. It's not as if a distributor would know anything
about building packages, would we ;-)
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
More information about the Linux-HA