Hi all, On Thursday 25 February 2010 02:44:32 pm Tim Moore wrote: > I don't see how that follows from the "beauty of having one repository". I > see the "one repository" model as slowing down all work, collaborative or > not. >
Since my original email seems to have sparked much more controversy that I intended, let me just try to clarify a few aspects. I should probably say "a *coordinated* development effort", as opposed to a "single repository". I don't really object that much to the fact that independent bits and pieces of FlightGear contributions are stored in physically different locations, but I do wish to see that the individual bits and pieces continue to play nicely with each other. One possible drawback of having independent repositories is that development becomes uncoordinated among them, leading to incompatibility and conflict. I do see this type of uncoordinated fragmentation as being counterproductive, and not contributing to a positive user experience. I want to emphasize that apart from a few "private sandboxes", most of these sites appear to exist for genuine reasons, but nevertheless I currently see some fragmentation and lack of coordination.To take an example, various aircraft models can be found at various stages of development scattered across different sites, and (to take another example) individual scenery bits are scattered around various places, and /or designed without a clear long term development plan in mind. Currently it is up to the user to track all these individual contributions and try to make sense of it. The beauty of a central repository is that as an (admittedly experienced) user you don't need to bother about tracking all these sites, and just run "cvs up" to get all the latest and the greatest, with usually quite amazing stability. Of course, there are alternatives for CVS, and the software package manager on my Linux (OpenSuse 11.1) laptop is a good example of that. All I need to do is run an "update" command, and it accumulates patches from a number of repositories, even commercial ones if I want. I can imaging that with a little thought on how to set this up, a more distributed, yet coordinated, development effort is feasible for FlightGear. In such a scenario, users would run a fairly simple-to-use updater, which would check their favorite sites, and install new updates according to their preferences. That is kind of the system I can see would provide the best of both worlds. To do this, contributions one various sites should probably adhere to just a few simple rules. As long as we don't have a such an automatic updater, I'm a little weary against add on sites, because it may easily lead to conflicting development issues that will not benefit the user experience. If we go down that path, it may lead to a situation where more and more interesting features are ending up in add-on packages, making the core of FlightGear less interesting. That, in turn, would lead to considerable more user effort to make an interesting simulation environment. Ultimately, a situation like this (fragmented addon scenery and mutually incompatible addon modules) has been one of the major reasons why I gave up on MSFS, and decided to fully focus on FlightGear instead. Cheers, Durk ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
