Open tresf opened 5 years ago
qnebra
commented
5 years ago I think this https://github.com/LMMS/lmms/issues/4554 is very, very related to this topic. Especially for lmms users with external controllers like me.
Because for now lmms workflow with external controllers isn't as good as it should be.
tresf
commented
5 years ago @qnebra that sounds like a legitimate bug.
tresf
commented
5 years ago @qnebra you sent me a PM on Discord and I want to be more clear. Your bug affects workflow (all bugs do), but it's not a "nice to have" feature, it's a legitimate bug and should be tracked as such.
Quoting the bug you've linked:
it works, only if you disconnect "volume" from "mod wheel".
I want to keep the legitimate bugs open in our tracker so that they're easier for developers to find, assign and work on. The features above are related to items -- in most cases -- completely missing from LMMS and are better left in a meta issue so that there's a bird's eye view of demand and related issue. I hope that helps!
claell
commented
5 years ago @tresf I like the idea of having meta issues (although tags might also do a good job for this particular problem), but the current way of doing this does not look "right" to me. ~Why close issues linked here and mark them as duplicates?~ The "normal" way I am used to is to use labelling to distinguish between feature requests and bugs, so they can coexist in an issue tracker and are only closed when implemented.
Edit: Seems like I misunderstood things a little bit, thought all issues linked here are closed.
tresf
commented
5 years ago @tresf I like the idea of having meta issues (although tags might also do a good job for this particular problem), but the current way of doing this does not look "right" to me. Why close issues linked here and mark them as duplicates? The "normal" way I am used to is to use labelling to distinguish between feature requests and bugs, so they can coexist in an issue tracker and are only closed when implemented.
Edit: Seems like I misunderstood things a little bit, thought all issues linked here are closed.
@claell Thanks for the feedback. I'm not aware of another way to cleanup 800 bug reports. Even with the above 100 bug reports, there are still over 600 still open that we need to sort through. Notice many already have 2, 3, or 4 duplicates! Other projects (like Ubuntu) simply blindly close out bug reports when they EOL a product, I feel this technique is better and I hope this approach is better received.
Moving forward, we'll have better bug submission standards which should help avoid duplicates as well as encourage people to open PRs instead of bug reports for minor changes.
claell
commented
5 years ago Hm, maybe I am just not really understanding what this is for.
In general my opinion:
If these 800 bug reports / feature requests are actually not solved already then they shouldn't be closed, but maybe they are solved already or not relevant anymore. But maybe they are so "small" that it is not worth to have issues for every single one of them.
I guess the real problem is that on the development side there is too less "power" to keep up with the speed of new issues appearing.
there are still over 600 still open that we need to sort through
Maybe a better tagging can be used (or leave them open). I am not a fan of closing not solved issues, but maybe that is the most effective way.
Other projects (like Ubuntu) simply blindly close out bug reports when they EOL a product, I feel this technique is better and I hope this approach is better received.
Maybe I misunderstood this a bit, but I think there is nothing EOL here?
Still better than blindly closing things, so thanks for taking the effort to go through all these issues.
tresf
commented
5 years ago Maybe I misunderstood this a bit, but I think there is nothing EOL here?
Neither is there (EOL) with Ubuntu, that's the point. Most trackers force bug submitters to file against a "supported" OS version and then close them out blindly (no human review at all) when the OS reaches EOL. Many trackers do this. Trackers like JIRA can do this and they put the burden back onto the submitter (they notice the bug was closed incorrectly, they have to reproduce and re-file).
The problem with LMMS isn't the bugs though, it's actually the enhancements. The bug tracker is being misused as a wishlist and for a product with only a few maintainers and over 2 million users, this is a problem. Rather than tracking these requests as "open" it's more honest to ourselves to focus on what the project needs first.
For example... Take this rant into consideration... I'm typing this RIGHT NOW just off the top of my head...
The playback position head of a track sucks. The stop button should jump back to beginning, always!The pause should ALWAYS PAUSE, NOT STOP. The cursor should be consistent across ALL editors. Why isn't there a cursor in the Beat/Bassline editor? Why can't I click "pause" from the mixer? Why isn't there a visual indicator of the channel the track I'm working on is routed through?
These issues are fundamental flaws (or limitations) with the UI and the inconsistencies introduced over years and years of volunteer work. They were never design choices, but they can, will and have spun into dozens of bug reports all pretty much stating "do it like Ableton does" :)
Our permanent solution is to provide very strict submission guidelines (with a separate template for enhancement and bugs).
I am not a fan of closing not solved issues, but maybe that is the most effective way.
The first step to cleaning up junk a mess is to put it in a big pile and decide what to throw out. That's what we're doing and we need help. :)
claell
commented
5 years ago Neither is there (EOL) with Ubuntu, that's the point. Most trackers force bug submitters to file against a "supported" OS version and then close them out blindly (no human review at all) when the OS reaches EOL. Many trackers do this. Trackers like JIRA can do this and they put the burden back onto the submitter (they notice the bug was closed incorrectly, they have to reproduce and re-file).
I haven't experienced this with bugs on Ubuntu, so I don't really understand what you mean, but I guess it is not that important.
misused as a wishlist
Well, of course you can decide what to use the issue tracker for, but in most projects the issue tracker is actually used as a wishlist without problems. I wouldn't speak of a misuse in that case. This just results in many open issues, but there is nothing bad about that imho, because you can filter for bug tagged issues.
Rather than tracking these requests as "open" it's more honest to ourselves to focus on what the project needs first.
Imho focusing can be done without closing them.
Our permanent solution is to provide very strict submission guidelines (with a separate template for enhancement and bugs).
Sounds reasonable. I created #4889 to create them.
tresf
commented
5 years ago I created #4889 to create them.
Thanks. @lukas-w already created a PR for this. Can you provide your assistance there so that it's centralized? Also, please search before creating new issues. 😉
Imho focusing can be done without closing them.
... and do what exactly? Pick a "good" bug, paste the other ideas into it and make it appear like it was written by the OP? We've been doing this right along and it's actually worse. The pruning is happening and it's going to make the tracker easier for the developers. If there's one that really needs reopening, please request it. Ideally, we'd have more people helping with these in general but they require a holistic understanding of the software, which is usually best corralled by a developer, tester, or power user.
tresf
commented
5 years ago but in most projects the issue tracker is actually used as a wishlist without problems
Not true. Projects with a large user-base and low-quality submissions (like openjdk) just block end-users from submitting.
I haven't experienced this with bugs on Ubuntu, so I don't really understand what you mean, but I guess it is not that important.
It may be a bad example but trackers do this, I just don't have an example, and I'm losing time to find one.
claell
commented
5 years ago Also, please search before creating new issues.
I know, I know, only searched the issues, not the PRs :smile:
... and do what exactly? Pick a "good" bug, paste the other ideas into it and make it appear like it was written by the OP? We've been doing this right along and it's actually worse.
Why is picking a "good" bug needed? Imho the workflow is the following:
Not true. Projects with a large user-base and low-quality submissions (like openjdk) just block end-users from submitting.
I said in most projects, in your example that might be true. So maybe we are both true in our points, while your point is probably more relevant.
It may be a bad example but trackers do this, I just don't have an example, and I'm losing time to find one.
No problem.
tresf
commented
5 years ago Many small feature requests, might get overwhelming, so put them in meta issues and / or use tagging
This bug report is a step in that direction. We've already closed about 100 bugs. We need to do 600 more and then we can talk about how big this mess is and what to with new meta issues moving forward. We're reading every bug report in the process and trying to find a home for it. Many of these bugs were opened by developers, and they're OK with this too. Cleanup always looks worse before it looks better. :)
claell
commented
5 years ago Yes, but I meant without closing them :smile:
Reasons for leaving them open:
Cons:
tresf
commented
5 years ago There will be probably be discussion there if a developer decides to implement a feature from this list
We don't lock bugs, this can still happen.
That way the issues can also be found when going through open issues
No one goes through 800 issues. I agree it's hard to decipher open from closed, but that's solved in "what to with new meta issues moving forward" portion above.
It just feels wrong to me to close not implemented issues with maybe relevant discussions
Agreed but as a maintainer, it feels worse to have a bug tracker that at its current growth rate will have thousands of bugs, many being duplicate or describing a feature that won't be coded for years to come. It's misrepresentative of the contributors and the tracker is meant for developers.
claell
commented
5 years ago We don't lock bugs, this can still happen.
I know, but usually closed issues aren't discussed that much.
No one goes through 800 issues
I know but with decent tagging there won't be 800 issues to go through but only a few. For example if someone searched open issues with the tag starter.
thousands of bugs
I don't see the difference of having them "pseudo"-closed or opened to this problem.
many being duplicate
Than they can be closed?
describing a feature that won't be coded for years to come
That is normal and should not be bad. Also I think one could introduce a tag for that to filter them out, if possible or put all relevant issues into milestones to get rid of "utopic feature requests" for the current development process.
the tracker is meant for developers.
Should be the priority, but not only. And I really don't see what is improved for the developers when closing those issues in comparison to leaving them open. To me that is maybe only a psychologic effect.
tresf
commented
5 years ago don't see what is improved [...] only a psychologic effect.
This is just more arguing of the same point. The reasons are clearly outlined and explained.
claell
commented
5 years ago The reasons are clearly outlined and explained.
Well as far as I know, you never really explained what is bad about open feature requests, also I elaborated, why they are not bad. But ok, you can decide and it actually is not that bad to close them, so I won't ask for explanation any further and accept that you want to have this in that way.
Still my offer for help stands. This will probably require to add me to the LMMS team, which might be a bit fast from your perspective. If you need any references, some sort of interview etc. let me know.
What I would do / propose is to go through the remaining open issues and assign feature requests with more detailed tags like piano-roll, song editor, mixer and effects etc. Those tags might not be perfect at start, but can be renamed or agglomerated in a later effort. That would allow you to filter through those tags in order to agglomerate those issues in this meta issue.
tresf
commented
5 years ago What I would do / propose is to go through the remaining open issues and assign feature requests with more detailed tags like piano-roll, song editor, mixer and effects etc. Those tags might not be perfect at start, but can be renamed or agglomerated in a later effort. That would allow you to filter through those tags in order to agglomerate those issues in this meta issue.
Tags can help find a particular issue if that's what you're looking for, but they're not holistic. Holistic coding requires knowledge of the codebase and corralling of issues. With 800 issues falling into 10, 20 or 50 different categories, tags can become busy work that results in the same mess.
Still my offer for help stands
Observed efforts are concerning. For example, choosing to rename internal names/files (#4890, more work for developers). Furthemore, making an issue -- this issue, an organized effort to consolidate bug reports -- a home for endless conversation is detrimental has historically proven detrimental to productivity.
We can discuss more on Discord. Familiarizing yourself with the team would help.
claell
commented
5 years ago Tags can help find a particular issue
Yes and they can also help sorting issues, find duplicates etc.
but they're not holistic.
I don't understand what you mean with that.
corralling of issues.
I'd be interested in a source for that statement.
falling into 10, 20 or 50 different categories, tags can become busy work
Well, it will be work, but that work has to be done anyway. And regarding your repeated "mess" statements, have a look at
https://gitlab.com/gitlab-org/gitlab-ce/issues
and how they handle their bunch of issues. To me it looks like it works for them and I don't see a reason why it shouldn't work here.
concerning
Sad to hear that.
choosing to rename internal names/files
I asked @SecondFlight before, so please stick to the facts.
a home for endless conversation has historically proven detrimental to productivity.
Again, please stick to the facts. I contacted you via Discord just because I did not like to discuss this in this GitHub issue. You told me the discussion should be ~continued on GitHub~ public, I assumed you wanted it here and you never complained before. I don't like how you now give this back to me and insult me like this was my fault.
We can discuss more on Discord.
Alright.
tresf
commented
5 years ago You told me the discussion should be continued on GitHub, here we go
No, I said "public".
I asked @SecondFlight before, so please stick to the facts.
I'm not sure what this is in reference to. Regardless, these types of ad hominem replies quickly become toxic. Feedback about the renames were made in the relevant bug reports.
In regards to holistic and corralling, it's about overall view of the project (how it's progressed, how it will progress, what the necessary resources are to continue progressing). It's about combining related items as well as... and this part is very important... the unnecessary specificity of requests that are trivial (i.e. Items that explain basic improvements that are common sense to any UI developer, just lack the hours and hours of coding, debugging and testing to roll into a future release. Furthermore, items that have no intention to be worked on are pointless to be in "open" state. Different projects have different opinions on this, but I'm not sure GitLab is a good example. 1. They're commercial, we're not. 2. They have 33K issues, one of which is that with that many issues, searches result in a 500 error. Ouch.
Anyway, we're not trying to discourage help, but spending this much time arguing the Open/Closed state of a bug that the project actually cares about is a classic example of Parkinson's law of triviality.
Gabrielxd195
commented
5 years ago This is great!!. Having all the problems listed and organized is the best. although I have been able to observe some even greater problems:
I know that stability and launch are not the central theme of this thread, but if these affect stability, therefore affect the work flow, therefore in my humble opinion, I suggest:
I understand that no improvement is '' simple '' to develop and that it will take time, but if the project is organized in this way, the improvement of work flow and all the development of lms will be faster. over time the list will increase but if we take into account the order of priority of the improvements, it will be better for everyone. regards
SecondFlight
commented
5 years ago I appreciate your input, but please allow me to correct some of what you've said, as your premise is largely inaccurate:
There are many errors and improvements and the list is increasing.
Indeed, this is what the list is meant to help with. Our issue tracker is unbelievably bogged down, mostly with well-meaning enhancement requests. The primary goal of this list is to concentrate the mess into one place and allow us to close issues with lower priority. This list is getting bigger, but each time an item is added to this list, it is closed on the tracker.
The improvements are being released in test versions (RC)
This is not true. There have not been new features added to the release candidates in over a year. All changes to the RCs are bug fixes.
The release of stable 1.2 was delayed.
This is because there have been a lot of bugs worth fixing.
This list is not a list of must-have features that we plan to implement. This list simply represents an effort to clean up our tracker. Every feature on this list has been open in our tracker for some time, but the act of moving these features here doesn't mean we plan to implement all or even any of them.
Organize the improvements in order of priority.
This is a good idea. At the end of the day, priority will be decided by whoever actually does the work of implementing a feature. We won't complain if another developer doesn't agree with our priority and implements a low-priority feature or bugfix. Still, I think prioritizing issues is a great idea.
Veratil
commented
5 years ago Not sure if this is the right place to comment for this, but I wanted to better organize, format, and generally prettify the Coding Conventions page for easier reading. Are we still wanting to have that page? I do see some other PRs now for clang-format and clang-tidy, but I'm not sure where things are going with it.
I did go ahead and make a prettified version here (with extra stuff at the top to make sure I covered things) in case we want to update. I figured using RFC style requirement keywords would be best to describe what rules could be bent or not.
tresf
commented
5 years ago Not sure if this is the right place to comment for this
Thanks. It's not, really.
This thread is for software workflow (not developer workflow). Probably better for the "how to keep programmers" threads.
The organization of topics in the new version is nice. The capitalization and italics for words like NOT (does the RFC recommend this sillyness?) aren't needed (I don't even see this weirdness in license agreements, where there's legal action). Anyway, the fact that you've taken the initiative to help the project means something to us, you can start editing it any time. Just ping someone one #devonly on Discord for access, linking this comment.
Veratil
commented
5 years ago Not sure if this is the right place to comment for this
Thanks. It's not, really.
I was going to comment on the closed Coding Conventions issue, but I'm not sure how y'all like commenting on closed issues, and you stated from that one that this superseded it.
The capitalization and italics for words like NOT (does the RFC recommend this sillyness?) aren't needed (I don't even see this weirdness in license agreements, where there's legal action).
That was my choice, RFC only states they are "often capitalized". I wanted to put emphasis on them to make them stand out. It can easily be removed. 😁
Anyway, the fact that you've taken the initiative to help the project means something to us, you can start editing it any time. Just ping someone one #devonly on Discord for access, linking this comment.
Sounds good! Thanks.
musikBear
commented
4 years ago a comment on
Make "My Home" user definable in settings #1130
Presets saved as xpf-files has path to the instrument hard-coded in the file. It does not matter for LMMS-instruments, but it does for VST-presets
plugin="H:/LMMS/presets/VST/DSK techsynth PRO/DSK TechSynth PRO.dll"
This is a problem when
Why not have that path dynamically linked to a path in Settings, then this problem would be gone
tresf
commented
4 years ago Presets saved as xpf-files has path to the instrument hard-coded in the file. It does not matter for LMMS-instruments, but it does for VST-presets plugin="H:/LMMS/presets/VST/DSK techsynth PRO/DSK TechSynth PRO.dll"
The VST relative path logic is only coded for the samples directory. Please use that instead of the presets directory. A DLL is not a preset and shouldn't be organized as such.
musikBear
commented
4 years ago The VST relative path logic is only coded for the samples directory
@tresf You mean that VST-instruments dll-files is meant to be in the Samples directory? Eg :..\Documents\lmms**samples** There? Sorry but that is not intuitive for me. SF2' could be regarded as a kind of 'samples', but VST-dll's files, UI-files and banks?
What is the logic behind that idea, and when (version) did implement that ?
tresf
commented
4 years ago I wrote it a while ago because the relativize logic was already written for samples, scaled well to SF2 and and there was no dedicated "plugins" folder yet so we added the logic to VSTs as a stop gap.
Note, VST effects use a different folder that's configured in the settings
musikBear
commented
4 years ago @tresf Understood! Thanks for explaining.
VMan-2002
commented
4 years ago i want to loop segments please
musikBear
commented
4 years ago @tresf -Note "humanization" #1165 is done (No PR yet) But maybe it should be marked 'in progress' or 'done' idk how you normally do that. Implementation: https://www.youtube.com/watch?v=jlQo5lVIbEU
tresf
commented
4 years ago @musikBear great news, thanks for the update. I'll reopen, assign and change to in progress.
musikBear
commented
4 years ago In respect to
New default shortcuts (table) formerly (Hash)1488
I want to give a heads-up: I have used '+' and '-' in piano-roll for resp. elongating, and shorten selected notes, with a simple keypress. (Implements #3138)
Spekular
commented
4 years ago A lot of the "closed" issues under the 1.3 milestone are actually consolidated here. In order to make it easier to see what's left to do in the milestone, I've added annotations to all the items on this list that have a milestone.
ryuukumar
commented
4 years ago tresf
commented
4 years ago @russiankumar it's marked as in-progress with that PR mentioned. Once it's merged, yes, we'll check it off, thanks!!!
ryuukumar
commented
4 years ago
- [ ] Proposal to use >> as default playhead behavior
#3740- [ ] Stop and return |<< versus "pause" default behavior
#3740[Milestone: 1.3]
The first one (maybe the second too) has been fixed, update?
Spekular
commented
4 years ago Done!
Spekular
commented
4 years ago I've added song editor groups to this since it "seems workflow related AND won't be closed by a quick patch", and added #5726 as a sub-item (It's a bit of a weird feature and would become largely redundant if we had groups). I'm hesitant to close #735 though, so I'm leaving it open for now but don't have any objections if someone wants to close it.
ryuukumar
commented
4 years ago
- [ ] Better track color support #1006 #1160 #1176 #2332 (in progress: #5573)
It's complete now, could you cross it off the list?
tresf
commented
4 years ago It's complete now, could you cross it off the list?
Done.
craslaw
commented
3 years ago I've started work on #879. Can the original issue be reopened? I am taking the time to implement resizable rubberband selections where applicable instead of just fixing the cursor.
zonkmachine
commented
3 years ago @craslaw sure!
IanCaio
commented
3 years ago I've started work on #879. Can the original issue be reopened? I am taking the time to implement resizable rubberband selections where applicable instead of just fixing the cursor.
@craslaw Maybe you should wait until #5524 is merged, as it changes the logic and method that changes the cursor during TrackContentObjectViews mouse events. IMO it might make it even easier to fix this small issue with the resize cursor being used, as I think it's only a matter of adding a conditional to check if there are multiple selected TCOs.
Rossmaxx
commented
2 years ago @tresf can you update the list. i feel that a lot more of it has been fixed.
Spekular
commented
2 years ago @tresf can you update the list. i feel that a lot more of it has been fixed.
Please don't do this unless you have specific issues in mind to be added or checked off.
Rossmaxx
commented
2 years ago i mean just to update the check marks. it feels like he didn't update it for a long time and around 80% of the issues seem to be closed.
Spekular
commented
2 years ago For our meta-issues the open/closed status of a child-issue does not determine whether or not the issue is resolved. Closing issues when we consolidate them lets us keep the open issue list a little more manageable. If you would go look at some of the recently consolidated issues you'd see this in action, they're marked as closed but not resolved.
This means the list is far from 80% complete and there are no updates to be made unless you can name a specific issue and the merged PR or commit that resolves said issue.
tresf
commented
2 years ago @tresf can you update the list. i feel that a lot more of it has been fixed.
Sorry, if you look at the edit log, this issue is now maintained by Spekular and others. As instructed, any specifics that need updating, let us know. This bug tracker is huge and maintaining it is a lot of work, so the more specific the better. ♥️
I'm creating a meta issue for better UI/UX workflow. This list should be updated frequently because it's the source of many of our new bug reports. If a new bug report arrives that seems workflow related AND won't be closed by a quick patch it can be marked as a duplicate and placed here.
Since workflow is so important to users -- something they can directly relate with -- this can also help serve as a futuremap if the developer team is to start milestoning certain enhancements (something we don't do a great job of currently)
Lastly, it can serve as a birds-eye-view (so to speak) of what our users really want. ❤️
💥 = Bug 🚀 = Good first issue for new developers
See also:
Tracks
Song Editor/Beat+Bassline Editor
>>as default playhead behavior #3740|<<versus "pause" default behavior #3740 [Milestone: 1.3]Piano Roll Editor
Automation Editor
Instruments
Internal
meta) [Milestone: 1.3]External
Mixer and Effects
dBindicators #1213 #4458Files and Folders
Misc/Overall