Stale and unused branches

[rubiefawn]

There are a number of stale branches that haven't been touched in years, and show no indication of being merged or contributing to the project in any way.

• ❓ unstable-0.4 needs code review before discarding.
• ❓ unstable-1.1-lmms2 needs code review before discarding.
• 🗑 unstable-1.1-zyn removed by @PhysSong
• 🗑 fix-ds-env removed by @PhysSong
• 🗑 stable-1.1
• 🗑 maintenance-test2
• 🗑 maintenance-test
• 🗑 feature/recording Deleted with @Reflexe's permisison.
• 🗑 #4904 Removed by @JohannesLorenz.

Is there any good reason to not clean up and delete these stale branches?

[tresf]

0.0.9 to 1.0.0 are all available as releases with both binary and source.

unstable-0.4 It had features that never made it to stable-1.0 proper. Reason is, it made lmms so unstable that the project completely reverted to 0.4.15 codebase for what eventually became stable-1.0. A code review is needed before abandoning any features.

unstable-1.1-lmms2 hasn't been touched since 2014, and binaries and source for 1.1 and family exist as releases.

Same story as unstable-0.4, but for the stable-1.1 release. Yet again, developers got too progressive, yet again the work got abandoned. A code review is needed before abandoning any features.

unstable-1.1-zyn

This working Zyn 2.5 integration code but never made the cut due to crashes with Windows. Whomever is doing the Zyn 3.0 integration can decide if this code has value: AFAIK, it's @JohannesLorenz.

stable-1.1

If deleted, we'll lose the tags that our releases are targeted against. We should keep all stable branches for eternity I think. If I'm wrong, please explain.

maintenance-test2, maintenance-test

Deleted.

feature/recording

AFAIK @Reflexe needs to decide.

[JohannesLorenz]

unstable-1.1-zyn

This working Zyn 2.5 integration code but never made the cut due to crashes with Windows. Whomever is doing the Zyn 3.0 integration can decide if this code has value: AFAIK, it's @JohannesLorenz.

2.5 is better than what we have at master right now. However, for Linux, zyn 3.0 can (and IMO should) completely be done via plugin. I'm just not sure if Lv2 works on Mac and Windows. Also IIRC @tresf mentioned there was a licensing issue with zyn plugin binaries, but this should not prevent us from using zyn on Windows via plugin?

Btw, if we want to get abandoned branches away but are not sure if we want to delete them, we could add a new repo "abandoned-branches" to the LMMS org. Though this can have disadvantages, too...

[tresf]

if we want to get abandoned branches away but are not sure if we want to delete them

We can also create and close a PR against a comparable branch, which (I think) should keep the diff around forever even after the originating branch is gone.

[Reflexe]

feature/recording

AFAIK @Reflexe needs to decide.

this branch is obsolete and can be removed. When ready (in the next month, hopefully) , I'll open a pull request and we'll merge recording into master.

[JohannesLorenz]

I'm just not sure if Lv2 works on Mac and Windows. Also IIRC @tresf mentioned there was a licensing issue with zyn plugin binaries, but this should not prevent us from using zyn on Windows via plugin?

Can anyone answer these two questions?

[tresf]

I'm just not sure if Lv2 works on Mac and Windows.

MacOS should be fine. Don't know about Windows. Calf-studio gear has the following info on their site regarding LV2 + macOS support:

Calf Studio Gear under MacOSX

Its possible to compile calf plugins under Mac OS X. If you are using homebrew, you can use the > Formula from the homebrew-audio tap. This allows you to use calf plugins under any LV2 capable host or via jack using calfjackhost. Be aware that the LV2 GTK dos not work reliably, so you should use the generic UI only.

Installation using homebrew

brew tap david0/homebrew-audio
brew install --HEAD calf

If Windows doesn't have LV2 support I'd guess it has to do with IPC communications, but I'd ping @DomClark for insight into that, he's our resident Windows expert.

@tresf mentioned there was a licensing issue with zyn plugin binaries

I don't want to mislead anyone, Zyn's still open source. That was only in regards to using pre-compiled binaries from @fundamental versus building our own. For example, if we provide the plugin unencumbered with LMMS, it would be a bit unethical despite being perfectly legal. I'll quote the Zyn page:

Introducing: ZynAddSubFX 3.0: Zyn-Fusion

The Zyn 3.0 UI is open source at this time, but to support development binaries are for sale $45+ through gumroad. You can also download the free demo here, which only has the limitation of going silent after 10 minutes.

• Buy Zyn-Fusion, $45+:
• ... or try the FREE Demo

[DomClark]

I'm just not sure if Lv2 works on [...] Windows.

I'm not especially familiar with LV2, but I don't see why not. It seems to purely specify its own API without relying on POSIX APIs or anything. A more convincing argument, however, is that the LV2 and lilv source code contains #ifdef _WIN32 checks, suggesting that it is indeed intended to be able to run on Windows.

For example, if we provide [Zyn 3.0] unencumbered with LMMS, it would be a bit unethical despite being perfectly legal.

How are we planning to encumber it? Hopefully not by including the demo version; that would be a step backwards from our current version of Zyn. I recall a discussion on Discord about including a version that only works in LMMS, so people still have to buy or build it themselves to use it in another DAW. I'm not sure how this could be achieved through LV2, but I guess @JohannesLorenz can figure that out.

If deleted, we'll lose the tags that our releases are targeted against. We should keep all stable branches for eternity I think. If I'm wrong, please explain.

A git branch doesn't contain the commits within it as such; it's just a pointer to its head commit. Deleting the branch doesn't actually get rid of any commits, rather it just deletes the pointer to them. (You wouldn't want it to delete the commits anyway, since commits often appear as part of multiple branches.) Git has a garbage collector to get rid of any orphaned commits after a while (not sure how often this gets run), but as long as there's a reference to a commit, e.g. through a tag or a branch, it should be safe. (At least this is my understanding - again, if I'm wrong, correct me.)

[tresf]

How are we planning to encumber it?

Simply disable interfacing that's non-critical to its functionality. I'd argue simply disabling VSTi support would be sufficient, but I don't know the metrics on how the plugin is consumed by the masses. If there's an "unlock" technique though C++ that can be invoked, that may also be viable.

Alternatively we could create an obfuscation, but that makes debugging harder.

Hopefully not by including the demo version; that would be a step backwards from our current version of Zyn.

No, agreed.

[tresf]

as long as there's a reference to a commit, e.g. through a tag or a branch, it should be safe.

This makes sense. To this point, we can delete anything with a tag, which I think is just stable-1.1. @iansannar FYI, I noticed you haven't updated your branch descriptions with a summary of why we may want to keep these branches.

With this information, I've removed stable-1.1 branch.

In regards to the ones without tags... I started looking at the stale branches. unstable-1.1-lmms2 has 33 commits, but about 3,000 lines changed. At a glance, I can quickly see that some features (like SampleExact) are ported, some (like a dedicated TempoTrack, BasicFilter names) are not.

Is it valuable? I don't know. Even if it is, I don't know if anyone will know to cherry-pick from it since the primary authors aren't here to yell at us when we're duplicating their work.

What I do know with certainty is 3,000 lines of code takes a very long time to author and some other branches have changes that are much, much bigger. If we purge these, the people largely invested in maintaining the C++ codebase should agree. I generally don't fall into that category, so I'm indifferent.

[tresf]

feature/recording

AFAIK @Reflexe needs to decide.

this branch is obsolete and can be removed. When ready (in the next month, hopefully) , I'll open a pull request and we'll merge recording into master.

(@iansannar reacted with 👍)

@iansannar you reacted but didn't remove it? Ok, well now I have removed feature/recording with written permission from @Reflexe.

[rubiefawn]

you reacted but didn't remove it?

Pretty sure I can't modify anything but my own fork, and deleting branches there doesn't affect the original repo, so 👇

Ok, well now I have removed feature/recording with written permission from Reflexe.

Thanks 😁

[rubiefawn]

I might add the following branches to this discussion. Feel free to correct me if the following branches are still relevant.

• fix-ds-env seems to be a branch that exists solely for DrumSynth: ensure correct envelope length in any sample rate #5467 which has already been merged.
• #4904 shares a name with After linking models, values are swapped instead of being the same #4904, a closed issue. Removed by @JohannesLorenz.

[JohannesLorenz]

#4904: Thanks for the info. I probably accidentally pushed that to LMMS/lmms instead of my fork. I removed this branch from LMMS/lmms now.

[JohannesLorenz]

unstable-1.1-zyn: I checked this branch and think we should not use it. It is set up before we turned zyn into a submodule (b621c7e), so this will have tons of conflicts. I'd prefer one of the following:

1. merge the official 2.5 into our LMMS/zynaddsubfx
2. do nothing now, wait for Lv2 (will take a whole while)

[PhysSong]

unstable-1.1-lmms2 can be reviewed in per-commit basis because there are only 19 commits to review(excluding merge commits).
unstable-0.4, however, can't be reviewed in the same way. Even after excluding commits which was cherry-picked to/from master or already reverted, hundreds of commits still remain.
For re-using or discarding the branch, we need to first find the list of major changes which are only in unstable-0.4.

@JohannesLorenz What do you want to do with unstable-1.1-zyn?

[JohannesLorenz]

@JohannesLorenz What do you want to do with unstable-1.1-zyn?

It's just a pointer to a very old master. The branch can be removed. In order to update zyn, I think we should implement Lv2's UI feature and then we'll have the newest zyn "for free".

[PhysSong]

Thanks. I removed unstable-1.1-zyn.
For the remaining branches:

• I've looked into unstable-1.1-lmms2. Due to recent heavy renaming, there are too many merge conflicts to update the branch. We probably have to re-implement what implemented in the branch if there are demands for it.
  However, there are only a few major changes in the branch. Part of them might still be useful, but I need to look into them more deeply.
• I started to review changes in unstable-0.4. Some features are not very useful at this moment because they are either too outdated or already implemented in different ways. There are some other features which look very interesting, though.

Once I finish reviewing those branches, I will open new issues or comment on existing issues for useful but abandoned changes in them.

[rubiefawn]

Any update on these last two branches? I'd like to tie up loose ends and close this issue.

Edit: It's okay if we decide to keep those branches, I just want that to be an intentional decision.

[Rossmaxx]

Go ahead. We have diverged way too much to even care.

[Rossmaxx]

I would like to ask @tresf on his opinion before deleting the branches, in case we have something of value over there.

[tresf]

Any update on these last two branches? I'd like to tie up loose ends and close this issue.

Edit: It's okay if we decide to keep those branches, I just want that to be an intentional decision.

It's an OK from me. There was a day that I thought perhaps the features that landed there might be useful to others, but all these years later, I believe it's a lost cause. For example, @diizy was highly involved in those days, but mysteriously vanished from the project in May of 2015. I think 9 years is a respectful amount of time to wait. No objections here.

[Rossmaxx]

Ok I'm deleting the branches.