It's good to get the view from both sides of the coin. :-)
Hopefully the larger point to be made is that we are moving forward with
terragear-cs and my main point of jumping in here is to try to give some
context and hints and understanding of the basic system. There's no point
in chasing down the wrong paths in search of bugs and work arounds.
Regards,
Curt.
On Sun, Apr 17, 2011 at 1:49 PM, Martin Spott <martin.sp...@mgras.net>wrote:
> Curtis Olson wrote:
> [...]
>
> I'm trying not to add yet another iteration to the debate about the two
> terms "topologically correct" vs. "good enough", everything's already
> been said (details upon request, if required), but I think one point
> ought to be made very clear in this context, for those who are unaware
> of the history of "terragear-cs".
>
> > The terragear-cs fork has had substantial changes from my original
> terragear
> > tree. [...] So the
> > point is I let the fork happen, and let others take over management of
> > terragear, because it was just far far beyond what I could handle
> thinking
> > about at the time.
>
> Stating that Curt "let the fork happen" could be quite misleading
> because people might understand that the fork would have been 'planned'
> in some way - which is entirely incorrect. Instead, the fork was
> actually nothing but the last resort after, within a period of ten !!
> months, Ralf Gerlich neither a) got a patch reviewed, which he had
> submitted to Curt nor b) was given write access to the TerraGear CVS
> repository.
>
> I _do_ acknowledge that Curt might have his very personal reasons for
> not considering Ralf's work then, but, let's be honest, what would
> _you_ do when you feel like being stuck in a dead end for such a long
> period as Ralf did, and would like to proceed in what you started ?
>
> Let me guess, I think you'd be creating a fork, and may it just be for
> the sole purpose of having your own development versioned. Nowadays
> people are creating their own public forks (ah, "clones" ;-) of
> "terragear-cs" before submitting _anything_ - which is't that bad at
> all - as long as they're planning to submit their changes sooner or
> later.
>
> Cheers,
> Martin.
> --
> Unix _IS_ user friendly - it's just selective about who its friends are !
> --------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
