On Wed, Oct 19, 2011 at 10:19 AM, Cedric Sodhi wrote: >> other developers may take care of your work when you're not around, >> others will feel responsible to provide support if they can,...). > > I think we have sufficiently seen how other people's work is taken care > of after they leave. And how much it helps in this regard, that the > planes are forced under the hood of GPL and subjected to your authority, > your restrictions. I think old, abandoned planes will equally, if not > more likely be willingly taken over by others, if they are not forced > into a master-repo.
Why? To my mind the practicality of being able to maintain and improve aircraft after the original author has left the project is one of the best reasons for having a shared repository. I have been involved in maintaining a number of aircraft after their original author's have moved on, so have quite a lot of experience in this area. I have found that having a shared aircraft repository has made it straightforward to make the (often quite minor) changes required to ensure that the aircraft continue to fly, and made it straightforward for new people to contribute, often years after the original author has left the project. A prime example of this is the Piper Cub. The following is from memory, so apologies if I get the names wrong: The original model was by David M. He moved on, and after a period of a number of years with only minimal maintenance (to ensure it continued to fly), another user (Karla IIRC) made significant improvements to the model. He himself moved on to other things, and more recently I myself took over and made some minor changes to the model and improved the FDM. If the aircraft had been held in a separate repository, the "minimal maintenance" would not have occurred, and the aircraft would have bit-rotted, and become unflyable. There's not much incentive to improve an aircraft that doesn't fly. It's unlike that Karla or myself would have put the effort into maintaining and improving the aircraft. Additionally, having a shared repository made the practicalities of maintenance straightforward. Karla didn't have commit rights, but was able to submit patches that were applied on his behalf by a team of committers. If there had been a separate private repository run by (say) Dave M, Dave would have had to commit the patches or give Karla commit rights. Dave's a nice bloke and I'm sure would have done so, but it's possible that contributors pass away, lose their passwords etc. The alternative is that Karla would have had to create his own repository, and fork the aircraft. All of this is more of a hassle. (I myself have commit rights, which makes life a lot easier) -Stuart ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
