Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Jacob Burbach]

I understand there are a some cases where one might need all aircraft
to perform some specific task, and when I said "unlikely ANYONE would"
I could have spoken better. However for the vast majority of
developers, contributors, and testers, I have to believe it is
completely unnecessary or desired to get everything. For those power
developers that DO actually need everything, I also have to believe
they are more than capable of figuring out how to import some repos,
run a script, etc.

It is not wise to continue to let fgdata repository just grow and grow
without end, it cannot be sustained in that manner indefinitely. More
aircraft are created all the time, it is not going to get smaller or
easier for people to work with. How many people have we already
alienated, who may have otherwise been able to contribute, simply
because they do not have access to the bandwidth necessary to deal
with fgdata at no fault of their own?


cheers

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Ciosco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Jari Häkkinen]

On 2011-10-19 21.12, Torsten Dreyer wrote:
> Another example: For the last release, we branched and tagged the
> repositories and well defined states. This was OK for three repositories
> (fg+sg+fgdata). Doing this manually for 300+ repos is a no and doing
> this scripted calls for trouble.

But is there a need to tag all 300+? Only a handful aircraft are part of 
fg releases.

I do understand that some/many have the need to download all aircraft, I 
will for sure do that. For me the download size is not the issue. I 
genuinely think that the split will benefit the project. Of course, if 
it alienates developers then the change may turn out to be a bad move. 
Why not wait and see how the new repository structure plays out? It is 
easy to revert if needed. What is the cost? A short delay in committed 
fgdata changes. Development doesn't have to stop since all of us have a 
clone of the old fgdata that can be used to keep track of our changes.


Jari

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Ciosco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Torsten Dreyer]

Am 19.10.2011 20:45, schrieb Jacob Burbach:
> Seems like most people are just banging their heads against the wall
> trying to make a new system the same as the old, which is counter
> productive and unfortunate. It is highly unlikely ANYONE needs every
> single aircraft from git that they were previously forced to take,
> which is the whole point of the change. If people are honest with
> themselves I think they would realize they only need such aircraft
> that they plan to use or do development on. Personally I am extremely
> happy that I will no longer need to pull down hundreds of aircraft I
> have no intention of ever touching just so I can work on and test
> development new development in flightgear.
Fair point. But some of use might need to walk through all aircraft from 
time to time. One example: I'm working on a new implementation of the 
navradio code (the code that does the VOR/LOC/GS computation). I'd 
prefer to guarantee some degree of backward compatibility with existing 
aircraft. Which ones should I choose?

Another example: For the last release, we branched and tagged the 
repositories and well defined states. This was OK for three repositories 
(fg+sg+fgdata). Doing this manually for 300+ repos is a no and doing 
this scripted calls for trouble.

I'm not saying that the old situation (one single repo) is heaven on 
earth. But for me as a developer, it has more advantages than 
disadvantages. I have no issues with the size, I branch, merge, pull and 
push in seconds. Only, git gc --aggressive takes some time.
>
> In the end this will make it much, much easier for new developers and
> testers to get up and running and get to work.
I'm not convinced that this is true.

Torsten

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Ciosco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Curtis Olson]

On Wed, Oct 19, 2011 at 1:45 PM, Jacob Burbach  wrote:

> Seems like most people are just banging their heads against the wall
> trying to make a new system the same as the old, which is counter
> productive and unfortunate. It is highly unlikely ANYONE needs every
> single aircraft from git that they were previously forced to take,
> which is the whole point of the change. If people are honest with
> themselves I think they would realize they only need such aircraft
> that they plan to use or do development on. Personally I am extremely
> happy that I will no longer need to pull down hundreds of aircraft I
> have no intention of ever touching just so I can work on and test
> development new development in flightgear.
>
> In the end this will make it much, much easier for new developers and
> testers to get up and running and get to work.
>

A developer that needs to make download packages for every available
aircraft?
A developer that wants to check if a source code change will impact the
available aircraft (or gauge what the level of impact would be if they made
a particular change.)
A developer that needs to update code, and also fix all the associated
aircraft to track a code change.
A user who likes to be a collector and have everything available to browse
through whether they plan to use a particular aircraft today or not.
I could probably think of many more if I thought for a while longer.
We can't be short sighted here and do a major regression that causes
problems for a lot of people, just because there are some vocal people who
don't have a personal need for every usage case.

I know we all worship at the alter of git, but isn't the main problem here
is that we are forcing everyone to download the complete binary history of
everything in the data package, and this is not scaling well for us?  If we
put it to a vote, I wonder how our general user population would respond to:
Do you want (a) the entire binary history of everything (b) the entire set
of aircraft.

We are committed to git, I'm not suggesting otherwise, but the entire binary
history of the data tree is pushing 10Gb.  My understanding is that
splitting off the aircraft wouldn't reduce the total size, but would allow
us to deal with smaller chunks and optionally cherry pick just the parts we
want.  But if the result is that it is an immense effort or very difficult
to get all the data and all the aircraft for people that want it (for any
reason) then we have a problem.  Telling them they don't need it and
shouldn't download it is not really a good answer.

Here's another way to look at it.  We need to keep policy and capability as
separate as possible.  If we end up with significantly reduced capability,
just redefining our policy is going to make a lot of people unhappy.
 Ideally we should find a solution that offers the required capabilities to
support different policies.  People that just want a few aircraft can
establish that policy for themselves, people that want all the aircraft can
establish that policy for themselves.

We can't go around telling people what they should want or what they should
do in response to taking something away from them and implying there's
something wrong with them if they think otherwise.

Curt.
-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Ciosco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Jacob Burbach]

Seems like most people are just banging their heads against the wall
trying to make a new system the same as the old, which is counter
productive and unfortunate. It is highly unlikely ANYONE needs every
single aircraft from git that they were previously forced to take,
which is the whole point of the change. If people are honest with
themselves I think they would realize they only need such aircraft
that they plan to use or do development on. Personally I am extremely
happy that I will no longer need to pull down hundreds of aircraft I
have no intention of ever touching just so I can work on and test
development new development in flightgear.

In the end this will make it much, much easier for new developers and
testers to get up and running and get to work.

cheers
--Jacob

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Ciosco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[James Turner]

On 19 Oct 2011, at 17:47, Curtis Olson wrote:

> One more super module question: if I start plowing through 350 aircraft by 
> hand, and then next week you come out with a super module, will that require 
> me to redownload everything, or can that be retrofitted on top of the modules 
> I've already fetched? 

I think you need to re-download everything, I'm afraid.

But maybe a Git expert can correct me.

James


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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Curtis Olson]

On Wed, Oct 19, 2011 at 11:03 AM, Curtis Olson wrote:

> A super module sounds ideal if that's doable in git.  Looking forward to
> it!  For now, maybe I have to sluff along with the aircraft from the old
> fgdata repository.
>

Hi James,

One more super module question: if I start plowing through 350 aircraft by
hand, and then next week you come out with a super module, will that require
me to redownload everything, or can that be retrofitted on top of the
modules I've already fetched?

Thanks,

Curt.
-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[TDO_Brandano -]

We have to make a small distinction here. Are we talking about users or 
developers? As it was pointed out earlier, GIT should not be seen as a 
distribution mechanism, this is a task best left elsewhere, and possibly 
managed by the frontend. It should not be difficult to just archive all the 
planes for download in a single install package. If you want to use the 
unstable, unreliable planes from git, then you should put up with the idea that 
it might require a little more than a single click for you. That said, it is 
perfectly possible to make a tool that will do this for you automatically.

Ciao,

Alessandro

Date: Wed, 19 Oct 2011 18:06:24 +0200
From: jorgvanderve...@googlemail.com
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after  
the Split

Normally windows users want everything in a 1 click download like precompiled 
packages. Maybe we can do this serverside, let them check a box for each 
aircraft or select all and simply give them a link?

Jorg


2011/10/19 TDO_Brandano - 






The greatest problem i can see is that there's no wget equivalent for Windows, 
or tools to parse strings from a file, inbuilt in the shell. That's why I was 
mentioning python: it's easier to get working on Windows and these tools are 
part of the standard library. On linux, of course, you can get all the data 
with a savvy combination of wget, grep and sed.


Ciao,

Alessandro

> Date: Wed, 19 Oct 2011 17:42:49 +0200
> From: anders-...@gidenstam.org
> To: flightgear-devel@lists.sourceforge.net

> Subject: Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after 
> the Split
> 
> On Wed, 19 Oct 2011, Curtis Olson wrote:
> 
> > Sure we can script it out, but do I have 2-3 days right now to fiddle with a

> > script?  Not this week myself.
> 
> Updating aircraft repositories you have cloned should be easy enough,
> a quick and dirty bash hack:
> 
> for d in my-aircraft-dir/*; do (cd $d; git pull --rebase); done

> 
> (Testing that $d is indeed a directory might be good, though.)
> 
> Initial cloning is slightly worse since you'd need to get the URLs (or 
> the changing part of it) from somewhere (like the php script mentioned 

> above?).
> 
> 
> Cheers,
> 
> Anders
> -- 
> ---
> Anders Gidenstam
> WWW: http://www.gidenstam.org/FlightGear/

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

  

--

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





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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[jorg van der venne]

Normally windows users want everything in a 1 click download like
precompiled packages. Maybe we can do this serverside, let them check a box
for each aircraft or select all and simply give them a link?

Jorg

2011/10/19 TDO_Brandano - 

>  The greatest problem i can see is that there's no wget equivalent for
> Windows, or tools to parse strings from a file, inbuilt in the shell. That's
> why I was mentioning python: it's easier to get working on Windows and these
> tools are part of the standard library. On linux, of course, you can get all
> the data with a savvy combination of wget, grep and sed.
>
> Ciao,
>
> Alessandro
>
> > Date: Wed, 19 Oct 2011 17:42:49 +0200
> > From: anders-...@gidenstam.org
>
> > To: flightgear-devel@lists.sourceforge.net
> > Subject: Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life
> after the Split
> >
> > On Wed, 19 Oct 2011, Curtis Olson wrote:
> >
> > > Sure we can script it out, but do I have 2-3 days right now to fiddle
> with a
> > > script? Not this week myself.
> >
> > Updating aircraft repositories you have cloned should be easy enough,
> > a quick and dirty bash hack:
> >
> > for d in my-aircraft-dir/*; do (cd $d; git pull --rebase); done
> >
> > (Testing that $d is indeed a directory might be good, though.)
> >
> > Initial cloning is slightly worse since you'd need to get the URLs (or
> > the changing part of it) from somewhere (like the php script mentioned
> > above?).
> >
> >
> > Cheers,
> >
> > Anders
> > --
> >
> ---
> > Anders Gidenstam
> > WWW: http://www.gidenstam.org/FlightGear/
> >
> >
> --
> > 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
>
>
> --
> 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
>
>
--
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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Curtis Olson]

On Wed, Oct 19, 2011 at 11:03 AM, Curtis Olson wrote:

> Hi James,
>
> A super module sounds ideal if that's doable in git.  Looking forward to
> it!  For now, maybe I have to sluff along with the aircraft from the old
> fgdata repository.
>

Replying to myself:

Once we have a super-module for all the GPL aircraft in our central
repository, it would be interetesting to begin work on a 2nd super-module
for all the available externally maintained aircraft repositories we can
find.

Thanks once again,

Curt.
-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Curtis Olson]

On Wed, Oct 19, 2011 at 10:48 AM, James Turner wrote:

> The intention is create a super-module which has each aircraft as a
> submodule. Eg an 'all-aircraft' repository, for people who want this.
>
> Ideally someone with some scripting skills would automate creating that
> repository, and then we're back to a few steps:
>
>clone
>init submodules
>pull (which will recursively pull, and take ... some time)
>
>
Hi James,

A super module sounds ideal if that's doable in git.  Looking forward to it!
 For now, maybe I have to sluff along with the aircraft from the old fgdata
repository.

Thanks!

Curt.
-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[TDO_Brandano -]

The greatest problem i can see is that there's no wget equivalent for Windows, 
or tools to parse strings from a file, inbuilt in the shell. That's why I was 
mentioning python: it's easier to get working on Windows and these tools are 
part of the standard library. On linux, of course, you can get all the data 
with a savvy combination of wget, grep and sed.

Ciao,

Alessandro

> Date: Wed, 19 Oct 2011 17:42:49 +0200
> From: anders-...@gidenstam.org
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after 
> the Split
> 
> On Wed, 19 Oct 2011, Curtis Olson wrote:
> 
> > Sure we can script it out, but do I have 2-3 days right now to fiddle with a
> > script?  Not this week myself.
> 
> Updating aircraft repositories you have cloned should be easy enough,
> a quick and dirty bash hack:
> 
> for d in my-aircraft-dir/*; do (cd $d; git pull --rebase); done
> 
> (Testing that $d is indeed a directory might be good, though.)
> 
> Initial cloning is slightly worse since you'd need to get the URLs (or 
> the changing part of it) from somewhere (like the php script mentioned 
> above?).
> 
> 
> Cheers,
> 
> Anders
> -- 
> ---
> Anders Gidenstam
> WWW: http://www.gidenstam.org/FlightGear/
> 
> --
> 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
  --
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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[James Turner]

On 19 Oct 2011, at 16:27, Curtis Olson wrote:

> Right now we've replaced a one-line command with several weeks of manual 
> work.  (Or so it appears.)  I understand the reasons, and we need to move 
> forward, but I think this is a logic gap here -- an unforeseen side effect, 
> and a problem we (someone) needs to scramble on to address.

The intention is create a super-module which has each aircraft as a submodule. 
Eg an 'all-aircraft' repository, for people who want this.

Ideally someone with some scripting skills would automate creating that 
repository, and then we're back to a few steps:

clone
init submodules
pull (which will recursively pull, and take ... some time)

James


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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Anders Gidenstam]

On Wed, 19 Oct 2011, Curtis Olson wrote:

> Sure we can script it out, but do I have 2-3 days right now to fiddle with a
> script?  Not this week myself.

Updating aircraft repositories you have cloned should be easy enough,
a quick and dirty bash hack:

for d in my-aircraft-dir/*; do (cd $d; git pull --rebase); done

(Testing that $d is indeed a directory might be good, though.)

Initial cloning is slightly worse since you'd need to get the URLs (or 
the changing part of it) from somewhere (like the php script mentioned 
above?).


Cheers,

Anders
-- 
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/

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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Curtis Olson]

On Wed, Oct 19, 2011 at 10:14 AM, TDO_Brandano -
wrote:

>  Not automatically, as far as I know, but it should be relatively simple to
> script this. the main issue is how to script something that will work across
> platforms. I can do this in less than 20 lines of python, but of course not
> everyone has python installed on his windows machine
>

We (someone?) definitely needs to do something here.   I'm sitting here now
having cloned the fgdata-new repository with zero aircraft and zero
instructions for fetching them.  I know enough git and I know the root path,
so I could go do this -- but for 350 aircraft, this would be weeks of manual
work interleaved with lots of waiting to get all of them and then a major
pain to update them all in the future or notice and fetch new aircraft.

Sure we can script it out, but do I have 2-3 days right now to fiddle with a
script?  Not this week myself.

What about new users coming to the project?  We need to have some
instructions and a reasonable mechanism that works for everyone.

Right now we've replaced a one-line command with several weeks of manual
work.  (Or so it appears.)  I understand the reasons, and we need to move
forward, but I think this is a logic gap here -- an unforeseen side effect,
and a problem we (someone) needs to scramble on to address.

Anyone have any good ideas? Can anyone knock something out quickly?

With svn you can just checkout the top level, or checkout any subtree
underneath that individually.  Is there any similar concept with git?

Thanks,

Curt.
-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[TDO_Brandano -]

Not automatically, as far as I know, but it should be relatively simple to 
script this. the main issue is how to script something that will work across 
platforms. I can do this in less than 20 lines of python, but of course not 
everyone has python installed on his windows machine

Ciao,

Alessandro

From: curtol...@gmail.com
Date: Wed, 19 Oct 2011 10:03:25 -0500
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after  
the Split

Question on the new repository layout:
I would like to pull every aircraft from 
https://gitorious.org/flightgear-aircraft/


Is there a way to do this in a single command or do I have to manually identify 
each aircraft in the repository and manually clone it here?  If someone adds a 
new aircraft to this repository, will it get automatically fetched on my next 
git pull or do I have to manually check for new aircraft and manually pull them 
each individually?


Thanks,
Curt.


On Wed, Oct 19, 2011 at 8:59 AM, George Patterson wrote:


On 19 October 2011 19:29, Cedric Sodhi  wrote:

>

>  https://gitorious.org/flightgear-aircraft



Last night, the discussion came up where the above page is slow to

load, in part it's due to 1.2MB of HTML code, plus the CSS, plus the

any images in use. Not very browser friendly. I hacked together a php

script that will parse a locally stored version of the above page and

display urls to the individual aircaft "projects". On irc, Zorg, Gijs

and perhaps a few others in the #flightgear channel had a poke it and

gave it a nod. Tonight I have improved it, and it now validates as

XHTML 1.0 Strict.



I guess, what essential information do we require from the above

Gitorious resource page. I can add parsing of the each aircraft's

RSS/atom feed, but will need to work on caching first. Currently I

have been periodically fetching the above page and saving it as a

static resource that is then referred to as requested. It should help

those that are on slower connection or pay a high data rate for

traffic. (Or those who are pressed for time. :-) )



The url is http://fgfs.dyndns.info/aircraft.php I haven't linked it

from the front page ofhttp://fgfs.dyndns.info as yet.



Regards





George



> to officially publish your planes as part of the Flightgear project.

>>

>> 2.  Assuming the answers are no, yes, to #1, will all these repositories

>> be centrally located so one can track new or modified ac of interest?

>

> If you do not wish to publish your planes under the conditions outlined

> above, for instance because you don't want to use Gitorious or because

> your plane is not GPL, then, so Thorsten, you will not be entitled to be

> listed and tracked centrally (I personally don't agree with that).

>

> --

> regards,

> ManDay

>



--

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



-- 
Curtis Olson:http://www.atiak.com - http://aem.umn.edu/~uav/

http://www.flightgear.org - http://gallinazo.flightgear.org



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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Curtis Olson]

Question on the new repository layout:

I would like to pull every aircraft from
https://gitorious.org/flightgear-aircraft/

Is there a way to do this in a single command or do I have to manually
identify each aircraft in the repository and manually clone it here?  If
someone adds a new aircraft to this repository, will it get automatically
fetched on my next git pull or do I have to manually check for new aircraft
and manually pull them each individually?

Thanks,

Curt.



On Wed, Oct 19, 2011 at 8:59 AM, George Patterson wrote:

> On 19 October 2011 19:29, Cedric Sodhi  wrote:
> >
> >  https://gitorious.org/flightgear-aircraft
>
> Last night, the discussion came up where the above page is slow to
> load, in part it's due to 1.2MB of HTML code, plus the CSS, plus the
> any images in use. Not very browser friendly. I hacked together a php
> script that will parse a locally stored version of the above page and
> display urls to the individual aircaft "projects". On irc, Zorg, Gijs
> and perhaps a few others in the #flightgear channel had a poke it and
> gave it a nod. Tonight I have improved it, and it now validates as
> XHTML 1.0 Strict.
>
> I guess, what essential information do we require from the above
> Gitorious resource page. I can add parsing of the each aircraft's
> RSS/atom feed, but will need to work on caching first. Currently I
> have been periodically fetching the above page and saving it as a
> static resource that is then referred to as requested. It should help
> those that are on slower connection or pay a high data rate for
> traffic. (Or those who are pressed for time. :-) )
>
> The url is http://fgfs.dyndns.info/aircraft.php I haven't linked it
> from the front page ofhttp://fgfs.dyndns.info as yet.
>
> Regards
>
>
> George
>
> > to officially publish your planes as part of the Flightgear project.
> >>
> >> 2.  Assuming the answers are no, yes, to #1, will all these repositories
> >> be centrally located so one can track new or modified ac of interest?
> >
> > If you do not wish to publish your planes under the conditions outlined
> > above, for instance because you don't want to use Gitorious or because
> > your plane is not GPL, then, so Thorsten, you will not be entitled to be
> > listed and tracked centrally (I personally don't agree with that).
> >
> > --
> > regards,
> > ManDay
> >
>
>
> --
> 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
>



-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[George Patterson]

On 19 October 2011 19:29, Cedric Sodhi  wrote:
>
>  https://gitorious.org/flightgear-aircraft

Last night, the discussion came up where the above page is slow to
load, in part it's due to 1.2MB of HTML code, plus the CSS, plus the
any images in use. Not very browser friendly. I hacked together a php
script that will parse a locally stored version of the above page and
display urls to the individual aircaft "projects". On irc, Zorg, Gijs
and perhaps a few others in the #flightgear channel had a poke it and
gave it a nod. Tonight I have improved it, and it now validates as
XHTML 1.0 Strict.

I guess, what essential information do we require from the above
Gitorious resource page. I can add parsing of the each aircraft's
RSS/atom feed, but will need to work on caching first. Currently I
have been periodically fetching the above page and saving it as a
static resource that is then referred to as requested. It should help
those that are on slower connection or pay a high data rate for
traffic. (Or those who are pressed for time. :-) )

The url is http://fgfs.dyndns.info/aircraft.php I haven't linked it
from the front page ofhttp://fgfs.dyndns.info as yet.

Regards


George

> to officially publish your planes as part of the Flightgear project.
>>
>> 2.  Assuming the answers are no, yes, to #1, will all these repositories
>> be centrally located so one can track new or modified ac of interest?
>
> If you do not wish to publish your planes under the conditions outlined
> above, for instance because you don't want to use Gitorious or because
> your plane is not GPL, then, so Thorsten, you will not be entitled to be
> listed and tracked centrally (I personally don't agree with that).
>
> --
> regards,
> ManDay
>

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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[James Turner]

On 19 Oct 2011, at 10:15, Edheldil wrote:

> Is there any written spec on this system? I got frustrated when looking
> for a specific aircraft in fgrun :) and so I suggested something similar
> several days ago on IRC, but it got confused with a/c rating.
> 
> If I understand you correctly, "submit a/c to a catalogue" would mean
> that the information would not be kept in the a/c data - which has its
> pros and cons. I rather think that the metadata should be in the a/c
> itself. Maybe some combination would be the best of all worlds?


http://wiki.flightgear.org/Aircraft_deployment

One thing has changed since I wrote that - I'm probably going to put the 
metadata in a *separate* file from the -set.xml (but still part of the aircraft 
zip / distribution) because it means the system can handle 'non-aircraft' 
packages (eg, shared Instruments) that lack a set file, and it also simplifies 
handling multiple aircraft variants (set files) in one package.

For encoding the metadata, I'm assuming an open-ended scheme, using properties, 
but with a standard ontology defined on the Wiki. I don't really what the 
ontology is, but obviously it will include era (1930s, 1950s), type 
(fixed-wing, glider, heavy), role (general aviation, commercial, bomber, 
fighter, etc), and so on. It could an arbitrary number of rating systems too, 
eg:


1950
fixed-wing-jet
commerical
beta/alpha/production
GPL/freeware/CC-SA-nonsense

5
56
... and so on 



Again, I'm not worry about the onotology until I have enough code written that 
it matters, which will be a few months time, probably.

James


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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Edheldil]

On 10/19/2011 10:36 AM, James Turner wrote:
> On 18 Oct 2011, at 23:21, dave perry wrote:
>
>> 2.  Assuming the answers are no, yes, to #1, will all these repositories 
>> be centrally located so one can track new or modified ac of interest?
>>
>> 3.  Is there any interest in creating repositories by ac class/type?  
>> e.g. historical, military-fighter, military-transport, 
>> civilian-light-ac, airliners, etc.
> Jus tot keep repeating (forever, until I have time to write the code) - don't 
> confuse development and deployment here. The package system I'm working on 
> includes the notion of aircraft catalogs (each an XML feed), listing 
> aircraft. It's up to the catalog maintainer which aircraft he adds to it (or 
> authors he allows to add to the catalog), and it's up to the end-users which 
> catalog(s) they subscribe too.
>
> I'm also trying to force some metadata as part of this, about era / type / 
> usage, so someone could create a '1950s Military' catalog, or alternatively 
> use a 'all-aircraft' catalog, and then do a filter by era / class / license / 
> rating / something else.

Hi,

Is there any written spec on this system? I got frustrated when looking
for a specific aircraft in fgrun :) and so I suggested something similar
several days ago on IRC, but it got confused with a/c rating.

If I understand you correctly, "submit a/c to a catalogue" would mean
that the information would not be kept in the a/c data - which has its
pros and cons. I rather think that the metadata should be in the a/c
itself. Maybe some combination would be the best of all worlds?

I think that each a/c should define:
 - type (SR-71B, MiG-15bis)
 - manufacturer / constructor (e.g. for Soviet planes) - (Grumman, Mikoyan)
 - nicknames and codenames (Delfin / Maya, Avenger)
 - year of first flight or production or some such
 - country of origin
 - role (fighter, airliner)
 - tags (jet, blimp, ..., movable wings, ..., WW2, ) <- a bit fuzzy

Also the liveries/camouflages themselves could/should define
 - country
 - civil or military
 - force / company
 - years from-to

The advantage of user supplied info is that it's independent of a/c
author and can be possibly more up to date, or specify categories not
considered by the author - like a "List of aircraft flying in the
Redflag exercise".

Otoh metadata specified directly by author within a/c data will be
probably more accurate and authoritative, usable by offline tools like
fgrun and less prone to a sudden disappearance.

Any thoughts?

Edheldil


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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[James Turner]

On 18 Oct 2011, at 23:21, dave perry wrote:

> 2.  Assuming the answers are no, yes, to #1, will all these repositories 
> be centrally located so one can track new or modified ac of interest?
> 
> 3.  Is there any interest in creating repositories by ac class/type?  
> e.g. historical, military-fighter, military-transport, 
> civilian-light-ac, airliners, etc.

Jus tot keep repeating (forever, until I have time to write the code) - don't 
confuse development and deployment here. The package system I'm working on 
includes the notion of aircraft catalogs (each an XML feed), listing aircraft. 
It's up to the catalog maintainer which aircraft he adds to it (or authors he 
allows to add to the catalog), and it's up to the end-users which catalog(s) 
they subscribe too.

I'm also trying to force some metadata as part of this, about era / type / 
usage, so someone could create a '1950s Military' catalog, or alternatively use 
a 'all-aircraft' catalog, and then do a filter by era / class / license / 
rating / something else.

James


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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Cedric Sodhi]

On Tue, Oct 18, 2011 at 04:21:47PM -0600, dave perry wrote:
> On 10/18/2011 10:24 AM, Cedric Sodhi wrote:
> > - Development -
> >
> > All aircraft related development shall henceforth be performed on
> > repositories which are maintained by the respective authors.
> >
> > It is planned that most of the repositories on
> >
> > https://gitorious.org/flightgear-aircraft
> >
> > will be dissolved over time and be taken over by the respective authors.
> I don't understand the above (up to - Development -).
> 
> Questions:
> 1.  Are you saying that aircraft developers cannot leave their aircraft in
> 
>   https://gitorious.org/flightgear-aircraft
> 
> indefinitely?  So do we need to set up our own git repository for each 
> ac we maintain?  This raises the knowledge/experience bar required for 
> aircraft developers/maintainers.

As it turns out, the majority of those currently involved in the
discussion on this mailing list (see the thread  which Thorsten started
on AC repositories) seem not to agree with that, although it is indeed
the suggestion which I made.

Instead, Thorsten et al welcome you to use the "infrastructure" of the
official aircraft repository

  https://gitorious.org/flightgear-aircraft

to officially publish your planes as part of the Flightgear project.
> 
> 2.  Assuming the answers are no, yes, to #1, will all these repositories 
> be centrally located so one can track new or modified ac of interest?

If you do not wish to publish your planes under the conditions outlined
above, for instance because you don't want to use Gitorious or because
your plane is not GPL, then, so Thorsten, you will not be entitled to be
listed and tracked centrally (I personally don't agree with that).

-- 
regards,
ManDay

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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[dave perry]

On 10/18/2011 10:24 AM, Cedric Sodhi wrote:
> = IMPORTANT NOTICE TO EVERYONE INVOLVED WITH THE DEVELOPMENT OF FGDATA
> OR AIRPLANES THEREIN =
>
> Thanks to the concentrated effort of all people involved, most notably
> Jorg - who I'd hereby like to thank on behalf of all of us, for spending
> three successive days and nights branching, cloning, filtering,
> splitting and verifying data -
>
> FGDATA has, by today, successfully been split
>
> into individual repositories, comprising the respective planes and
> FGDATA "core" data.
>
> Again:
>
> === !!! ===
> > From the present day on, the development version of FGDATA NO LONGER
> CONTAINS ANY AIRPLANES - You will have to clone a new FGDATA!
> ===
>
> - Airplanes migrated -
>
> All airplanes, hitherto found in $FGDATA/Aircraft/, have been removed
> from that place in the development version of FGDATA and can presently
> be found in their individual repositories at the following URL
>
> https://gitorious.org/flightgear-aircraft
>
> (Disclaimer: HTML page is rather huge)
>
> Please contact either of the following administrators to be given
> priviledges on one of those repositories:
>
> https://gitorious.org/+flightgear-aircraft/memberships
>
> - New FGDATA Core -
>
> FGDATA is now without any aircraft. The only things which remain in
> FGDATA's "Aircraft" directory are general purpose data which are used by
> a bulk of different airplanes. The respective directories of these data
> are
>
> Generic
> Instruments
> Instruments-3d
>
> Despite its name, now a historical relict, NO AIRCRAFT SHALL EVER BE
> PUSHED TO $FGDATA/Aircraft.
>
> The new FGDATA can be found in the official repository at the following
> URL
>
> https://gitorious.org/fg/fgdata-new
>
> The repository is named "fgdata-new" for the time being and the old
> "fgdata" is kept arround, frozen, to have a fallback if anything should
> happen.
>
> Please contact either of the following administrators to be given
> priviledges on the new fgdata repository:
>
> https://gitorious.org/+flightgear-developers/memberships
>
> - Development -
>
> All aircraft related development shall henceforth be performed on
> repositories which are maintained by the respective authors.
>
> It is planned that most of the repositories on
>
> https://gitorious.org/flightgear-aircraft
>
> will be dissolved over time and be taken over by the respective authors.
I don't understand the above (up to - Development -).

Questions:
1.  Are you saying that aircraft developers cannot leave their aircraft in

https://gitorious.org/flightgear-aircraft

indefinitely?  So do we need to set up our own git repository for each 
ac we maintain?  This raises the knowledge/experience bar required for 
aircraft developers/maintainers.

2.  Assuming the answers are no, yes, to #1, will all these repositories 
be centrally located so one can track new or modified ac of interest?

3.  Is there any interest in creating repositories by ac class/type?  
e.g. historical, military-fighter, military-transport, 
civilian-light-ac, airliners, etc.

By the way, thanks for all the work on this and also for this helpful 
note of documentation!


> On a sidenote, some of those repositories are already superflous because
> development has long been moved somewhere else. These are the first
> repositories which will be decomissioned.
>
> Only repositories for which no author is found will remain stored
> centrally.
>
> Development on the rest of FGDATA will continue in the new FGDATA
> repository until further notice, possibly until more components are
> migrated, as it has been brought forward.
>
> https://gitorious.org/fg/fgdata-new
>
> - Usage -
>
> To keep up with the new structure, commit all your local changes on your
> old FGDATA and move its directory out of the way (for example by
> renaming it).
>
> $ cd fgdata
> $ git commit -a
> $ cd ..
> $ mv fgdata fgdata-OLD
>
> Next, clone the new repository of FGDATA
>
> $ git clone git://gitorious.org/fg/fgdata-new.git fgdata
>
> IF YOU HAD LOCAL CHANGES, you will need to reapply these changes. This
> could be a little adventurous, because these are actually two separate
> repositories and you can't just rebase. You'll have to prepare the
> patches and apply them over. If you need help with this, check on the
> official IRC channel at
>
> irc://irc.flightgear.org/flightgear
>
> for help.
>
> Now you have the new core FGDATA (possibly with your own changes, if you
> followed the hint above).
>
> In the coming days, we will provide you with scripts which conveniently
> fetch your personal selection of aircrafts; until then you will have to
> manually obtain them from the repositories. Here is how:
>
> DO NOT PUT THE AIRCRAFTS INTO THE NEW FGDATA! Instead, create a new
> directory somewhere completely different, say,
>
> /usr/local/flightgear/aircrafts
>
> and store the aircrafts in there (for example clone them from their
> repositories). If you specify that directory on the command line to
> Fligh

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Stuart Buchanan]

On Tue, Oct 18, 2011 at 5:33 PM, Stuart Buchanan wrote:
> On Tue, Oct 18, 2011 at 5:24 PM, Cedric Sodhi wrote:
>> NOTE: Some aircrafts explicitly require to be inside of FGDATA, because
>> they are programmed to expect their own data files to be found in
>> FGDATA. These airplanes will give you an error if you put them outside
>> of FGDATA (as you must).
>>
>> In order to solve this, you can symbolically link them individually into
>> FGDATA (Git is already told to ignore those links).
>>
>> $ ln -s /usr/local/flightgear/aircrafts/c172p /path/to/fgdata/Aircraft/
>>
>> ===
>
> Surely that would be a bug in the aircraft that should be fixed?

... and it has now been. You should now be able to use the c172p outside
of the fgdata/ directory.

-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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Torsten Dreyer]

Am 18.10.2011 19:45, schrieb Gijs de Rooy:
>
>  > Torsten wrote:
>  > git clone g...@gitorious.org:fg/fgdata-new data
>
> Make sure you don't forget .git. Use this:
>
> git clone g...@gitorious.org:fg/fgdata-new.git
touche - I'm getting too old for this ;-)

It works now, thanks!

Torsten

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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Gijs de Rooy]

> Torsten wrote:
> git clone g...@gitorious.org:fg/fgdata-new data

Make sure you don't forget .git. Use this: git clone 
g...@gitorious.org:fg/fgdata-new.git data

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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Torsten Dreyer]

Am 18.10.2011 19:30, schrieb Gijs de Rooy:
>  > Torsten wrote:
>  > For some reason, there seems to be no ssh url available for fgdata-new
>  > and the aircraft projects?
>
> There is. g...@gitorious.org:fg/fgdata-new.git
>  and for the aircraft it's like
> g...@gitorious.org:flightgear-aircraft/c172p.git
>  (all aircraft
> repos simply match
> the respective aircraft's directory name).
>
> You mean you don't see it at Gitorious? Works fine here on IE9 and FF7...
Sorry, I was referring to the clone/push url. Surely the gitorious web 
site works as expected.

The ssh url is required (iirc) to access gitorious with the public key 
as a commiter.

git clone g...@gitorious.org:fg/fgdata-new data

fails with

Cloning into data...

== Gitorious: ==
Access denied or bad command


fatal: The remote end hung up unexpectedly

before I can enter my private key.

Torsten

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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Gijs de Rooy]

 > Torsten wrote:> For some reason, there seems to be no ssh url available for 
 > fgdata-new 
> and the aircraft projects? There is. g...@gitorious.org:fg/fgdata-new.git and 
> for the aircraft it's like
g...@gitorious.org:flightgear-aircraft/c172p.git (all aircraft repos simply 
match
the respective aircraft's directory name).

You mean you don't see it at Gitorious? Works fine here on IE9 and FF7... 
Cheers,
Gijs
  --
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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Torsten Dreyer]

Am 18.10.2011 18:24, schrieb Cedric Sodhi:
> Next, clone the new repository of FGDATA
>
> $ git clone git://gitorious.org/fg/fgdata-new.git fgdata
For some reason, there seems to be no ssh url available for fgdata-new 
and the aircraft projects?

Torsten

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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Cedric Sodhi]

On Tue, Oct 18, 2011 at 05:33:23PM +0100, Stuart Buchanan wrote:
> On Tue, Oct 18, 2011 at 5:24 PM, Cedric Sodhi wrote:
> > NOTE: Some aircrafts explicitly require to be inside of FGDATA, because
> > they are programmed to expect their own data files to be found in
> > FGDATA. These airplanes will give you an error if you put them outside
> > of FGDATA (as you must).
> >
> > In order to solve this, you can symbolically link them individually into
> > FGDATA (Git is already told to ignore those links).
> >
> > $ ln -s /usr/local/flightgear/aircrafts/c172p /path/to/fgdata/Aircraft/
> >
> > ===
> 
> Surely that would be a bug in the aircraft that should be fixed?
> 
Indeed.

> Also, IIRC there are a number of aircraft that have dependencies on other
> aircraft. Presumably this would be a good opportunity to fix those as well?
> 
Agreed.

ManDay

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

Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split

[Stuart Buchanan]

Good work guys. Thanks.

On Tue, Oct 18, 2011 at 5:24 PM, Cedric Sodhi wrote:
> NOTE: Some aircrafts explicitly require to be inside of FGDATA, because
> they are programmed to expect their own data files to be found in
> FGDATA. These airplanes will give you an error if you put them outside
> of FGDATA (as you must).
>
> In order to solve this, you can symbolically link them individually into
> FGDATA (Git is already told to ignore those links).
>
> $ ln -s /usr/local/flightgear/aircrafts/c172p /path/to/fgdata/Aircraft/
>
> ===

Surely that would be a bug in the aircraft that should be fixed?

Also, IIRC there are a number of aircraft that have dependencies on other
aircraft. Presumably this would be a good opportunity to fix those as well?

-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