Should we keep fixing bugs in master or start working in v3.6?

[onox]

@Juanvvc @gilbertohasnofb @wlbragg @dany93 @andgi @dg-505 @thevirtualfer Do we start adding 3.8 features to master or we use it only for fixing 3.6 bugs until the release milestone?

I can create a new version-3.6 branch (v3.6 is used for the tag) if we choose the former.

[onox]

There's still a list of bugs that need to be fixed, but I'm afraid that the core devs only want us to fix critical bugs.

[wkitty42]

AIUI, that's why the branch was done... keep working on features in master and any bugs in 3.6 can be worked on from there and merged back into both 3.6 and master... later when 3.8 comes along, branch 3.8 at that point and keep working on master to 3.9+...

we still have a month or so to fix bugs and get those into fgdata now that they have something to work with... we just cannot add new features to what is there in the 3.6...

[onox]

Well, I disagree with that. They don't do it either in fgdata. They just have a feature freeze right now. They're not branching.

[wkitty42]

i know that, man... they are freezing /features/ but fixing bugs... /we/ branch because it is the easiest thing to do... a tag can also be done... if we have to go back and fix a bug (eg: sound files), then we can do that by fixing the v3.6 branch and they'll pull it into fgdata again... just keep working on features and such in master... if there's a bug found there that pertains to 3.6, fix it via a branch off of 3.6 and then merge the fix into both 3.6 and master...

[onox]

But then you have to backport fixes...

[wlbragg]

But then you have to backport fixes...

That is right and that doesn't sound like any fun.

[wlbragg]

But for core it is probably easiest to have the 3.6 branch and in most cases patching master with a bug fix for 3.6 shouldn't be that difficult.

[onox]

Okay, I'll create a v3.6 branch then.

[onox]

Here's the branch: https://github.com/Juanvvc/c172p-detailed/tree/v3.6

[onox]

I'll rename the branch to version-3.6

[wkitty42]

why would there being any backporting?

bug xxx found in version-3.6 git checkout version-3.6 git branch -b v3.6-bugxxx fix the bug submit a pr to merge v3.6-bugxxx with version-3.6 merge it into version-3.6 submit a pr to merge v3.6-bugxxx with master merge it into master remove v3.6-bugxxx

what am i missing?

[onox]

https://github.com/Juanvvc/c172p-detailed/tree/version-3.6

I've changed the branch name so that there's no possible collisions with the v3.6 tag.

[wkitty42]

i'm curious how that's going to affect my local repo since i fetched and checked out v3.6 :laughing: i guess it should adjust to the new name properly and it'll fix my fork when i push there...

[onox]

Can you do git pull again?

[onox]

You can try to do git branch -d v3.6 to delete the branch.

[wkitty42]

let me see what happens... [time passes] here's what i got now...

myuser@mymachine:~/myflightgear/c172p-detailed-dev$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
myuser@mymachine:~/myflightgear/c172p-detailed-dev$ git fetch upstream
remote: Counting objects: 26, done.
remote: Compressing objects: 100% (17/17), done.
remote: Total 26 (delta 10), reused 3 (delta 3), pack-reused 6
Unpacking objects: 100% (26/26), done.
From https://github.com/Juanvvc/c172p-detailed
   df6b2c5..e0a32e6  master     -> upstream/master
 * [new branch]      version-3.6 -> upstream/version-3.6
 * [new tag]         v3.6       -> v3.6
wkitty42@shadow:~/myflightgear/c172p-detailed-dev$ git merge upstream/master
Updating df6b2c5..e0a32e6
Fast-forward
 Models/Effects/interior/black_px.png     | Bin 9050 -> 10768 bytes
 Models/Effects/interior/blue_px.png      | Bin 185429 -> 191235 bytes
 Models/Effects/interior/default_px.png   | Bin 209986 -> 212723 bytes
 Models/Effects/interior/grayscale_px.png | Bin 71602 -> 75980 bytes
 Models/Effects/tyrespray/rain-nose.xml   | 135 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 Models/Effects/tyrespray/rain-port.xml   | 135 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 Models/Effects/tyrespray/rain-stbd.xml   | 135 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 Models/Effects/tyrespray/smoke.png       | Bin 0 -> 6482 bytes
 Models/c172p.xml                         |  49 ++++++++++++++++++++++-------------
 Models/interior_cube.xcf                 | Bin 9310240 -> 9310126 bytes
 c172-sound.xml                           | 208 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 c172p-set.xml                            |  53 +++++++++++++++++++++++++++++++-------
 12 files changed, 689 insertions(+), 26 deletions(-)
 create mode 100644 Models/Effects/tyrespray/rain-nose.xml
 create mode 100644 Models/Effects/tyrespray/rain-port.xml
 create mode 100644 Models/Effects/tyrespray/rain-stbd.xml
 create mode 100644 Models/Effects/tyrespray/smoke.png
myuser@mymachine:~/myflightgear/c172p-detailed-dev$ git branch
  bug-248
* master
  v3.6

so now i guess i should delete the v3.6 branch i had pulled earlier? then i can check out version-3.6 if i want or need to...

[onox]

Yes. And if you do git tag -l you can see one tag named v3.6. You can also do git tag -v v3.6 to verify the tag.

[wkitty42]

myuser@mymachine:~/myflightgear/c172p-detailed-dev$ git branch -d v3.6
Deleted branch v3.6 (was df6b2c5).
myuser@mymachine:~/myflightgear/c172p-detailed-dev$ git checkout version-3.6
Branch version-3.6 set up to track remote branch version-3.6 from upstream.
Switched to a new branch 'version-3.6'

seems ok :smile_cat:

[onox]

I've asked on the mailing list if they accept bugs from our 3.6 release milestone. If the answer is no, we can accept pull requests to version-3.6 branch from them and in the mean time we can start working on 3.8 feature freeze milestone issues, although I suggest to focus on 3.6 release issues, since that list needs to go down to 0 open issues once day :smiley:

[wkitty42]

if they accept bug fixes? they should since they won't be features like the new craft is for them... they should accept them up to their bug fixing freeze in another month or so...

i agree on fixing the bugs we have now and know about in the version-3.6 branch... that doesn't mean that features can't be done in master, though... one just has to be certain of what branch they are in when doing the work :wink: :laughing:

[wkitty42]

i forgot to add that they should be submitting bugs back to us for version-3.6, too... of course, we might should let stuart know that the branch name has changed to version-3.6 instead of v3.6 and that there is a tag by that name...

[onox]

i agree on fixing the bugs we have now and know about in the version-3.6 branch...

You mean these bugs?

That depends on whether they accept fixes for those bugs. They might very well just only accept one or two critical fixes. In that case the bugs above have to be fixed in master.

That would mean that we can just forget about version-3.6, because only the core devs are going to create PR's for that branch. We can keep focused on master then.

[wkitty42]

yeah, i guess all those are bugs and not features... i see some are marked as "enhancement"...

either way, my understanding is that bug fixes should be accepted by them from now until 0000 GMT 17 July when their bug fix freeze goes into effect and they cut 3.6 loose to the rest of the hungry masses... that gives us a month to get those ones taken care of or moving them to 3.7/3.8 coming up in what? 5/6 months i think? that's a nice release cycle if i have it right...

another project i'm on has four updates a year and that only give us three months in each period... that's not even doing anything for a new version release which has work ongoing at the same time...

[onox]

Anyway, I'm waiting for answers on the mailing list. If they only allow critical fixes, meaning we can start adding 3.8 features to master, then I'll bump the version in c172p-set.xml in master to 3.7. (I won't touch the version-3.6 branch)

[wkitty42]

right! there ya go :) i'm playing catch up with messages over several formats, too... past time for dinner, as well... my email is next and that's going to be ~200-300 posts at least...

[onox]

I got an answer from Stuart on the mailing list:

Yes, you can keep fixing bugs for 3.6, and from a quick glance over the list those all look absolutely fine. It's just a feature freeze.

Once we get to the code freeze, we'll only be accepting critical fixes of the "plane doesn't load" variety, so you should assume that you can't make any fixes after that point.

So we can first fix the 3.6 release bugs until 16th of July. After that we can work on 3.8 features.

[onox]

I've set the code freeze milestone (3.6 release) to a couple of days earlier (Monday 13th of July), so that we can do any last merges of master (assuming that no one commits new features to master) to version-3.6 on time.

[gilbertohasnofb]

Guys, my brain is a bit more git-limited than most of you, so could you please explain to me in layman terms what has been decided about these branches? When I fix a bug something, should I do it on the master branch or somewhere else from now on?

[onox]

1. We do not add 3.8 features to master
2. We fix bugs from https://github.com/Juanvvc/c172p-detailed/milestones/FlightGear%203.6%20release in master
3. Once in a while can merge master to version-3.6.

[gilbertohasnofb]

Perfectly clear! Thanks onox :smile:

[onox]

Btw, ehofman has created a new stall sound: http://www.adalin.com/ehtw.info/html/images/sawtooth.wav that can be licensed GPLv2.

I don't like it as much as our stall sound. If you don't really like it either, we can just add it to version-3.6 so that our master branch can still contain the better looking stall sound.

[gilbertohasnofb]

I don't like it at all. Really, a stall sound is not a simple saw tooth but a much richer sound with fluctuations.

I will try to find some compatible sounds for our plane then... I think we need to rework the stall, the trim wheel and the parking brake lever, correct?

[onox]

@gilbertohasnofb For the version-3.6 branch the file needs to be GPLv2.

[gilbertohasnofb]

Or CC0 as well, right? Meaning copyright free.

[onox]

This is what ehofman wrote on the mailing list:

On 06/17/2015 12:14 PM, Ludovic Brenta wrote:

Denk Padje wrote:

So CC-BY 3.0 licensed files can legally be distributed as part of FlightGear, but we don't do it because the policy is to only distribute GPLv2 files?

Pretty much, yes. At least that's my understanding. And I think it's "GPLv2 or later".

It's not. We guarantee GPL 2.0+ compatibility. But there are Public Domain files in SimGear. For instance Davids XML and property tree code.

[onox]

So, CC0 is not allowed either. ehofman says public domain and CC-BY 3.0 are allowed, but stuart and ludovic say no.

[gilbertohasnofb]

So, CC0 is not allowed either.

Are you sure???

"CC0 is the "no copyright reserved" option in the Creative Commons toolkit - it effectively means relinquishing all copyright and similar rights that you hold in a work and dedicating those rights to the public domain." from https://wiki.creativecommons.org/wiki/CC0

ehofman says public domain and CC-BY 3.0 are allowed, but stuart and ludovic say no.

Oh dear...

[onox]

Yep, that's their policy, everything has to be GPLv2, even data files for which GPLv2 makes no sense. I have wished them good luck finding artists who license their works under the GPL :joy: :sob:

[gilbertohasnofb]

Oh, so this is messy. Every single public domain sound we used so far is marked as CC0. Actually, this is how the license is defined:

The person who associated a work with this deed has dedicated the work to the public domain by waiving all of his or her rights to the work worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law. You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission. See Other Information below.

https://creativecommons.org/publicdomain/zero/1.0/

That's as public domain as it gets, and it says nothing about sharing with a similar license.

But if it's the case we can't use CC0, then I mean... then I think we have to remove every single sound from our project and then either record them ourselves or completely give up adding sounds.

[gilbertohasnofb]

Oh boy, I might have to recheck the textures as well.........

[gilbertohasnofb]

:weary: :sob:

[Juanvvc]

I think you missed the second part of ehofman message: the pitch of the stall sound must depend on the angle of attack :) The current Sounds/stall2.wav is looped and does not depend on the angle of attack. It sounds "right", but it is not.

I believe ehofman proposal of a constant sound, in addition to have a not questionable license, is more flexible and allow us to play with the effect to make it more realistic.

[gilbertohasnofb]

I think you missed the other part of ehofman message: the pitch of the stall sound must depend on the angle of attack

No, I didn't miss that. I just think that's a crude approximation; I can easily imagine how this will sound with its pitch changing with the angle of attack, but to me it will still sound very poor. It will be a better model of how a stall horn works in RL but it will sound worse, and therefore be a worse effect in my opinion. For instance, a stall horn is not a constant sound but it comes and goes at the activation time. There is lots of fluctuations in the sound which are very difficult to model (that's why a looped sample is far superior IMO).

Here is an analogy: you can have a model of how the particles of air interact with light to decide how to colour the sky, or you can hard code the sky colour according to how you want it to look like. A crude implementation of the first would be a better model of reality of course, but it does not guarantee a better looking sky. And I think the second approach is much better.

I believe ehofman proposal, in addition to have a not questionable license, is more flexible and allow us to play with the effect to make it more realistic.

Sure, license wise it makes sense. But I do plan to recreate a better stall sound myself as well, if that's all right with all of you.

[onox]

I have to go now, but whatever your plan is, make changes related to licensing in the version-3.6 branch, not in the master branch.

[gilbertohasnofb]

@onox okay, we speak later then. But I am really in need of advice on what to do with those sounds of ours (and maybe some textures as well). All of the sounds are most certainly CC0 and if we really won't use any CC0, then the solution is to delete them all and then either to synthesize the sounds ourselves (usually tricky and rarely sounds good) or record it ourselves (we need someone with a good audio recorder and access to a C172). I could try to record some of these sounds at home in the next days (clicks, knobs, etc.), but that would be a new feature and wouldn't make it to FG 3.6... :cry:

Anyway, I won't actually touch on any sounds until this whole situation is completely clear, as there is lots of potential of wasting time and wasting work.

[Juanvvc]

In real life, there are fluctuations because you fix the angle of attack. In the current version of the sound, we have fluctuations even if you maintain constantly a too high angle of attack and you are under a constant stall

These fluctuations are not only wrong on a real C172, they were also one of the reported failures that caused the AF447 accident in 2009.

[gilbertohasnofb]

I know that, but my point is much simpler: what sounds better, a recorded sample that may sound unrealistic in some situation but sounds good or a clearly computer generated sound that has some realistic behaviour. I prefer the recorded sample, that's all. But as always, it's up to you guys to decide which way to go.

[Juanvvc]

I can admit wrong sounds in other parts of the aircraft, but the stall horn is a system critical enough to be completely realistic in a flight simulator. I really prefer not playing recorded fluctuations when the alarm must be constant.

In addition, I really think the sound proposed by Erik can be realistic once implemented the pitch and volume effects. We can find these effects in use in the propeller, for example.

[gilbertohasnofb]

I still have my doubts about how the final result will be, but all right.

[onox]

We can control the pitch with a property based on AoA. Does it depend on other factors as well?