Hi John,
John Wojnaroski wrote:
> If this had been a commercial development and the product had been
> released in this state, we would all be updating our resumes at this
> point...
No doubt. Still the point is: The product is not intended to be
released in this state. In fact, current state is not only not intended
to be released, it's not declared as a release candidate nor as BETA or
ALPHA (or pre-ALPHA, whatever you like), it's simply where current
development is heading for, in other words: a development source tree.
Yes, it actually is this, and nothing more. Please let us keep this
as the basis of the discussion .... at least I'm convinced that this
is fact ....
People apparently got used to the state that FlightGear typically has a
CVS tree that you can compile at the end of a development day and
'fly'. This usually isn't a bad idea because FlightGear has no such
thing as real quality control before a release. Instead people simply
drop their code, and fixes, into CVS during a so called development
cycle, the most obvious glitches are getting cleared at the end of the
cycle and the result is being shipped as "release". I have been trying
to document ongoing development of FlightGear for a long time, I know
what I'm talking about.
But does this _necessarily_ have to be this way _all_ the time ? Do
people really have to get into panic when this is not the case for a
short period in a development cycle ? In my eyes this is completely
exaggerated. Other software projects, commercial and OpenSource, stand
much longer distances without having a source tree that matches at
least release candidate level and without users getting into panic in
that time. So why should FlightGear make an exception here ?
In fact the changes that make the port to OSG are not simply dropped
into CVS and left there alone, instead the remaining issues are
actively being worked on. The "core developer" for this move just
doesn't have the habit to write long EMail postings to the list but
instead to spend the available time for actual coding ;-)
> [...] If OSG is superior in
> performance, ease of development, features, etc then it needs to win
> that argument based on the principal of natural selection. And those
> advocating its selection need to endure the pain of dual paths and
> double work until the existing plib head shrivels and dies from
> user/developer apathy.
The question that I have to pose here: Does FlightGear really have the
ressources to maintain two development trees and put "the pain of dual
paths and double work" upon those who really push the development ?
Have a look at the CVS changelog and compare the names you find there
from the past development cycles with the names of those people who are
performing the loudest cries on this list .... and you'll get a very
clear picture. I'd say these people do better by experiencing a bit
more of patience, or, even much better, help with clearing the
remaining issues, if they have the skills to do so.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
