%% "Charles Hines" <chuck_hines_at_vnet.IBM.COM> writes:
ch> I prefer the term 'semi-mythical' myself.
:)
ch> I have to admit that my progress with fvwm has been less than optimal
ch> (as I warned it would be when I started) and I've been sorely tempted
ch> lately to give up the care and feeding of fvwm to someone else because
ch> of that.
I notice that no one (including, I'm first to admit, me) is jumping up
and down to take your place, so don't feel bad :)
ch> - Work on 2.0.47 is going ok (but slowly). Quite a bit is going
ch> into it.
A comment: in my experience this is extremely common with free software,
and one of the major issues to be addressed for any free software
development process. I've seen it with perl, Linux, fvwm, gcc, etc.
People just keep adding features, and more features, and more and more
features, and a "stable" release never comes out because with every
release that fixes bugs in the last set of features there are more
features to be debugged.
And it only gets worse the more time that elapses between some kind of
reference release, because people get worried that the _next_ "stable"
release will take as long as the last one, and they're all pushing to
get their favourite item into _this_ one so they don't have to wait a
few years for the next one, and then this one takes longer, etc. etc.
A vicious catch-22 :)
My opinion, FWIW, is that no more new features should be accepted,
period (okay, maybe the autoconf stuff can go in! :). Make one release
with not a single new feature, but just whatever bug fixes there are,
then cut 2.1 if that looks reasonable after 3 weeks or so (give a hard
deadline to prod people into getting/installing the latest version).
The only way to get out of this is for someone to be hard-hearted and
say "forget it; you have to wait." Not that these aren't the world's
greatest features, but a line has to be drawn, and kept.
Note this _only_ works if we can commit to getting the release _done_
within a month or so of the feature freeze. Otherwise things will back
up too much and the dam will break again.
ch> - I hope that only one or two more 'betas' will be necessary after
ch> that before 2.1.0 can finially appear. As I said, quite a bit is
ch> going into 2.0.47 and some bugs will have to be ironed out, but I
ch> think that it's finially getting close... Hm... Paul, does that
ch> sound familiar? :)
Yep :)
As I said above, IMO we will never be able to stop the "one or two more
betas" until we stop the "just a few more features".
--
-------------------------------------------------------------------------------
Paul D. Smith <psmith_at_baynetworks.com> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions--Bay Networks takes no responsibility for them.
--
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 Tue Dec 09 1997 - 15:47:14 GMT