Lmms: Make developing more attractive

[JohannesLorenz]

This is a meta issue on making developing more attractive, in order to gain new developers and also to keep current developers.

You can reference other issues here, whether new or existing.
They must not be detailed, e.g. you can write "LMMS needs better VST support because the project will die without VST", but you can't reference issues like "VST abc fails in situation xyz".

This thread is using sub-captions to categorize the issues. Of course, those can be changed by request.

How to make the work itself (coding/versioning) more attractive

• [ ] Guide for setting up QtCreator (#4934)
• [ ] Make master branch spit out nightly builds, treat master as the preferred version for power users and developers. (#3347)
• [x] Master branch is unstable (#4931)
• [ ] Pay more attention to PRs (#4935)
• [ ] How to get the code better documented? (#4932)
• [x] Extend plugin development wiki page @JohannesLorenz . Should be up-to-date and cover Native, Lv2, maybe SPA.
• [ ] Improve plugin development wiki page to explain basics like NotePlayHandles, see @DeRobyJ 's post below.

Sources of new developers

• [ ] Google Summer of Code 2020?
• [x] Hacktoberfest 2019?
• [ ] Social Media?

Keep LMMS competitive with other DAWs

If a project is fun to program, but no one uses it, it's still not attractive to devs.

• [ ] Make LMMS realtime safe

[musikBear]

would make it more competitive with other daw

Does that matter? Afaik there is no 'competition'. Competitors fights for market-shares, because they make money on set shares. LMMS does not.
I see no reason to compare LMMS' market-position to any commercial DAW' Its rather irrelevant.
In respect to getting coders, i think that beside having deep insigt in cpp/qt there are 3 factors that matters:

• interest in music
• spare time in abundance
• strong believe in open-source

If that can be accepted, then it is obviously a limited number of programmer-candidates

[StakeoutPunch]

Does that matter? Afaik there is no 'competition'. Competitors fights for market-shares, because they make money on set shares. LMMS does not.
I see no reason to compare LMMS' market-position to any commercial DAW' Its rather irrelevant.

It is absolutely relevant when a frightening amount of LMMS users end up migrating to other, commercial, DAWs due to lack of features and/or bugs. Competition is not just about money. Getting people to work on a program is a hard sell when they just see it as an out-of-date toy.

[JohannesLorenz]

@Gabrielxd195 I'm not sure with the exact meaning of all the points you bring up. I'd suggest you open issues for your threads and then I'll reference them (you can also edit my post if you can). But please note: FWIR the stable-branch model is deprecated after 1.2.0 (at least I heard that from @tresf ), so it may not be necessary to mention issues about the stable branch.

[he29-net]

I wouldn't say deep insight in C++ and Qt is that much of a necessity. I had no prior Qt experience and it took me just a day or two to figure out all the main concepts. Deeper C++ experience may be helpful to deal with some of the more obscure stuff, but if you know any other language well, it should be easy to find solutions online.

As for spare time -- everyone has spare time, it's just a question of motivation and priorities how it will be spent. :) Sure, LMMS is not a mainstream project, so the pool of potential contributors is a bit smaller. But given the user base (I saw a reference to ~2M downloads at the forum?), there should be more than enough.

For me, the main obstacle was simply not knowing how everything in LMMS works. When you write your own code, you instantly know where to find any file and any class, you know about all the older parts that can be simply reused and so on. When you look at code from someone else, you need to figure out every little thing in order to move forward.

Combined with lacking comments and not very descriptive variable names, this gets tiresome and demotivating very quickly. For example, a seasoned dev may see a function parameter "fpp_t frames" and instantly know what it means. For me, it immediately raises many questions:

• is that a class or just a simple data type?
• what is a frame?
• does it hold some audio data?
• what does "fpp" stand for?

If it was simply called "frame_count", I wouldn't even have to stop to think about it, I could instead focus on understanding what the code does with it.

It's a small distinction, but those can pile up. What it ends up doing is shifting the balance between "hey, it's not actually as hard as I thought, I think I could do it" and "I've been sitting here for an hour and still have no clue what this code does, let's go do something else instead".

I know, because I've been programming for around 15 years (and using primarily FOSS for about 10) and it never occurred to me, that instead of just reporting issues for programs that I use, I could be actually fixing them myself. The perceived difficulty of _starting_ to contribute to a project usually just seemed too high.

LMMS happened to get my attention because I noticed an issue that a) kind-of solved my problem (providing necessary motivation) and b) seemed easy enough to do without extensive knowledge of the inner workings (lowering the perceived difficulty).

In this regard, there are already "good first issue" labels -- these are great! Maybe they could get more exposure, i.e. make a list of easy and interesting first issues and drop some links near the support sections, so that programmers that are passing by can realize contributing directly is actually an option. :)

Documenting all the code in detail is not going to happen, right, no question about it. :D Not to mention many of the little problems would be essentially invisible for devs familiar with the project, since, well, they already know. :)

But a suggestion to explain non-trivial portions of the code, non-obvious function inputs / outputs and to prefer longer, descriptive names, could be perhaps added to Coding conventions. I probably break many coding conventions during development myself, but I try to put in some effort in the end to clean up the code before publishing.

I.e., write the code for _other_ people. Always assume a truck will run over you _tomorrow_, and the long-term viability of all your contributions will depend on whether somebody else would be able to understand your code and maintain it. :)

[Spekular]

Looking at the wiki's home page, we don't currently have an obvious "CLICK HERE IF YOU WANT TO HELP DEVELOP" article anywhere. "Submitting a patch" is probably the closest, but it's the fourth subpoint in the third section.

A link above even "Getting Started" titled something like "Contributor Quickstart"/"Contributing Step-by-step" should grab people's attention when they check the wiki, and could be a useful resource to link anyone interested. Something like a list of steps, with each step linking more in depth instructions if necessary.

Contributor Quickstart

• Decide what you want to work on
• Get a development copy of LMMS set up
• Familiarize yourself with the relevant code
• Implement your improvement
• Create a pull request
• Wait for code review
• Get in touch if you run into issues

Somewhere tied to the "implement your improvement" step could be a page or note mentioning that comments should be added to the code you touch, to assist #4932.

[tresf]

I've read a lot of replies on this bug tracker but @he29-net's is one of my favorites as I think accurately depicts very important struggles with the code base.

To share a bit of personal experience, I'm 50+ hours into a tiny abandoned C++/Java project and still haven't refactored code. The amount of work that can go into preparing source code for mass consumption can be a very timely task.

[musikBear]

HUGE :+1 to both he29-net & Specular!
In a cooperative project like LMMS comments cant be too detailed!
For every method, there ought to be a 'Header' comment, that explains what this particular method does and how. It should also be noted from where the method recieve input paramters, and where (name of method) the output is used. The best would be a standard form, so the clarity of the code is enhanced, also that way.
Exactly as he29 wrote, The code you write, should be for others to understand, using method-names that is non-deskriptive, is in most cases, a cardinal sin.
Imo, a prerequest for submitting patch, should be that all code is thoroughly commented, and explained -preferably explained for dummies!
And huge :+1 for a Beginners-guide-to-LMMS-coding

[Spekular]

Here's a draft of the Contributing Step-by-Step wiki page.

[tresf]

Here's a draft of the Contributing Step-by-Step wiki page.

I see a few upvotes on the original proposal, but I'm not sure that helps. We can add a link to "Good First Issues" on our main wiki as most of those bullet items I would consider common sense. @Spekular please do not take offense to this breakdown. ❤️

• Ask for help when you need to -- common sense
• Decide what you'd like to work on -- well, of course.
• Build your own copy of LMMS -- that's sort of the point
• Familiarize yourself with the relevant code -- most of this is already under the "Start Coding" section of the main wiki
• Implement your improvement -- common sense
• Coding conventions -- already under the "Start Coding" section of the main wiki
• Create a pull request and await review -- common sense
• Celebrate! -- not necessarily. Most reviews actually result in more work -- and worse, the target release may be a long time out!

I think better time is spent addressing the points addressed above.

• @JohannesLorenz - Master branch is unstable (#4931)
• @JohannesLorenz - PRs are not getting attention / mark PRs that they're ready for review
• @JohannesLorenz - How to get the code better documented? (#4932)
• @he29-net - [add] comments [and make] descriptive variable names [to avoid] tiresome and demotivation [reactions]
  
  
  
  • @he29-net - explain non-trivial portions of the code
  
  
  • @he29-net - [explain] non-obvious function inputs / outputs
  
  
  • @he29-net - prefer longer, descriptive names
  
  
  • @he29-net - add these items to coding conventions
  
  
• @he29-net - "good first issue" labels [need] more exposure [...] [distribute] some links [#support, etc] to community
• @he29-net - write the code for other people [or as I'd put it, for yourself, a year from now]

And my own list...

• @tresf - Make master branch spit out nightly builds, treat master as the preferred version for power users and developers. (requires releasing 1.2, automating the release system for master).

[Spekular]

@tresf No offense taken, but I think you've missed the point. The point is to have an:

• Obvious starting point
• Birds eye view
• Collection of existing resources
• Organized by the order you'd need to use them
• That assumes very little previous knowledge

The guide is like navigating the wiki on autopilot. It's a video game quest log, a map, rails, whatever. Keep it open and work your way down and you don't have to think about anything except doing one step and then the next. Why waste people's brain-cycles with having to plan for themselves?

Ask for help when you need to -- common sense

But where?

Decide what you'd like to work on -- well, of course.

But how? I think it's valuable to point people to "good first issue"s and the meta issues, as well as nudging them towards existing issues before they go and start a brand new, potentially duplicate or troublesome issue.

Build your own copy of LMMS -- that's sort of the point

There for the purpose of having an overview of the entire process

Familiarize yourself with the relevant code -- most of this is already under the "Start Coding" section of the main wiki

Yes, and? It's also mixed with unrelated pages and "core architecture" is below the more specific pages for no reason.

Implement your improvement -- common sense

Birds eye view + encouraging code convention, commenting, and unit testing

Create a pull request and await review -- common sense

To who?

Celebrate! -- not necessarily.

Actually, you might get a few comments about things you have to change first. Even so, you've come a long way, so give yourself a pat on the back! This is just a cheeky pre-emptive thanks mixed with encouragement. It already acknowledges that there will be more work to do.

As for time is [better] spent, I'm not sure what time you're talking about. The opportunity cost of having this wiki page is near zero, it's already written and would just need to be linked from home. I avoided mentioning 1.2 or linking to 1.2 branches so no links will go stale, and I'm not sure which step in this process would change to make it irrelevant.

[tresf]

Ask for help when you need to -- common sense

But where?

^--- Our wiki.

Decide what you'd like to work on -- well, of course.

But how? I think it's valuable to point people to "good first issue"s and the meta issues, as well as nudging them towards existing issues before they go and start a brand new, potentially duplicate or troublesome issue.

Then just add it! The existing page is there for a reason. Burying it in a 3,000 word article is the wrong way.

mixed with unrelated pages and "core architecture" is below the more specific pages for no reason.

Then fix it.

Create a pull request and await review -- common sense

To who?

Developers.

The opportunity cost of having this wiki page is near zero, it's already written and would just need to be linked from home.

Linked from the page you said needs improvement? 🤦‍♂️

As for time is [better] spent, I'm not sure what time you're talking about.

Well, it's the point of this post. This isn't a pep rally, it's a conversation about how to fix something.

[darkmastermindz]

Could we please just follow the Open Source best practices? https://opensource.guide/best-practices/

[DeRobyJ]

I believe this meta issue is a big step in the right direction.

I'd like to add a little suggestion, based on my personal experience with LMMS development!

I've always thought the best way to start developing for LMMS is by creating an instrument plugin.
I've tried following the wiki to write an instrument myself, but even if I'm on par with the required skills (as I've experimented with portaudio, VST SDK, and I wrote a max/msp object), I'm still unable to understand how plugins are made.

You see, those three real-time DSP libraries have something in common: the programmer writes the processing procedure, taking "double* ins" and putting "double* outs".
LMMS instruments are written differently, but I can't find out how they are written, where do I program my processing procedure, or how else I should work!

That's of course just my personal experience. But I do feel that wiki page is missing a required skill, or should explain how LMMS handles sound synthesis.

(I must say I'm not too familiar with Qt, though.)

[he29-net]

By the way, as for "prefer longer, descriptive names" -- what about the recommended 80 characters line limit? I just reformatted one of my main class files to 80 chars / line and frankly, I feel it is much less readable since the extra lines now start all over the place, disrupting the nice text flow otherwise created by indentation.

A quick search shows the limit can be dated back almost 100 years to old IBM punchcards (which seem to be based on even older dollar notes).
I doubt anyone is writing code on a 80x24 terminal these days and raising the limit to 100 or even 120 characters would be less likely to discourage the use of longer variable names, while still allowing to easily fit two windows side-by-side on a wide-screen monitor.

[tresf]

I feel it is much less readable since the extra lines now start all over the place, disrupting the nice text flow otherwise created by indentation.

Agreed. Please ignore that and feel free to edit it out. It's still convenient at times for certain environments, but it's no longer a requirement.

[JohannesLorenz]

* Celebrate! -- **not necessarily**.  Most reviews actually result in more work -- and worse, the target release may be a long time out!

So sad and yet so true! :smile:

Seriously... github recommends a CONTRIBUTING.md which will be at least shown on the community page. It should help contributors "verify that they're submitting well-formed pull requests and opening useful issues". We don't have it yet. Even if we had that page in the wiki, it's convention to have such a page outside of the wiki - in the main repo in CONTRIBUTING.md.

We could of course just create that file and write "Look into our wiki". The wiki start page may be suited for experienced devs, but imagine you've just a bit C++ experience, are a noob to git and github... Maybe you don't know what a PR is and that there's a nice IDE named "QtCreator" helping you to write code conforming to our conventions? Do you already know of the "good first issue" button? You maybe prefer having a cookbook which helps you to not forget anything, making your first PR a good PR.

When I came to github at ~2012 I read those github help articles where they explain how to add SSH, a remote etc. Of course, I could have googled all that, but the articles were fun to read and motivated me to start.

[JohannesLorenz]

LMMS instruments are written differently, but I can't find out how they are written

@DeRobyJ I'm not 100% sure what you mean. Did you already read our wiki article? Which is a bit out-dated, I'll need to add hints about LADSPA, Lv2 and SPA.

[JohannesLorenz]

In general, we should not decide things here in a rush. Please create separate issues and link them (or tell me and I'll link).

prefer longer, descriptive names

I prefer shorter names, especially for local variables. That's really something that requires a poll.

By the way, as for "prefer longer, descriptive names" -- what about the recommended 80 characters line limit?

What do the open source guidelines say? What do our other developers think? Maybe make an extra issue and I'll link it?

[Spekular]

If we're going to be discussing variable names, I have to say the m_name
standard for member variables has never felt all that useful to me.

On Sun, Apr 7, 2019, 20:24 Johannes Lorenz [e-mail] wrote:

In general, we should not decide things here in a rush. Please create
separate issues and link them (or tell me and I'll link).

prefer longer, descriptive names

I prefer shorter names, especially for local variables. That's really
something that requires a poll.

By the way, as for "prefer longer, descriptive names" -- what about the
recommended 80 characters line limit?

What do the open source guidelines say? What do our other developers
think? Maybe make an extra issue and I'll link it?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/LMMS/lmms/issues/4929#issuecomment-480616740, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIgVmpR3M1EulFxLJymRbJqTt9SQ9-kdks5vejf1gaJpZM4cZLi9
.

[DeRobyJ]

I'm not 100% sure what you mean. Did you already read our wiki article? Which is a bit out-dated, I'll need to add hints about LADSPA, Lv2 and SPA.

@JohannesLorenz I mean that the wiki article about LMMS Plugins doesn't actually say how LMMS will transform note events to audio.

The info I'm missing is where the signal processing function is, and in particular it doesn't introduce the programmer to PlayHandles.
NotePlayHandle.cpp says that it

manages playback of a single note by an instrument

And indeed any instrument plugin such as TripleOscillator does have a "playNote" function which takes NotePlayHandle and somehow instructs it on what to do (in 3xosc case, I understand it creates Oscillators which are able to play notes... still I can't find where the processing function is, where is the output written. However, I understand at this point it's internal core stuff that an instrument programmer doesn't need to know)

Yet, that wiki page makes no mention of PlayHandles or the playNote function, the programmers will have to learn how to use them themselves by looking at existing instrument plugins and reading the NotePlayHandle documentation.

With some research you can still find the info you need to understand how it works, but I do think something of it should be written on that page, as writing instrument plugins for LMMS is very different to writing VST or other popular real-time audio processing program.
(LMMS Effect plugins are more similar to those, as the have full control over the processing function. The difference is of course imposed by the need for polyphony in instruments, to my understanding)

---

This is nothing critical of course, my suggestion is based on my personal experience with the wiki, as a beginner DSP programmer. So maybe there's actually no problem and more skilled programmers will figure things out quickly enough. My point is that some programmers that do have the Required Skills mentioned on the page might still be confused after reading the wiki.

[musikBear]

but imagine you've just a bit C++ experience, are a noob to git and github... Maybe you don't know what a PR is and that there's a nice IDE named "QtCreator" helping you to write code conforming to our conventions? Do you already know of the "good first issue" button? You maybe prefer having a cookbook which helps you to not forget anything, making your first PR a good PR.

This ought to be a gospel!
If that thought was followed by action, it would with no doubt result in more devs.
I would like to see a dokument/ cookbook, that could guide a total noob through all the peripheral necessities: Github/ Bash/ QT/ Repositories
I think these thing overwhelm potential devs, and then they walk away, thinking "too much fuss, to even get started"

[JohannesLorenz]

Any opinions about Spekular's proposal above?

[tresf]

Any opinions about Spekular's proposal above?

If we're going to be discussing variable names, I have to say the m_name
standard for member variables has never felt all that useful to me.

Not a seasoned enough C++ coder to vote on this one, but some interesting discussions on Reddit about it: https://www.reddit.com/r/cpp/comments/4fxvqi/naming_convention_for_class_member_variables/d2d0twz/

Personally, I don't do this technique in any other languages, but those languages also use getters/setters mostly instead of friends classes, etc. Also, those other languages generally don't define in a separate (header) file, so I'm not sure my experiences/opinions are worthy of any constructive input.

[JohannesLorenz]

I meant, any opinions about Spekular's Contributing Step-by-Step draft?

(@tresf Thanks still, but please no variable name discussions in this thread, that would be OT)

[tresf]

any opinions about Spekular's Contributing Step-by-Step draft?

I think it goes to lengths to explain stuff that's part of contributing to any project, but that said, I would recommend just publish it. It's a wiki for a reason and -- like all wiki articles -- it can be improved as more people start using it.

• First, make sure it's referenced here: https://lmms.io/get-involved/
• Second, it should be mentioned in the ISSUE_TEMPLATE.md (e.g. CONTRIBUTING.md) https://github.com/LMMS/lmms/pull/2348#issuecomment-344505973

[JohannesLorenz]

@Spekular I've added some things and shortened many paragraphs. Can you please check if you're OK with the changes?

When we are more sure about, I recommend moving the whole file from the wiki into our CONTRIBUTING.md .

[tresf]

When we are more sure about, I recommend moving the whole file from the wiki into our CONTRIBUTING.md

CONTRIBUTING.md should be short and concise and should only change when needed.

Our wiki on the other hand should be fluid and change often. Keeping a source file identical to our wiki causes unnecessary commits to our codebase. One option is to add the wiki as a submodule, but then the wiki commit will need to be bumped periodically. The advantage to this approach is all of the documentation will be available offline for tarball users, etc. What I feel we need to avoid is using a GitHub-specific workflow file to bombard contributors with info.

[musikBear]

any link to this CONTRIBUTING.md -I would lik to read it.

[tresf]

any link to this CONTRIBUTING.md -I would lik to read it.

No, it doesn't exist, but I strongly suggest to avoid TL;DR because then we risk the chance of it being TL;DR.

[JohannesLorenz]

Keeping a source file identical to our wiki causes unnecessary commits to our codebase.

I was recommending to move the info from wiki to code, not copying. Redundant info is pointless.

One option is to add the wiki as a submodule, but then the wiki commit will need to be bumped periodically.

On master, the wiki is already a submodule. I think it was you who added it :smile:

What I feel we need to avoid is using a GitHub-specific workflow file to bombard contributors with info.

Can you please elaborate? We are on github, so we cannot avoid github workflow in the document.

[tresf]

What I feel we need to avoid is using a GitHub-specific workflow file to bombard contributors with info.

CONTRIBUTING should be a guideline (or checklist), not a procedure.

[musikBear]

@tresf
..Remember you told me not to use abbreviations?

No, it doesn't exist, but I strongly suggest to avoid TL;DR because then we risk the chance of it being TL;DR.

whut is TL;DR
'Here' is would mean 'Send to Danmarks Radio' but 'to' would be mispelled (TiL)
Nahh no reason for reply..
Google says: Too Long. Didn't Read
But adds :

"Frequently used acronym by lazy, ignorant people in Internet Forums, where their urge to type something exceeds their ability to read"

Outch.. Raw -> rude explanation me think :p

[tresf]

"Frequently used acronym by lazy, ignorant people in Internet Forums, where their urge to type something exceeds their ability to read"

Correct. Trying to avoid a problem where we have:

lazy, ignorant people in Internet Forums, where their urge to type something exceeds their ability to read"

One may argue that we don't want these types of people contributing, however, those may also be the very people that really need a simple outline for contributing. Regardless, quick and concise wins when writing rules if they're expected to be read.

[tresf]

Thought this was friendly to newcomers; found it on AdoptOpenJDK's new bug tracker:

🆕🐥🐶 First Timers Only
This issue is reserved for people who never contributed to Open Source before. We know that the process of creating a pull request is the biggest barrier for new contributors. This issue is for you 💝

👾 Description of the issue
At several places the translator is used to get a translation for a message that should be logged or used as a message for an exception. This should be removed and plain Strings should be used for logging and exceptions.

Example:
LOG.debug(R("RFileReadOnly")); or LOG.debug(Translator.R("RFileReadOnly")); should be refactored to LOG.debug("File is read only");

📋 Step by Step
🙋 Claim this issue: Comment below.
🍴 fork the repository in github by simply clicking the 'fork' button.
⤵️ check out the forked repository
🔀 create a feature branch for the issue. We do not have any naming definition for branches.
💾 Commit your changes.
🔀 Start a Pull Request.
🏁 Done 👍 Ask in comments for a review :)
🔬 If the reviewer find some missing peaces or a problem he will start a discussion with you and describe the next steps how the problem can be solved.
💥 you did it! We will merge the fix in the master of the IcedTeaWeb project.
💐 Thanks, thanks, thanks for being part as an open source contributor for IcedTeaWeb
🤔❓ Questions

You can join our community chat at Slack

[PhysSong]

Make master branch spit out nightly builds, treat master as the preferred version for power users and developers. (requires releasing 1.2, automating the release system for master)

I think we can start working on this. Should I open a separate issue to track this? @Reflexe @tresf

[benstefanovic]

It would be great if all the dependencies were fetched automatically, as I'm struggling to build LMMS due to missing CMake scripts, specifically those for XCB, even though I have the right package installed.

Edit: Fixed this issue by installing libxcb-util0-dev on Ubuntu 18.04. Might need to add this to the 'Compiling' wiki page.

[tresf]

It would be great if all the dependencies were fetched automatically

This is easier said than done. Some dependencies are large and complex and require platform-specific commands.

That said, some dependencies are submodules and we do try to fetch them. We have a #support and #devtalk channel on Discord that's a good place to ask for help. The devs are very friendly. If there's a bug in our documentation, we try to fix it right away.

[curlymorphic]

A few comments from a previously active dev, Issues I can see that would be discouraging to new devs wanting to contribute to LMMS.

• Outstanding pull requests, having a look at this list, it is very long, full of comments like "need review", "needs testing", some of these are outstanding from 2016, I would assume some of these also suffer from bitrot. I would suggest if these are not to be merged then maybe closing would be a good idea, the current list does not look attractive.
• 
  
  
  
  • The duration between releases is HUGE, most people are more enthusiastic if they feel they will see the results of there contributions, a 4 to 5 year release cycle is not attractive.
  
  
• 
  
  
  
  • Maybe it could be stated that a knowledge of dsp development is not essential, from my experience a lot of work simply involves the UI not working as expected, this may lower the barrier to entry.
  
  
• 
  
  
  
  • Stop removing developers' names from the involved list, as stated "Contributors ordered by number of commits" the current windows download from lmms.io shows the below, out of the top 4 contributors, 3 names have been removed, and one shuffled down the list. Actions like this are not the way to encourage new members of the team. This list also does not reflect the efforts of many others, that do not contribute code but have a large impact on the ecosystem, such as support, "Best of LMMS", moderating the discord server, documentation etc, I feel all should be credited, or all names should be removed.
  
  
• 
  
  
  
  • 
  
  
• 
• 
  
  
  
  • Development on Linux only, LMMS is a cross-platform audio application, it is very common for devs not to use Linux, from my recent observations in other discord channels the norm would be developing on mac's, or maybe windows.
  
  

I am aware this post may not appear to be too proactive, however, I feel the points are valid.

[michaelgregorius]

Another previously active developer here.

I agree with most of what @curlymorphic wrote, especially with the comment regarding the duration between releases.

Let's take the following pull requests as an example:

• Pattern names difficult to read: https://github.com/LMMS/lmms/pull/3691
• Draw notes as rectangles and only move them below the text label at small heights: https://github.com/LMMS/lmms/pull/3699

I invested several hours/days of work into these pull requests because I think that the changes improve the usability for the user and also make the software look more attractive to users. The pull request have been merged to master in 2017, so almost three years ago, but still haven't found their way into a stable release so that users can actually benefit from them. It's also not clear to me when they will be integrated into a stable release.

So one proposal would be to add a road map where developers can see the planned releases and also get an idea of what branch they use as the basis for new features/bug fixes.

Another proposal obviously would be to have shorter release cycles. I think it's much more attractive to develop on a software where the underlying assumption is "This will already be available to users in the next Ubuntu release" instead of "I don't know if users will ever see what I do here."

Would it make sense to plan and sync LMMS releases with the Ubuntu releases (or any other big distro)?

So to sum up I have two proposals:

• Add a road map.
• Sync LMMS' release cycles to one of the big distros.

[Spekular]

Not to get too off topic, but @michaelgregorius I've been using a build with your pattern rendering for so long I forgot it wasn't in stable. Among users in the Discord, I know there are at least a handful others who also use master builds as their main version.

With this in mind I wonder, would nightly builds alleviate your concern (that users may not see the results of your work for a long time)?

[tresf]

Anything that adds overhead such as a Democratic process and leadership is going to suffer when there's no dedicated leadership.

It's my opinion that master needs a nightly release system, so that people can use the product with all features.

Unfortunately many of those that managed releases process are less active, so even the process of offering downloads has suffered.

1. Nightly (or at least a manual build/upload)
2. Dedicated area on the downloads page

This would get master features in people's hands immediately. Eventually if master becomes more useful we can embrace a highly active build as our best offering, only branch off for stable when we're about to make a major change

That's my opinion. More builds from bleeding edge more frequently.

[michaelgregorius]

Hi @Spekular, hi @tresf,

I think having nightly builds for master might be a step in the right direction. This would enable interested users to check out new features and it might also result in more feedback with regards to these new features.

[tresf]

Some progress on a continuous build has been documented here: #3347. Like many other things, it's years and years old.

To make sure builds in the wild aren't mislabeled @iansannar and I worked successfully on getting the branding sorted here #5166 and it's come along nicely but stalled at the final stages (my fault).

Unfortunately, I don't have the experience with the Circle-CI uploads nor the PHP/twig experience with the downloads page to make this happen in a timely fashion. I can commit to the branding stuff and help make decisions about how the releases area will be maintained, but I'd need help from someone more familiar with auto-publishing (e.g. @lukas-w @liushuyu @Reflexe).

I'd argue this effort of nightlies is actually more important than the release of stable-1.2.2 because developer engagement and appreciation brings more features and fixes more quickly. Keeping around developers means more people to help test/review/merge and should snowball into progress.

Anyway, I'm willing to help where I can with this. I didn't have time back then but now I do. Also happy to continue the discussion in #devtalk.

[musikBear]

I will just add my bend nickel and then you can ignore it
Official releases twice a year

• One at midsummer
• One at Christmas
  Nightly builds, for dev purpose only (bug hunt and reviews)
  Biannual off releases would create a buzz and build up excitement in the community, and at least the Christmas-release would be like a seasonal gift :p
  I suppose Druid's & Asa-belivers in the community would receive a Midsummer release as a gift too..
  Last release has +5o new features. I doubt everyone even know all of them at all..
  If the biannual release had ~5 new features, then it would be suitable imo.

[tresf]

Please don't tell the few volunteers here when to release a version. Releases are based on stability and features, not Christian holidays.

[ttepatti]

Just pitching in to say - as an active user who occasionally files GitHub issues but doesn't have much development experience, I'd love to check out nightly builds. I see mention of a lot of awesome features that are fixed in the next release and I'd love to get my hands on them and test drive them early :)

[lukas-w]

I can commit to the branding stuff and help make decisions about how the releases area will be maintained, but I'd need help from someone more familiar with auto-publishing

@tresf I wouldn't call myself familiar with auto-publishing but I'd like to help. Can you give me a short overview of the current status and what exactly would need to be done? I haven't been following the project's progress lately and I'm quite out of date especially with CI and website changes.

[tresf]

Can you give me a short overview of the current status and what exactly would need to be done?

High level:

• Each commit to hit master that yields a successful build gets uploaded to a Nightlyrelease area on Github.
• Downloads page receives a new Nightly button/area

For consistency purposes, we should match branding between downloads page, github release tag and in-app branding. https://github.com/LMMS/lmms/pull/5166/files#diff-fbae549c95b393e3b412d5cd08b02112R65

At the time of writing this:

• Stable (e.g. 1.2.2)
• Beta (e.g. 1.3.0-RC1)
• Nightly (e.g. 1.3.0.1234)
  
  
  
  • #5166 uses "Unknown"? Probably needs fixing
  
  

Low level:

• Each CI needs to be adjusted to upload binaries
  
  
  
  • Travis-CI
  
  
  • AppVeyor (optional, not sure where we place these)
  
  
  • Circle-CI
  
  
• If an upload fails, the nightly area should retain the last uploaded binaries
• The stable release should always appear above nightly in the download page listing

[Veratil]

• Each commit to hit master that yields a successful build gets uploaded to a Nightlyrelease area on Github.

As in a single nightly image or multiple per commit that day?

[tresf]

As in a single nightly image or multiple per commit that day?

For simplicity, I'd say each commit to hit the branch. I realize this may be undesired when devs are going on a merge-spree, but any other design requires a separate process to fire the build, so it's a bit of a toss-up.

[Veratil]

For simplicity, I'd say each commit to hit the branch. I realize this may be undesired when devs are going on a merge-spree, but any other design requires a separate process to fire the build, so it's a bit of a toss-up.

Actually this might be beneficial to quickly find regressions. If the previous nightly didn't have it but the latest does, and there are 5 commits between, that would help bisecting quickly. Perhaps we should keep the past X days of nightly builds.

[tresf]

Perhaps we should keep the past X days of nightly builds.

Assuming we manage it as a release in GitHub, keeping these wouldn't be trivial. We can do it, but it would require a rotation process.

[tresf]

Rotate brainstorming...

If we choose rotation, a proposal is to use non-numeric placeholders...

• continuous-apple 🍎
• continuous-lemon 🍋
• continuous-peach 🍑
• continuous-grape 🍇
• continuous-melon 🍉

A slight downside to this is lmms/lmms/releases will show these 5 items before stable. An alternative is to use a single release and use the filename as a filter.

[liushuyu]

A slight downside to this is lmms/lmms/releases will show these 5 items before stable. An alternative is to use a single release and use the filename as a filter.

Looking at other projects that I have contact with, it probably doesn't hurt to have another repository to just store the nightly builds: https://github.com/yuzu-emu/yuzu-nightly vs https://github.com/yuzu-emu/yuzu.

[russiankumar]

Hey!

As a new developer who recently started to contribute, I'd like to throw in my two cents on some things that I (and probably other new coders like me) would like to see, and what I believe is good in the current system.

Pros

• At least for me, it is easy to get questions resolved such as which functions to use, where to find certain files, etc etc both in the PR and on Discord. Everyone appears friendly and willing to help. I believe this in general gives new devs a positive attitude towards developing.
• After a review, the reviewers usually do guide you in where to go next to solve the problem they found. As someone becomes more experienced in the code, the dev tends to be able to solve the problems themselves, however for us newer devs, such guides really do help us a lot.

Cons

• Sometimes reviewers take a while to come back to PRs. I've been lucky to have quick responses from reviewers, but looking at other PRs, it seems that it's not always the case. This leads to PRs taking months to be finally completed, which has been discussed here already. This, however, could also be laziness on the side of the coder at times, so I think this con isn't something that can be "solved".
• It's not exactly the easiest thing on earth to start contributing. Though yes, support is offered once you begin coding, starting to code may be tough due to lack of enough documentation on the wiki (which is where we are pointed to to start coding). I think that at least some form of documentation would be good to be pointed to alongside the wiki entry so that devs aren't forced to scour the code for what they need.

A note: about the first con, I do get that reviewers also have a life and are busy with other things, which is perfectly acceptable. I'm talking about having to wait weeks (or apparently months, for some of those old PRs) for a review of any sort.

No offence is intended here, and I hope this is helpful.

[Spekular]

This has been stale for a while, so hopefully you don't mind me temporarily unpinning it to pin a "no new PRs" issue.