On Mon, 16 Jul 2007, Lars Marowsky-Bree wrote:
On 2007-07-16T12:20:42, David Lang <[EMAIL PROTECTED]> wrote:
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
project.
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"?
this one seems simple to me.
"are stable" means that the project considers them as good as any other package,
the code has gone through the same minimum testing as any official package.
"may be stable" means that they have no known problems (which would make them
unstable), but they have additional patches that haven't been run through the
same tested as the official packages
today the difference between these two boil down to 'Alan R blessed it', this
works well for the kernel where Linus is involved continuously, Alan has had
other things come up that distract him and keep him away from the list enough
that it's not working well for heartbeat. This is why I suggested further below
that the testing get more formalized and make it so that more then one person
can make official releases.
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.
and I with a formalized testing criteria I think that it would be a good idea if
a release could be made by any two of the three of you.
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.
I don't think anyone is implying that you are deliberately releaseing buggy
releases, but that's not the same as saying that the releases have all gone
through the same testing.
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.
yes, I agree to everything you are saying. this isn't the first time I have been
in a lurch becouse Alan hasn't made a release recently. I've been useing
heartbeat since almost the beginning, I was there for the rapid flurry of
releases that Alan talked about in this first message. I've also had several
times over the years that I have experianced problems that others haven't (I
have something like 50 clusters in production, if something odd happens with
heartbeat I definantly hear about the problem)
what I am seeing as the biggest stumbling block (although I admit that there may
be others, including personal feelings and control) is the testing of a release
candidate on the hell cluster. if that cluster testing can be automated so that
it doesn't require Alan's invovlement to test on it, then it may be reasonable
to say that any two of the four of you (you, Andrew, Dejan, and Alan) can take
any build that has passed the testing and bless it as a release.
yes, this involves Alan loosening control over the project, I hope he is willing
to do so.
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.
I (reluctantly) admit that this may be the case, but I will still argue that the
closer everyone's release can be to the mainline the better. The current
situation is about as bad as I've seen heartbeat get (although I haven't been
paying close attention, there may have been other times) due to the long time
since the last official release and the numerous bugs involved.
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.
true, but again look at what has happened with the kernel code, in the 2.5
timeframe things got bad enough that SuSE and RedHat kernels were so different
from each other and from kernel.org that they were incompatible with each other.
HEartbeat has not gotten this bad, but similar problems on a smaller scale ar
still possible. For the kernel the different distros are working hard to
minimize the patches they maintain seperatly, I'm just asking for the same
attitude towards heartbeat.
(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 ;-)
if the binaries end up being the same (accounting for library differences) I
don't care about the rest of the build or packaging differences.
David Lang
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
