"Curtis Olson" wrote:
> 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 ...
You're missing a small but quite interesting piece: Given the case that
the local repositories would all base on and sync with the same
'primary' CVS-to-GIT gateway, it's getting far simpler for the
respective developers/contributors to pull and merge the changes from
each other, thus sharing their develpment for tests and cross-checks
while still tracking CVS alias GIT _without_ waiting for the detour via
official CVS.
> 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.
My intention is not to challenge this your choice, I was just pointing
out that the delay which is caused by the respective evaluation and
approval process has been 'notoriously unpredictable' ;-)
> [...] Another approach
> would be to let any and all changes from just about anyone to be committed
> to the master repository [...]
The point is that you're too often unable to afford the time that
whould be required to tell wether the aspirant falls into the "just
about anyone"-category (I guess you remember that such a case had been,
in fact, initiating what has now grown up to the GIT mirror on our
MapServer machine).
If you're holding up this very choice, then you should also face the
fact that this choice is not the appropriate solution for attracting
really cluesome FlightGear developers. In this case you should at least
agree to establishing some tools that allow people to mitigate the
implications of the well-known bottlenecks.
> 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 [...]
I'm unable to follow your conclusions regarding CVS write access and
vocal developers ....
Good night,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
-------------------------------------------------------------------------
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
