On Wed, Aug 20, 2008 at 3:52 PM, Martin Spott wrote:
> The FlightGear project has been notoriously behind about getting
> people's source code contributions into CVS - for years. We all know
> the story, it's been the same for years already, no need to repeat it
> here.
>
> So, in order not to loose the respective contributions over the time,
> such a GIT repo - be it mine or someone else's - makes the perfect tool
> that allows contributors to maintain their changes in a local branch
> while still easily keeping them in sync with the main source tree(s).
> Thus, it will be highly beneficial for the FlightGear project as a
> whole to support these developers by backing an official GIT repo
> instead of letting their enthusiasm fade out in disappointment ....
>
> Guess why there are there so many private GIT repositories containing
> modified versions of FlightGear source trees !? Please think of it and
> keep up with the times.
Perhaps I misunderstand the scope and capabilities of git, but the way
things settle out in my mind is that it would make sense to support an
official GIT repository if (and only if) we decide to move the official
master code repository to GIT. I don't see what an "official" GIT mirror
provides over and above individual developer GIT mirrors. I do see that we
have a variety of ad hock git repository clones that serve the needs and
agendas of their individual developers/owners. Those seem to already do
exactly what you propose. I suspect that one size does not fit all here ...
(?) Is it possible for all the developers that run local repository mirrors
and clones to git (hah, pun!) on the same page and move all their diverse
stuff into a single repository? Would they all even want to? If the answer
is a resounding yes, that would be good for me to know.
And at the end of the day, no matter what source code version control system
we use, and no matter what useful tools it provides for branching and
merging, we still need a human in the loop to act as a sanity check to
evaluate and approve changes that go into the master repository. (I
understand this is a philosophical choice on my part. Another approach
would be to let any and all changes from just about anyone to be committed
to the master repository and let the review step happen when things break or
crash or stop functioning optimally ... I just do not like that particular
approach.)
I agree that you are right that the development community has needs that
should be better addressed, but my concern is to not act too swiftly and
make choices that immediately benefit only a few vocal developers at the
expense of other less vocal developers and perhaps serve the overall
community less well than before. I'm not saying that your proposal falls
into this category, just that I'd like to continue to move cautiously to
make sure that it doesn't (especially in the case of GIT which still has
questions surrounding it's ability to function well for non-unix
developers.)
Regards,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
