[First, a note to non-US readers, or those who may not be as familiar with
slang phrases. The saying "beating a dead horse" means continuing to debate an
issue long after everything has been said-- in essence, repetition of the same
set of arguments over and over. It derives from a centuries-old practice of
using horses to pull loads, carriages, etc. To get more performance out of the
horse, the master would beat its flanks with a crop. But if you pushed too
hard, the poor beast would just up and die on you. To continue "beating a dead
horse" accomplishes nothing.]
I was inclined to pipe in on the original thread, but it didn't take long for
it to turn into a circular repetition of the same arguments. Speaking as some-
one who has contributed patches and developed a Perl 5 extension for module
authoring, I have to say that the "Rats from a ship" thread is beating a dead
horse.
Try to remember, you are using a package that is freely available, unlike
OpenView or Motif. Those products have development teams devoted to them,
because Sun and OSF (respectively) can budget some of the revenue into further
development. Fvwm is, at its core, the effort of one person. There are a lot
of engineering issues surrounding team development, and when the team is in
fact scattered across the globe, linked only by the Internet, those issues can
become amplified. Don't believe me? Ask anyone working on a GNU project.
In recent weeks, the primary author of Fvwm has chimed in to offer explanation
as to *why* he has not bundled a new release recently. Fvwm is not his day job.
And since this isn't a vendor-supported project, there aren't others to carry
the torch while he attends to other priorities.
In short, it can be said that while no one should complacently accept Fvwm's
not-optimal code as the end of the development line, the users should accept
the fact that Fvwm does work, works well, and that the current developer is not
sitting on his bum doing nothing, but will in fact continue to develop the
product.
Now, if someone wanted to contribute to such an effort, I have no doubt that
such things as coverage analysis, memory usage/leakage analysis, code structure
etc. would be of use not only to Charles, but to anyone eager to volunteer to
assist him.
Randy
--
===============================================================================
Randy J. Ray -- U S WEST Technologies IAD/CSS/DPDS Phone: (303)595-2869
Denver, CO rjray_at_uswest.com
"It's not denial. I'm just very selective about the reality I accept." --Calvin
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Mon Jul 07 1997 - 11:51:41 BST