I am sure to remember one of those was fixing compositor bugs. Because those bugreports were the oldest.
And I think the other one was Hair but I may be wrong about that one.
Multi Texture Layer Editing and Compositing
5 Likes
what is the tracker curfer?
I did not understand clearly,
Developers and volunteers will focus on bugfixing until they have reached less than 200 open bugs on the traker?
Does this mean that all development work will be stopped, including the patch submission? 
the posting to bf-comitters has some more details
Hi,
On Monday, Blender begins a tracker curfew.
Please check the teaser video: https://www.youtube.com/watch?v=HDE2ARiN1a0A more complete document will follow suit, but the gist is: from now on the
Blender Foundation is going to adhere to a strict definition of what a bug
is.
- It is only a bug if the code was intended to work and it fails, or when a
an issue used to work and it fails.- It is only a bug if the module is in active maintenance. Otherwise it
might be registered as known issue.- If a bug fix takes more than a day, it is not a bug, it is a development
task (if parts of the module plans) or a feature request (which we don’t
support at the moment).- If a bug won’t be worked on for the upcoming 6 months, it is not a bug,
it is a known issue that needs to be documented.The developers under contract will dedicate 2 full-days a week to work in
the tracker to re-triage issues, fix bugs and patch review.Some stats following this definition. From a universe of 2,042 open reports
Blender has:
- 631 untriaged reports.
- 37 confirmed high priority bugs.
- 1,367 reports that may be either a bug or a known issue
In the end the tracker curfew is to bring confirmed bugs down to a
manageable number (~200). There is a similar goal for patch review, but I
will leave this for the official code.blender.org post next week.Have a great weekend,
Dalai
11 Likes
I like that… 
2 Likes
I hope you will be able to report and keep track on issues that are known in some form on the developer forums instead of some other website. Same for feature requests. Blender needs a unified website where you can make the reports for all of these categories the same way as you can report a bug inside of Blender right now with guide lines on how to write a post. So you just press a menu item and you get directed straight to the right forum.
1 Like
I hope that coding boost will not ignite a burnout for the dev crew.
Sadly, a good deal of reports already fit (and will continue to fit, the more so the more people pick up Blender) the “not a bug” category, and get dismissed as “feature requests” (not supported, lol), as “works by design” (even if design is horrible and faulty), or put off into a looooooooong waiting box. I don’t see what that particular wording changes in this regard: they’ve been doing that exact thing for years.
I mean, obviously it’s unrealistic to expect the devs to “just fix” all of the problems; some of the long-standing issues will gradually fade out on their own due to reworking of the core functionality, some will (hopefully) one day filter to a dev with means and will, some are simply a harder fix that may first appear. But man, when you report another glaring hole in consistency or feature parity, and it gets shrugged off as “works as intended” (often even with zero documentation on what’s actually intended), it can get infuriating.
That said, two dedicated tracker days does sound great.
2 Likes
I like that they’re going to spend two days a week on bugfixing. Everyone likes stable software.
I don’t like that they seemingly intend to listen to users even less. Branding things that don’t work as expected (or in a useful manner) as feature requests is such a tone-deaf response to the tracker problem…
4 Likes
Yes, exactly… They really only considered bugs to be literal typos in the code, regardless of how devastating behaviors the bugs which did not meet this criteria had.
If you report something like inability to set confirm changing brush size by any mouse button other than the left one, they will tell you it’s a feature request.
Then you can either…
A. Go F yourself
B. Proceed to create [sarcasm] surely to become popular [/sarcasm] feature request of ability for keymap to allow you to confirm brush size change using right mouse button. Oh imagine the likes pouring in.
…with B being equal option to A.
Blender’s usability will continue to be an issue if usability issues are not treated with the same respect as bugs. The most popular pieces of software out there, which people like, are popular because usability issues are treated with the same respect and bugs, and are developed by people who understand difference between solving usability issue and introducing whole new feature.
Typical example of that would be the necessity to rotate if you instances 90° in the viewport if you want to scatter them with particle system. It’s not really a bug in terms of there being a typo in a code, but changing coordinate axis for the mesh instances in particle system would hardly cut it as a “new feature”.
There’s a middle area between code-level bugs and new feature request, and they’ve now pretty much completely removed channels to report those.
6 Likes
Yeah, I can see that being an issue. I know at least some of my reports have fallen into the grey area of them being a “bug” or not. I left a ton of feedback on the remeshers during 2.81, some of the issues being serious usability issues that were unknown at the time since the features were brand new and needed the testing to find those workflow problems.
Luckily we managed to address the vast majority of them, but if they are going to be this strict with what is considered a bug or not, it is going to be hard leaving that feedback through the developer website. Which is a shame, since I think it has been the most effective place so far for doing this sort of work by getting more direct ways of contacting the devs.
Yeah, for example the other day I reported one where exporting formats doesn’t have file overwrite prompt. It’s easy to accidentally go into export instead of import rollout in the menu, and then if you doubleclick the file your wanted to import, you will without warning overwrite it, destroying its contents without any way to reverse/undo that.
Especially funny if you have both import and export in the quick favorites, tooltip being the only hint:
…and import/export window being nearly identical.
Of course, it was rejected for being a “feature request”. I wonder how many people already accidentally destroyed their import files. I did at least couple 
1 Like
Do you have any evidence of this, the .diff output from many of the bugfix commits involve far more than just fixing typos?
I know we would all like as many usability issues fixed as possible, but with thousands of reports, even the BF dream team of 20 full-time devs. would need months to resolve them all by way of putting down code, and that assumes waves of new reports do not come in.
Maybe typo wasn’t the best way to put it. I meant code that doesn’t work as intended.
Anyway, here is the Youtube video.
The people commenting on that video seem to be a bit less interested in trying to construe this piece of Blender news as a bad thing (like we’ve seen many times on BA with many other articles). The amount of benefit it will bring will really depend on where they draw the line between ‘feature request’ and ‘bug’, though 2.8x development shows they are taking usability more seriously.
2 Likes
Woah. A professional crowd simulation tool in Blender? Nice.
Open Source too? Perfect.
Tangent Animation is bringing the good stuff to Blender.
8 Likes
Does a bug categorized as a “known issue” become labeled as such and remain open so development can be followed? Or does it become closed as “invalid”?
If it’s the former, I think it’s fair, but I feel like I’ve seen reports of unexpected and even dangerous behavior being closed as “invalid”, which is frustrating for the user reporting the issue who wants to see it being recognized and be (hopefully) eventually be worked on.
1 Like
The idea is to be fair with users.
If your report is labeled as a bug, you may expect it to be solved quickly.
If it is labeled as a known issue, it will be a task that may last as is during an undetermined amount of time.
Before mentioning that an issue was known was literally meaning that issue was already known (seen as an acceptable limitation, trade-off by developer or already reported by another user).
Closing the report was not a way to neglect the issue ; but just a way to keep bugtracker clean by eliminating duplicates most of time.
It may be a good idea to count how many people report same issue. It gives an idea of how annoying it is. But there is no reason to keep open hundreds of reports about exact same issue.
There are always reports written by people who don’t follow guidelines, don’t know blender very well and expect it to work as another software.
Since 2.8 alphas, their policy is to consider design issues as something that should be discussed on devtalk forum to avoid that point of view of one user on how should work a feature damage workflow of other users.
So, things have never been as clear as now.
If you detect something that does not work like manual says it is supposed to work : blender is potentially broken. That may be a serious bug that may break many people’s workflow.
Developer will take a look and say if he can fix it now(bug) or not (known issue).
If you think that current design of a tool is not optimal, that may just annoy only one part of community and the rest don’t care. Level of importance is lower. If you succeed on devtalk forum to make a demonstration that improvement could benefit many people or that problem is annoying a lot of people, that will become a known issue, too.
But developers have to deal with a fog of 2 thousands bugreports collected since beginning of 2.8 transition, they need to clean the track in order to know where are priorities.
6 Likes