Syncing with the FlightGear core.

[edward-dauvergne]

Carry on from @onox's https://github.com/c172p-team/c172p-detailed/issues/1114#issuecomment-392185601, with back referencing:

onox wrote:

I wrote:

onox wrote:

I wrote: Or the alternative that James suggested and I also elaborated on of having a copy of the git repository mirrored at SourceForge and the aircraft removed from FGData. I.e. equivalent to fork #36, as there are currently 35 forks of the repository on GitHub, but used as a read-only mirror hosted alongside the FlightGear core infrastructure and used in Torsten's automated bundling procedure. This is a very, very easy solution that removes a lot of the current disjoint between the c172p-detailed team and the FG core.

@edward-dauvergne If you can fully automate this, then I've no problems with it.

Should this be a separate issue? This needs some structural organisation on this side. But it will benefit all parties.

Yes, please open a new issue. What kind of organization are you talking about?

For such a system, the c172p-detailed team would be fully in charge of keeping the aircraft in sync. It would require one or more team members having a SourceForge account, adding the c172p SF repository as a remote with a name such as 'sf', getting commit access (asking on the FlightGear mailing list), and then using 'git push sf' at regular intervals.

If the c172-detailed team decides that git repository mirror is the best way to go, then this should be mentioned on the mailing list so the core developers with admin access to the FlightGear infrastructure can create a blank 'c172p' git repository. Then just set it as a remote and push. You will also need to coordinate with Torsten to make sure that the tagging and branching names perfectly match his automated release scripts.

[gilbertohasnofb]

@onox @wlbragg What do you guys think about the best route for future syncs?

[onox]

That's not really automated. I prefer something like creating a webhook which can send a HTTP POST to some URL.

[gilbertohasnofb]

@onox would you be able to set that up then?

[edward-dauvergne]

The idea of the git mirror is really to provide the c172p team with the simplest possible path to self-control. You simply set up a remote called say 'sf', and run 'git push sf', and 'git push sf --tags' (for those with a SourceForge (SF) account).

For a webhook, that probably won't work as you need a true SF account to push to a SF repository (just as with a GitHub repository). That is similar to git post-commit hook script, in that that won't work either (and unfortunately GitHub does not allow for any true git hook scripts to be installed). There are other ways to automate this though:

1. Cron job: For example to run this every hour:

0 * * * * cd /path/to/c172p-detailed/git/repository && git push sf &> /dev/null && git push sf --tags &> /dev/null

2. Simultaneous push to all remotes using a git alias. Add the following to ~/.gitconfig:

[alias]
        pushremotes = !git remote | xargs -L1 git push

Then instead of git push, run:

git pushremotes
git pushremotes --tags

The changes will be pushed here and to the SF remote.

[edward-dauvergne]

I forgot to mention, the alternative suggestion of granting team members FGData commit access and then you manually synchronise the FGData Aircraft/c172p/ directory with this git repository is a lot more work than syncing a git mirror. That is what @stuartbuchanan normally has to do for you for each release.

[edward-dauvergne]

Another way to set the git alias would be:

git config --global alias.pushremotes '!git remote | xargs -L1 git push'

This of course only works on GNU/Linux and Mac OS X operating systems. MS Windows scripting would require quite a different command.

[wlbragg]

@gilbertohasnofb wrote

What do you guys think about the best route for future syncs?

Unfortunately I have little experience with any of this technology so I have to defer to @onox. My only feedback is it should be as simple to understand as it is to activate otherwise it will still be in the domain of one person. Also we have a really good system of checks and balances going here. I really don't envision anyone other than @onox pushing the final button when ready other than in an emergency situation when he is not available, then it should fall to one of the other team members of long standing that has some cross training of the system being used.

You know what, "cross training" would have prevented this entire discussion!

[onox]

For having a fully automated setup that you push to yourselves (i.e. a git mirror on SourceForge), you'll probably need to coordinate with Torsten on the mailing list on how to do this. Maybe his script should scan for tags, decreasing the version number until a matching tag is found. Or maybe he would auto-create any missing tags from your release branch. You'll have to discuss the details with him.

@edward-dauvergne I don't think we need committer access to anything on SF. Wouldn't it be easier if Torsten modifies that pre-release script you're talking about to just use the Github API and then do a git shallow clone and then rsync the content to fgdata?

You can get a list of branches and their commit sha's at https://api.github.com/repos/c172p-team/c172p/branches If you record the commit sha in the commit in fgdata, you can easily check if you need to clone by comparing the sha in the JSON response with the recorded sha in the commit in fgdata.

Additionally there is https://api.github.com/repos/c172p-team/c172p/tags but I find that one less useful because we don't create tags for bugfix releases (we only update the release branch)

[onox]

If you want, I can write a shell/python script that does all this (JSON fetch, sha compare, shallow clone, rsync, commit) and then post it here.

[edward-dauvergne]

I can say now that that would be a no-op with the core FG team. For example this is along the same lines as Thorsten Brehm's arguments about the original proposal to split FGData aircraft into git submodules, specifically these paragraphs:

If you look at our aircraft, you'll see the history go way back to the very beginning of FlightGear. Meanwhile, many aircraft developers have joined and left the project. Many private hangars have been created, shutdown, some were lost. The only aircraft which are guaranteed to live on are those in a repository controlled by the FlightGear community. It's not a guarantee forever - but it's a guarantee that is connected to the FlightSim (core / source code) itself - which is what really matters.

A community repo has a lot of advantages. When people leave, work isn't lost - maintenance kind of automatically "transfers" to the community. When really necessary, we can also apply patches - i.e. when something about the flight sim itself has to be changed and aircraft really need to be adapted (which we usually try to avoid, of course). A central repo also allowed us to use the bug tracker for aircraft issues. No one is going to work the bug tracker for issues which affect aircraft living in some dodgy private hangar, probably in 8 different versions maintained by 3 different authors - and we're going to see loads of aircraft forks, without an "official" repo.

A copy of the default aircraft needs to be part of the FlightGear infrastructure. How that happens is up to you. The reason is because the core team plans for the distant future. In 20 years time, both SourceForge and GitHub will probably no longer exist. Whether or not the c172p-detailed team will still be around then is also uncertain. So everything key to the FlightGear core needs to be packed up and moved as a block. Arguing to have the c172p aircraft removed from the FlightGear core completely will not go very far on the mailing list.

[onox]

Arguing to have the c172p aircraft removed from the FlightGear core completely will not go very far on the mailing list.

Where am I arguing that the c172p should be removed? I just said there's a way to automate the steps that Stuart is doing manually.

[edward-dauvergne]

Oh, I thought you meant that Torsten's script does this for the release bundle, not for the permanent FGData repository sync. Then maybe that should be asked on the mailing list. I have a feeling thought that Stuart needs to perform a number of manual steps and checks to make sure that the sync is correct and has not included too much. The sync involves the next branch and then again manual backporting to the release branch. This process could be quite brittle making it difficult for scripting. Otherwise I would assume that Stuart would have scripted this a long time ago.

[dany93]

Sorry to interfere in this subject, but I read in the FGDevel mail list that Torsten has pushed a 2018.2.2 version. I'm worried about the c172p propwash fix which was ready for being included since 29 May 2018. (master and release/2018.2).

https://github.com/c172p-team/c172p/blob/release/2018.2/c172p-set.xml c172p-set.xml,;line 1054 <spiral-propwash-coeff type="double">0.5</spiral-propwash-coeff> 0.5 instead of 1.

I've posted a message in FGDevel mail list too ("On holiday for a week" subject).

[edward-dauvergne]

It's not interfering, as this problematic situation is exactly what this issue is here to address and solve. The change is obviously not in the release. With a git repository mirror on SF that the c172p-team pushes to (or a team member manually merges to FGData), Torsten does not need to be aware that there are new c172p changes to incorporate, as they will automatically be bundled in the release with zero effort on his part.

[dany93]

This issue is for the mid-term.

The c172p fix is for now.

On 28 May 2018 in the FGDevel mail list, @edward-dauvergne wrote:

Cheers! The c172p team are also working on solving the too strong propwash issue. If that doesn't make it in time for 2018.2.2, that fix itself is important enough for a 2018.2.3 release.

You were the first asking for a fix and since you have often posted in this repository. I believed that you were aware that a fix had been pushed.

What can be done?

[edward-dauvergne]

Cross-posting again, I was on holiday so I could not help you get the fix into the repository in time for the automated 2018.2.2 release. In this case, an email to the FG mailing list would have helped. However the time span of less than a week (29th of May to 4th of June) is generally not enough time for core developers to react.

[dany93]

@gilbertohasnofb @onox

I don't know how to do.....

Once more, I've posted a reminder for the the Spiraling propwash coefficient change (not yet included in the upcoming FG release patch, just pushed by James Turner). Re: [Flightgear-devel] [flightgear:flightgear] 4 new commits to FlightGear

[dany93]

I've just received a response from James

Okay, I’ll merge that across now.

Would it help to give some of the C172 team write access to FGData so they can push such changes themselves?

Kind regards, James

[gilbertohasnofb]

I think @wlbragg has write access to FGData, does @onox have it as well? Could someone push that change soon?

Later at some point we do need to talk about the sync process once again, but right now the important thing is getting that fix synced.

[dany93]

Could someone push that change soon?

If I understand well (I hope, please check...)

I’ll merge that across now.

James will merge this change.