search

LMMS / lmms

Cross-platform music production software
https://lmms.io
GNU General Public License v2.0
8.15k stars 1.01k forks source link

Stale and unused branches #5172

Closed rubiefawn closed 2 weeks ago

rubiefawn commented 5 years ago

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.

image

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

tresf commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

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

JohannesLorenz commented 4 years ago

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 commented 4 years ago

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 (b621c7eb34cc0a1ec6db5e4dd2dad60f2e721f2a), 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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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

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

rubiefawn commented 2 weeks ago

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 commented 2 weeks ago

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

Rossmaxx commented 2 weeks ago

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

tresf commented 2 weeks ago

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 commented 2 weeks ago

Ok I'm deleting the branches.