Organization

[D-ECHO]

I think, at least for me, the most important issue at the moment is how to organize things. Myself, I'd "vote" for completely dropping YASim and only concentrating on JSBSim, mostly because keeping cross-compatibility takes a lot of worktime that could be used better on improving the aircraft (IMO). However, I'm open to discussion and would also submit to a majority ;)

[DanielMeissner]

For the development: At the moment my preference would be to get the basics right for the -900 variant, since the compatibility layer for the two FDMs is already in place. Once we are happy with that we could then add more sophisticated things and also scale the other variants. I'm impartial to when to drop the YASim variants.

For releases: Get the canvas stuff in now (as soon as possible) since that is tailored towards the current release. Maybe a -900jsb could be a "technology preview variant". This is also the goal of the RC1 branch that Henning and I have maintained for some time now. The most difficult issue anyway is merge conflicts from all the different repos and branches. Should we wait with that a few weeks to get more features tested out and finalized? Or start "The Merge (TM)" now and fix everything later?

After that we restructure everything and focus only on JSBsim and canvas instruments.

[D-ECHO]

I'm fine with concentrating on getting one variant right and then bringing the others to the same state. My JSBSim (https://github.com/CRJ700-family-team/CRJ700-family/tree/jsb-echo) also includes FDM for the other variants, but the differences in the files are only very small, also aerodynamics is completely "outsourced" into a separate file, so that changes there will be applied to all models.

In my opinion, it's best to do "TM" ;) as soon as possible, and from that common ground start off adding, testing and finalizing new features and stuff.

[D-ECHO]

Probably not contributing to the ease of this, the autopush work as well as the ALS Lights (#1 ) are in the jsb-echo branch, but I think as these are more nice-to-have we can leave this in a separate branch for now, merge everything else into master and then start work on JSB and add the additional features ALS lights and autopush

[tdammers]

My $0.02:

• Rather than attempt a "proper" merge (via plain old git merge or whatever), it's probably a more promising idea to take the current master branch and manually perform/replicated the desired changes we want to "merge" (either by making the required edits by hand, or by copying individual files over from other branches wholesale).
• Getting one variant right first seems like a good approach: we can then throw away the others and essentially redo them from scratch (except for the models and liveries and such). I would strongly suggest doing this on a separate branch though, and to do this after we have done "The Merge", in order to keep the master branch in a releasable state.
• Autopush seems like a fairly separate and nonintrusive thing that could be merged at any time.
• Many of the merge conflicts I have encountered when I attempted merging the canvas stuff were due to formatting, so I'd say we should get that sorted out at some point. Since The Merge is going to be disruptive anyway (the dreaded "git blame brickwall"), I say we should do a reformatting sweep right after it (or as part of it, same difference). That is, adopt formatting conventions (at least for XML and Nasal), and reformat everything to that. This way, future merges stand a better chance of avoiding conflicts. I'm not particularly set on any specific formatting convention, as long as there is one at all.
• Maintaining YASim and JSBSim in parallel sounds like lunacy in the long term, but dropping YASim is only acceptable if and when the JSBSim model is production ready and feature complete, at least to the same degree as the current YASim one.
• Same for the canvas screens - the current ones are far from perfect, but they're flyable, they do the trick, and performance is pretty good (better than airliners with canvas screens IME). I think we should only "release" (by whatever definition of "release") the canvas stuff once feature parity (and at least an approximation of performance parity) with the current situation is achieved. Of course we could do this one screen at a time.

[D-ECHO]

• I also think we should do the merge manually. At least I'm not fluent enough with git to not messup the whole thing halfway through.
• Is dropping YASim really only okay when JSBSim is production ready? This is the point where I'm unsure about. As we're being in a development repository here, I think we also could "afford" to have a non-production-ready state in here for a couple of time.
• I think @d-jsb's canvas work definitely should be merged in and the traditional XML screens should definitely be dropped. Again as above, I wouldn't have much headache about having a not production-usable version in here for a time, but that's only my opinion. I also think we should give ourselves plenty of time of developing in here, before doing a "release", i.e. declaring the version usable for everyday use

[d-jsb]

Hi :) as the delta between my local branch and the official branch on sourceforge got quite big, I tend to do a (semi-)manual merge, e.g.

• get any updates from the official repo I might have missed
• apply all the canvas EFIS work as one commit
• see what else is new and apply step by step

The 2nd step means dropping the old PFD, MFD, EICAS implementation (including any updates that may have happend in the last 2(?) years). Writing documentation in the Wiki is also quite high on my to do list so the framework I wrote may find more use.

[d-jsb]

I would not drop YASim to early, I put some code in some places to allow both FDMs to coexist in the CRJ700-family. Once you are happy with the new jsbsim models we could drop YASim...

[D-ECHO]

Okay :) sounds very good for me

[D-ECHO]

Hi @d-jsb , just wanted to quickly ask what's the status of merging the canvas instruments :)

[d-jsb]

Hi, I'm still in discussion with the core team regarding the module loader and framework going to FGDATA. I think there will be an agreement soon so I can submit the rest of my work.

[d-jsb]

Short update: the module loader and the canvas efis framework are in fgdata now (next branch) Being a little bit busy at the moment I will never the less pull the latest changes from the official repository and try to prepare an update of the CRJ700 as soon as possible