Board index FlightGear Support 3rd Party Repositories

Cloning fgdata with GIT submodules

Re: Cloning fgdata with GIT submodules

Postby Thorsten » Tue Mar 24, 2015 9:15 am

Thorsten, you are missing the point. It is not a competition and I don't think Israel is doing this as a competition.


Hm, why do we read 'scores' then? I specifically quoted the evidence for the competition theme - did you not read that? I think you're kidding yourself. If this weren't a competition, folks could just quietly use whatever repo they use and commit to SVN before a release.

Yet I see shouting an attention-grabbing at every corner.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Cloning fgdata with GIT submodules

Postby wlbragg » Tue Mar 24, 2015 10:21 am

But no - that's not good enough for you people. You feel so righteous that you want to win this.

"righteous", where did that come from? "win this", seriously, no I want it to be done right. I want it to be fair and OPEN. It has nothing to do with winning. I disagree with the choices being made.
If I just thought this was "sub optimal for some" I would have dropped this long ago. If you think that I think this is a competition and about winning then that is on you, you don't know me at all!

For me this is a disagreement in how things are being handled and after disseminating every available argument and counter argument I am left with my opinion.

I think it is a huge mistake to throw away the history of this project. Israel has saved it.
I can see that fgmembers is attracting or allowing more contributors. Not a competition, just fact, WHY? That is something the core needs to think long and hard about.
I don't really care if it is Sourceforge or Github, SVN or GIT, even though I prefer the latter, as long as it is safe, having both gives us a backup.
fgmembers is just a collection.

That's it, everything else is superfluous to me.

Quite frankly I am hoping it works the other way around, that the "official" becomes a stagnant collection of has-been's. Oh, it kind of looks like it already has.

That statement is really the only thing I would like to take back because I really don't feel that way at all. I would be thrilled if the "official" repo, even on SVN/Sourceforge, was to thrive and be the place to link to for all my aircraft.
But I can't get past the deleting of the history and the type of censorship that is currently in place there.
I won't support that.

Look at you. You're making this into a kind of competition - who gets more commits (or likes or whatever). Seriously? I think you missed the point.

No that is the point, WHY, why is it appear to be drawing development? Why isn't the "official' repo. You want me to jump on board with a system that has been turning away or locking out developers. You want me to jump on board with a repo that has been stripped of everything that made it worth something.
All it is now is a storefront and that is fine if that is what it is meant to be, so why all the fuss over this organized development area anyway. It's not taking away or deleting anything from the project, in fact it saved years of data and brought together massive amounts of previously separate projects.

It really is just like you said
Aircraft developers have always had their own GIT reporitories for development and then pushed status updates to FGData periodically and before a release. You could simply do whatever you like and continue that mode of operation - use any tools you like and update FGAddon regularly.

I think this still works. If you really read and tried to understand what I was saying instead of just forming the opinion that I want to win. You would have seen that I think it would be better if this new sandbox area, that seems to be successful and what quite a few developers are attracted to, could be used and leveraged for the benefit of the project instead of it being this big negative. After all it is just a work area. The same developers that use it have the same options they always have had, the POTENTIAL option to merge or contribute to the official repo. It's a matter of whether the "official" repo gatekeepers will allow it.

Israel has made every attempt to cooperate and assist this project. I was trying to do the same, for the most part, with my last post. I should have know better than to try to get the two camps to work together. All I got for my efforts was a character attack.

I hate the friction, I don't like the disruption, but I'm not a sheep.

Would you really want me to join that competition? Try to make new effects only available for users of FGAddon? Denying support to everyone who doesn't use the 'official' repository for development? The only reason why you appear to 'win' this is that the core developers don't try to win.

I don't quite follow the logic here. No one is doing anything like this, just the opposite. But to answer your question, no of course I wouldn't. I can't imagine you in that light. But I don't get the analogy or connection.
I don't think I am appearing to win anything, I certainly don't feel like I am. I feel like I am alienating myself for my beliefs.
But I can honestly say that the only good feeling and positive thing I got out of this entire affair, is to know that the history is saved for now and I have my FG pointing to one repo that has all the aircraft I used to have to piece and patch together. That is a real plus for me.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7610
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Cloning fgdata with GIT submodules

Postby IAHM-COL » Tue Mar 24, 2015 3:31 pm

Subject: FlightGear GUI hell: PUI, Canvas GUI, Mongoose, Qt5 ??
Torsten wrote:Because There is more than one way to do it..
How many FDM do we have in FlightGear?
How many weather systems do we have?
How many web browsers, e-mail clients, operating systems are on the market?
How many different types of chocolate can you coose from in an average supermarket?
And why is this so? Because sometimes it's a matter of taste, sometimes it's because people learn and products evolve over time.

For me, the freedom of choice is heaven, not hell. Not only when looking for chocolate in a supermarket.

Torsten
If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it? Probably not, because if they don’t recognise their freedoms, they’ll let their freedoms fall
User avatar
IAHM-COL
Retired
 
Posts: 4057
Joined: Wed Aug 08, 2012 6:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: Cloning fgdata with GIT submodules

Postby IAHM-COL » Tue Mar 24, 2015 4:17 pm

Hi everyone

It came to me as a big surprise that this thread has evolved overnight.
Specially the directions it has evolved towards. A personal handwrestling.

I ve read somewhere that Torsten and Thorsten had made their last comments on this topic, and apparently not so. That was a surprise.

Not so much of a surprise. That once either decide to make an opinion on the matter, the reasonings and arguments all go around personal battles, or competitions of some sort. If you guys want a "competition", you are invited to the USA Tour events.

When I proposed FGMEMBERs area, both here in the forum and in the devel-list, I did so as an offering of a development system for aircraft that in my opinion is much superior to whatever SVN=git hybrid you guys have going with SVN. Not only in having lost all history of the commit logs, but also because it helps making FGDATA modular, simple to manage, convenient for testing and development. I offered it not as "an alternative" to the official branch. But as a replacement. I never enlisted in a "competition" of two platforms.

The rejection of the core developers was not very well sustained, and in Curtis' own words, it just came as abrupt and dismissive to me. It comes on the form of:

Thorsten wrote in Tue Mar 24, 2015 2:40 pm:No. Why would I? Do you think I rigged the screenshot? Or do you think I need to prove anything to you?


And, yes, I did think so. When it came to the unbending rejection of a well-elaborated offer, and what I saw as a clear step up for a development sandbox for aircraft, it appear to me that the core developers rejection of the gift was expected to be explained in better terms that

* because we already did so.

Fortunately in my favor, when I made the proposal, I did with a finished product. More frequently than not, and idea, (just idea), needs to be given a chance of, and see if it develops. But I did not come with just an idea, but a completed product. When you said you already did so, interestingly I also have done so.

Durk, claimed a very interesting point. That for a proposal being considered seriously, a cost-benefit analysis needed to be run to see not only how it benefits the project (pros and cons), but also, how hard was it to implement.

I couldnt' agree more, but this cost-benefit analysis was never done (openly if so in the devel list), and every word mentioned at this respect was faced with strong opinions on some developers, and blatant unarguable short dismissals, without clear explanations (like "Just. Stop. Plonk. etc")

Who in the core developers that participated in the definite and irrevocable choice of FGADDON know the benefits and cons of the FGMEMBERs area? and who in that group knows what it takes, stepwise, to implement FGMEMBERs as the official alternative? and who in that group know what does fligthgear looses if FGMEMBERs is implemented as the official alternative?

Because I think this is where the "win" is. And you guys take all the win.

Once again.
When I offered FGMEMBERs to the Flightgear core. I did not expected a personal win. But a project win. I would be happy to have given a grain of sand in the Fligthgear development cosmos, by creating 600 individual repos. And rescue all the git-previous history, and provide an excellent platform to open aircraft development, in a way that can be welcoming to both old and new contributors.

But besides, that personal satisfaction of having been of help to a project I love, I did not expect any other gain.
Not even the chocolate boxes that Torsten Jokingly claimed to give repo's commit write access.

[and I also love chocolate]

For now, having diverting aircraft development repos is an alternative solution that provides us means for decentralize aircraft development, and prevent contributors of being isolated or limited. (Yes, we are not talking here about the selected group of 18).
Furthermore, what you still don't seem to understand is the consequences of me automatizing a rebasing of FGADDon to the FGMEMBERs area. Does it look like a competition to you?
When I rebase the FGADDon area, I already have every commit of yours. One by one. So any commit or contribution on FGMEMBERS not transferred to official, means we will have more contributions. Unavoidably. If the balance comes to zero, it would mean that no new commits occur in FGMEMBERS but only those that I automatically rebased from FGADDon. Not a competition there. While I rebase every FGADDon commit. How do you plan, if so, to have "effects" only available to FGAddon? That's quite a big statement. and I want to do every on my hands to prevent such occur.

But every commit that FGMEMBER has that FGAddon does not makes FGMEMBERs more complete. Not only we included at least 60 GPL planes that never gained "official" status but also we have "on-house" modifications of those official. Plus additional versions of aircraft isolated in branches or additional repos.

Basically, because I do not try to alienate any voice, and I just encourage contributors to develop. And I foster shared development.

And for starters, yes, I do believe the Core developers are alienating. For starters, they alienated me.

Yours, Sincerely
IHCOL
If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it? Probably not, because if they don’t recognise their freedoms, they’ll let their freedoms fall
User avatar
IAHM-COL
Retired
 
Posts: 4057
Joined: Wed Aug 08, 2012 6:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: Cloning fgdata with GIT submodules

Postby Thorsten » Tue Mar 24, 2015 4:22 pm

And for starters, yes, I do believe the Core developers are alienating. For starters, they alienated me.


I think you have cause and effect reversed.

And there's a difference between infrastructure and in-sim options. And doing your own repo is one thing - ranting how everyone else wronged you and how FG developers take everyone's freedom away based on essentially nothing is another.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Cloning fgdata with GIT submodules

Postby Torsten » Tue Mar 24, 2015 4:28 pm

I did not comment on your project. And I will not. We had our discussion, exchanged arguments and do not agree.
I can live with that.
What I commented on was the accusation of censorship and locking out contributors. I can't accept that.

Torsten
flightgear.org - where development happens.
User avatar
Torsten
 
Posts: 648
Joined: Fri Feb 01, 2008 10:22 pm
Location: near Hamburg, Germany
Callsign: offline
Version: next
OS: Linux

Re: Cloning fgdata with GIT submodules

Postby Jabberwocky » Tue Mar 24, 2015 5:40 pm

Okay, the "competition thing"

"competition" is like Olympic games. Someone wins, but in the end everybody returns home and has some nice memories about the event.
This is not "competition". This is an alternative created after someone had the idea to play "gate keeper" in an open source project. Which led to two different "services" catering to the users who fly those aircraft. And a flight sim stands and falls with aircraft. Trees on the ground, nice water shaders, pretty buildings, that is all great stuff, but nobody will start FG if he has no aircraft. End of the story.
So, one service has some outdated planes which, despite the argument on the dev-list that they are guaranteed to work, don't work. The other one had working planes and, since the "gate keeper" managed to get into struggles with almost all of the heavy weight plane developers we have (Helijah for example comes to mind) the "other one" aka FGMEMBERS has the latest aircraft and I doubt, that any of those who were angered by the "gate keeper" will bother too much to make additional uploads to SVN. Personally I don't care. My work is available via FGMEMBERS and distributed widely enough. And as far as I can see, most other aircraft developers act as if they see it similar.
So to make the point clear ... this is no competition. If at all, it is the slaughter of something, someone has created with himself as single gate keeper and which, for that very reason didn't work out. On the other hand, FGMEMBERS is run by a whole group. If IAHM-COL gets the Madfagascan Flu (or whatever nasty goes around), others can handle all the merges as well. And with every day, IAHM-COL drills us all more, how to handle things (personally I am a bit slow in the Git uptake though, he fights hard to get me into this business). But point is, SVN is the solution depending on one ... FGMEMBERS is on a good way to become a real team thing.
So, jsut for definition purposes: A "competition" would be some kind of race between two or more competitors with at least aboutish same chances. This is NOT a competition.
Jabberwocky
Retired
 
Posts: 1316
Joined: Sat Mar 22, 2014 8:36 pm
Callsign: JWOCKY
Version: 3.0.0
OS: Ubuntu 14.04

Re: Cloning fgdata with GIT submodules

Postby Hooray » Tue Mar 24, 2015 5:49 pm

Thorsten's got a point about the differences between infrastructure and in-sim features - having many of the latter may "confuse" people, while having too many options of the former (think wikis, forums, mailing lists, bug trackers, build servers or forks) will just add to help divide the community, which isn't unlike features excluding others - which touches on the whole Rembrandt vs. ALS debate, where people are obviously also concerned that one being vital (ALS) may contribute to the "killing" of the less vital one (Rembrandt).
Ultimately, nobody likes the idea of seeing their spare time spent working on something going wasted because some "core" of contributors decides that something is a dead-end, which is where all the emotions are coming from.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Cloning fgdata with GIT submodules

Postby wkitty42 » Tue Mar 24, 2015 5:52 pm

not wanting to extend this or cause any further rife, i want to ask a question that no one has asked or explained...

why is the (ancient?) history of the craft so important? what is it in there that needs to be kept? secret messages? a stash of old ascii pr0n? will someone die because it is lost? i don't understand what all the fuss is about...

the craft in the new FGADDON have been or are being updated to work with the current/upcoming fgfs... i've been watching a lot of them gaining the new effects capabilities as they've been added and FGADDON has been being updated... those old versions won't work with the new fgfs without creating errors and locking up the sim (eg: the p51d was recently fixed [again] to handle a problem that used to be allowed but is not any more)... anyway, back to the question... why is this history so important? no one has clearly and simply stated this... it should be able to be said in less then 250 words... less than 100 would be even better...

FWIW: as another one of the "new guys", i cloned the gitoriuos repo over several days... i had to use the torrent method but i was able to get it... i know that i'm not the only one and there's still time for others to clone it, too... the history is still around and available... it isn't lost completely...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9165
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 22.04

Re: Cloning fgdata with GIT submodules

Postby legoboyvdlp » Tue Mar 24, 2015 6:35 pm

Oh, stop it. This bickering about a simple issue. It's just annoying.

There is room for both in flightgear, as long as they remain parallel.
It is a matter of buying 5 mars bars or 1 multi 5 pack!
Why do the core developers have a prejudice? Is flightgear not supposed to be a community effort? Some of you, no names mentioned, seem to think that nothing made by others is good, and their decision is the best.

If you compare sourceforge and github, it is like cadburys and galaxy bars. Let the user choose!
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: Cloning fgdata with GIT submodules

Postby Thorsten » Tue Mar 24, 2015 7:22 pm

There is room for both in flightgear, as long as they remain parallel.


The devil is, as explained on the mailing list, in the detail. FGAddon is supposed to be in sync with current GIT, private hangars sometimes are, sometimes not. The difference is gatekeeping.

When I get a bug report for a plane (usually rendering/effect related), I want a well-defined state so that I can look at that precise state of the plane and know it is supposed to be in sync with the current devel version of the core. I drop bug reports for non-official hangars immediately because most of them are out of sync problems and I can't get a good state of the aircraft. And I don't want to check five different repositories in parallel and establish the state of all aircraft in there.

So if there is a rendering problem with a plane but that plane works fine for me in FGAddon, that's basically the end of my involvement. Not because I am mean, but because I have tried to track rendering problems for private hangars in the past and it's just too much effort.

That's why splitting infrastructure is bad, whereas several options of weather, GUI etc. are not. I know it's a subtle point, and hardly visible from the aircraft maintainer's perspective, but if you need to maintain the infrastructure the aircraft definitions run in, it starts to matter.

So to make the point clear ... this is no competition. If at all, it is the slaughter of something, someone has created with himself as single gate keeper and which, for that very reason didn't work out.


I suggest to look a bit into how the FG infrastructure is run and who has commit rights to FGAddon before spreading such nonsense or turning to military metaphors.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Cloning fgdata with GIT submodules

Postby sanhozay » Tue Mar 24, 2015 7:45 pm

wkitty42 wrote in Tue Mar 24, 2015 5:52 pm:why is this history so important?

An example:

A recent change was made to the route manager that redefined how leg data is attached to a waypoint. This means that aircraft now need to get information about a leg from the waypoint they are flying to rather than the waypoint they are flying from. An aircraft is easily updated so that it is compatible with the latest route manager, but a user running an older Flightgear version who downloads the latest aircraft may get breakages. If this user had access to the history of aircraft changes, they would be able to download the aircraft as it was when their version of Flightgear was released and run that aircraft until they were ready to upgrade.
sanhozay
 
Posts: 1207
Joined: Thu Dec 26, 2013 12:57 pm
Location: EGNM
Callsign: G-SHOZ
Version: Git
OS: Ubuntu 16.04

Re: Cloning fgdata with GIT submodules

Postby Thorsten » Tue Mar 24, 2015 7:47 pm

For which we have a download page where most users (who as a rule can't pick past history of a GIT repo) get their planes...
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Cloning fgdata with GIT submodules

Postby wkitty42 » Tue Mar 24, 2015 7:52 pm

that's my understanding, too, thorsten... why would someone running an older fgfs even be trying to use newer/updated craft from a newer fgfs? that doesn't make any sense... especially for the average joe user... developers, on the other hand? well... ;)
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9165
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 22.04

Re: Cloning fgdata with GIT submodules

Postby wlbragg » Tue Mar 24, 2015 7:59 pm

FGAddon is supposed to be in sync with current GIT

For your purposes I get this, it's the first thing that has made much sense to me. That is why I think it even more important to sync up the two repos and let FGAddon grab what they want to call official. I don't need them to make that decision for me, I'll use fgmembers.

developers, on the other hand?

This is what I am concerned with, average users are not who this repo mess concerns, and we all know how to get around in these systems.

wkitty42 wrote in Tue Mar 24, 2015 10:52 am:why is this history so important?

We don't know exactly what all is in the history. We do know that it has aircraft that are no longer "current" that might some day be resurrected. We know that with the history intact we can regress in time for multiple purposes, including troubleshooting. It's like real life, we should and can learn from history!
Depending on some random users to secure that rich history is not the correct route. Even if the "project" had archived it and made it available it wouldn't be much of a problem. But to just throw it in the trash, incomprehensible.

I've said everything I really wanted to put out there, not having said that much, so that is another reason why I am a little taken aback by the attitude and appearance of hostility directed towards me. I tried to stay out of this mostly but felt the necessity to back someone who was getting stampeded and bullied to death. Someone that made my life easier with an organized data source complete with everything it should contain. I didn't really jump in until it looked like it might be beaten out of existence, I am trying to avoid that.

The only other thing I have to say, (I thought I already did but it was gone when I looked at this thread again), Torsten, you know what I am talking about. I don't think my reply ever made it to the board and yours is gone.
But what I said was basically, it had nothing to do with you or your administration of anything. It was one incident, the "dash" incident. I didn't agree with it, it sets a bad precedence.

One more time, if you really read my post, a page back or so, it was an attempt to help get two sides to try to come together and make it better. It diverged a bit in anger and frustration, since retracted that part of it and I am finished. I hope my point in all of this is clear and understood, agree with it or not, now I simply want to move forward.

I support the new repo. I want it to be accepted and in sync with the "official" position of FG. I support the FG project.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7610
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

PreviousNext

Return to 3rd Party Repositories

Who is online

Users browsing this forum: No registered users and 2 guests