On Thu, 20 Oct 2011 00:10:29 +0200
ThorstenB wrote:
> We are really sorry for any inconvenience and misunderstandings this
> further change may cause. But now, as we have everybody's attention on
> the subject, we're looking forward to many people testing the proposed
> changes. We also invite
Hi FlightGear,
there was little input on the fgdata split and few people speaking up
when things were started. We do see a lot of responses now - many being
in favor of the change, but also concerns about remaining issues.
Indeed, setting up the new repo isn't as simple as it seemed initially,
On Wed, Oct 19, 2011 at 04:55:28PM -0400, Jacob Burbach wrote:
> On Wed, Oct 19, 2011 at 3:49 PM, Martin Spott wrote:
> > 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
> >> p
On Wed, Oct 19, 2011 at 3:49 PM, Martin Spott wrote:
> 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.
>
> I wonder by which justification you pretend
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
Hello everybody,
I apologize if my initial mail did not describe it clearly enough. I
hope this mail helps with all of your questions:
Before you go on a disclaimer ahead: There has been a minor (not just in
a manner of speaking) complication with the new FGDATA repository, so
there is now a new-
Curtis Olson wrote:
> We are committed to git, I'm not suggesting otherwise, but the entire binary
> history of the data tree is pushing 10Gb.
I'm not sure if we're talking about the same item, but the "bare"
repository of the entire 'fgdata' in its current state should be at
approx. 4 GByte or e
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
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.
I wonder by which justification you pretend to speak for a group whose
common understanding you never bothe
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 pre
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 t
My main point (or thought) is just that if we are going to push forward with
this split, then we need to go the whole way and make it work reasonably for
everyone. The people pushing this and doing the initial work, can't just
take it half way and then leave it because their personal concerns are
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
Martin says :
> Yes, revert the dissection of 'fgdata' until a practical solution is in
> place which doesn't require lots of people to waste extra time just to
> achieve the previous state which simply works for them."
Yes ! I agree.
Place all the planes in a second deposit, why not. But hundre
I actually lost track of who is doing what in the splitting of fgdata
but there is a tremendous response pointing out issues related to the
split. I want to express support for the splitting team.
I support the split if only for the reason that aircraft maintainers
will get commit rights to the
Important message for anyone that uses Git:
DO NOT CLONE FGDATA-NEW for the moment.
That repository was meant for testing-purpose only. In fact we found out that
there were
still aircraft-commits in there and Jorg is currently pushing a new (testing!)
repository.
The old fgdata is still up (
On Wed, Oct 19, 2011 at 11:55 AM, Martin Spott wrote:
> > A super module sounds ideal if that's doable in git. Looking forward to
> it!
>
> Gitorious will be pleased if everybody starts pulling everything from
> scratch - and developers will be pleased by Gitorious' performance when
> everybody s
Curtis Olson wrote:
> A super module sounds ideal if that's doable in git. Looking forward to it!
Gitorious will be pleased if everybody starts pulling everything from
scratch - and developers will be pleased by Gitorious' performance when
everybody starts pulling everything from scratch.
Previo
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 alrea
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
Cedric Sodhi wrote:
> On Wed, Oct 19, 2011 at 10:28:33AM +0300, thorsten.i.r...@jyu.fi wrote:
>> You seem to entertain the idea of a free lunch - get the goodies which
>> being part of the Flightgear project has to offer, but keeping the freedom
>> to do what you want. That may be a positive creat
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
pl
On Wed, Oct 19, 2011 at 11:03 AM, Martin Spott wrote:
> Curtis Olson wrote:
>
> > Anyone have any good ideas?
>
> Yes, revert the dissection of 'fgdata' until a practical solution is in
> place which doesn't require lots of people to waste extra time just to
> achieve the previous state which simp
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 equ
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
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'
Curtis Olson wrote:
> Anyone have any good ideas?
Yes, revert the dissection of 'fgdata' until a practical solution is in
place which doesn't require lots of people to waste extra time just to
achieve the previous state which simply works for them.
Spending some thoughts on how to compensate the
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 ge
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
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 p
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
> every
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,
Alessa
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
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 ph
Pulled c172p, senecaii, f16, citationx, citation-bravo.
c172p, f16 and citationx work fine.
senecaii and citation-bravo show random splash screens
during initialization and start with no cockpit or external view model
to be seen.
Symlinking the directories into $FG_ROOT/fgdata(NEW)/Aircraft makes n
I missed a day being offline yesterday, and now I see there's no way I'm
going to be able to read every message in this thread word for word and
catch (and acknowledge) every nuance of every point being made. So let me
just say what I'm thinking, which probably echos the sentiments of the other
lo
Im still not sleeping , so thanks for clearing things up. I for one
like the aircraft split , just awaiting the require permissions.Will
be nice to get my own work up to date without risking breaking
something elsewhere in fgdata .
Cheers
On Wed, Oct 19, 2011 at 5:42 AM, James Turner wrote:
>
> O
On 19 Oct 2011, at 12:27, thorsten.i.r...@jyu.fi wrote:
> Most of us are adult people, and most of the time we are able to act like
> civilized people, i.e. we can work out things in a reasonable way without
> invoking the law and waving license around. There are some rules for
> emergency cases
> I would have happily continued to
> maintain/upgrade them , and I,m hoping this change might make things
> easier ... but if Im now being told that my work can be changed
> without any notice to me , that i have no say over my own
> contributions, then I wont waste any more time here.
I think th
On 19 Oct 2011, at 11:53, syd adams wrote:
> while the central repository is a fine
> idea , after the move to git , I lost any commit rights to my own
> work, so after a time i gave up on the idea of maintaining them and
> started my own repositories . I would have happily continued to
> mainta
Just to add my own 2 cents while the central repository is a fine
idea , after the move to git , I lost any commit rights to my own
work, so after a time i gave up on the idea of maintaining them and
started my own repositories . I would have happily continued to
maintain/upgrade them , and I,
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, "submi
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 ho
> This is exactly the "deal" which I think you are rather hurting yourself
> with. I allege, that contributers of planes are not looking to make a
> deal with you, at least I would not.
First, you're talking to the wrong person. I'm not Thorsten B, I am
Thorsten R, and I do not represent the core
I'd loke to note that I listed pros and cons at the wiki. Some people
contributed, some didn't.
Rather than turning this into a me/we-vs-you/they fight I'd like to see that
people sit down
and add their thoughts (and facts) to the wiki. Makes it easier/healthier for
all of us ;)
http://wiki.fl
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
Hello again,
I would like to add that I agree, that making any implication about
whether authors *should* migrate their planes to their own repos, was
wrong. There is of course no reason to turn them away, if only, there is
a reason to request them to be part of the central Gitorious-Account (as
i
On Wed, Oct 19, 2011 at 10:28:33AM +0300, thorsten.i.r...@jyu.fi wrote:
> > As for the topic brought up here, I sense a bit of sentimentalism
> > clouding the technical judgment of some.
> (...)
> > In a positive creative development structure you leave the contributors
> > their freedom.
> >
> > "
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-f
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
> As for the topic brought up here, I sense a bit of sentimentalism
> clouding the technical judgment of some.
(...)
> In a positive creative development structure you leave the contributors
> their freedom.
>
> "Contribute your planes!" rather than "Come to Gitorious, ask for our
> permission to g
There is a fault somewhere in Flightgear/Simgear cmake which makes this
happen from time to time.
Here is a quick fix.
Step 12a
If you get the error
Could NOT find SimGear (missing: SIMGEAR_VERSION_OK) (Required is at least
version "2.5.0")
Press "Add Entry"
In the window that comes up set Name
52 matches
Mail list logo
