Am 16.10.2011 20:01, schrieb Alan Teeder:
> Flightgear already has such a system for scenery.  You only download
> what you want, or need. Very few users need scenery for the whole
> world.
> Extending this concept to the bloated aircraft section of fgdata
> seems quite logical.

It's important though to see the difference between the end-user 
front-end and our developer's back-end of the system.

In fact, for end-users, we already have such a front-end for aircraft: 
http://www.flightgear.org/download/aircraft-v2-4/  ;-)
Users get a base package and only download what they need - same for 
scenery as for aircraft. It's just that the aircraft front-end is 
completely manual - which can be improved.

Now, we're changing the aircraft repository back-end, which is what 
developers are supposed to use. Note that scenery developers also don't 
use the terrasync/SVN front-end for submitting their work. And now that 
we're creating separate aircraft GIT repositories, it still isn't the 
best idea to use these for end-user deployment. GIT is great for 
development - you can merge/branch/stash nicely. But it's not really 
what an end-user needs.

> I donĀ“t think that anyone is talking about splitting apart the core
> parts of fgdata, just the optional aircraft.

Not sure :). Once we're at it, we can also move other things out of 
fgdata, which don't really belong there. The "Models" folder for 
example, since that's not maintained there - it's just a copy of what is 
maintained in the scenery database and we shouldn't modify it directly 
in fgdata. And it's also fairly large and the second biggest part of the 
remaining archive. When all aircraft have gone, just the Texture & 
Models folders make up 50% of the remaining git archive. And their 
archive is much larger than the even biggest of our aircraft (and 
spacecraft... ;-)).
Once we start using git submodules, we can also go for a cleaner 
solution here. One or two more submodules won't make much of a difference.

> Perhaps one day someone will come up with a terrasync-like option to
> one of the front-ends ( fgrun) which will get chosen aircraft on-the
> fly when needed.

Yes, like what James is currently working on? ;-)
http://sourceforge.net/mailarchive/message.php?msg_id=27707002
http://wiki.flightgear.org/Aircraft_deployment#Proposal_from_James

He's made the proposal a while ago and is still working on it. Note, 
this is planned as an end-user front-end and supposed to be as automatic 
and convenient as downloading scenery already is. But all this is 
completely independent of the solution/repository type we're using for 
development.

cheers,
Thorsten

------------------------------------------------------------------------------
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

Reply via email to