Blender has more than 3000 open issues in the tracker, time for action!
The tracker – developer.blender.org – exists to help the Blender development process. However as Blender gets new users, it also get proportionally more reports.
This scenario over the years lead to a very particular scenario: Blender has an unmanageable number of open issues that are not representative of our road-maps. On one hands artists don’t know when a certain issue will be fixed. On the other hand, some Blender developers are swamped with over a hundred issues assigned to them.
It is time to finally address this, and the goal is:
- No patch un-triaged for > 1 week.
- Bring open reports in the bug tracker down to a manageable number (~200).
Bug Definition
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 is not supported 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.
Bug Triaging
The Blender Foundation policy to handle reports which aren’t clear or seem like feature requests is to close them immediately. For anyone interested on helping the development process, as well as the active developers, the following diagram together with the Bug Triaging Playbook should determine the life cycle of a report.
Anyone is welcome to help with the bulk of triaging. However it is exclusively up to the module owners, members and coordinators to sort between known issues and bugs.
Patch Triaging
In a similar fashion, the existing open 1,250 patches need to be triaged much more strictly.
- Patches should start with end-user level documentation.
- Patches only get reviewed for modules that are in active development.
- Patches should well align with current design and roadmaps.
The module teams will make sure design and roadmaps are well communicated in the module page on wiki.blender.org.
Plan of Action
New tasks subtypes will be created on developer.blender.org:
- Report: Default task type, for untriaged reports.
- Known Issues: Documented short-come of existing features.
- Bug: Confirmed issue.
All existing confirmed bugs will have their type changed back to “Report” and tagged with the “tracker_curfew” project.
All the low priority bugs will likely be classified as “Known Issues”.
All the patches older than 3 months will be closed, with a message pointing to this post and suggesting the patch to be updated if the contributor still find the patch relevant and can work on it.
All Hands On Deck
A dedicated triaging team (Germano de Souza, Philipp Oeser and soon Richard Antalík) will be full-time triaging reports. No bug fixing will be done by them while there is any untriaged reports around.
The remaining developers will be scheduled to work 2 days a week triaging and classifying the bug reports, tagging them properly, fixing old and new bugs, and going over the existing patches.
Honestly I found something new from this beautiful post. I am really thankful to you for this awesome post.
Having read this I believed it was extremely informative. I appreciate you spending some time and effort to put this informative article together.
This is really awesome and informative, best part of this post is your unique concept which is different from other thought.
http://ssssssiiittteeee.net
Thanks for sharing
If only Adobe showed the same dedication and urgency about fixing newly added bugs! But they don’t.
Amazing post. I am so impressed. Could never think of such a thing is possible with it…I think you have a great knowledge especially while dealings with such subjects.
This is one of the best blog I have read. Thanks for making my day And yes it’s a request from one of your reader i.e me, keep posting such great and informative blogs. I would love to refer my others friends also code blender best information thanks for you
so I just wanted to give a quick shout out and say I genuinely enjoy reading your articles. Your blog provided us useful information. You have done an outstanding for thanks
Is the CurFew already over? The statistics have not been updated since mid of March, even though devs are currently fixing quite a (cur)few bugs, and the target of 200 open ones has never been reached. Would be interesting to know what the count of open bugs is at the moment.
Bugs emergency! Called for ‘Tracker Curfew’ for all contracted Blender developers. They’re grounded until we have this beast
Bugs that turn out to be in another project’s code and that we’ve filed with that other project. Useful for tracking known issues that manifest themselves in our product, but that need to be fixed elsewhere (such as WebKit and V8 issues).
I’ve just registered a bug – in the Soft Body sim. It IS a bug but there are workarounds which one of the developers has been gracious to help me test.
However, this should be really handed off as a known issue (it’s a fault in the Lattice operator) and since this is a fairly rarely used modifier in this instance, I’d be happy to see it documented as such.
However: closing “bugs” out of hand can be irritating to the person reporting them.
Will there be any updates as to the progress and what the current count is?
Go to https://developer.blender.org/maniphest/ . Left hand side has a number of pre-set queries that run against the tracker database when you click the link, including queries for those tagged “Tracker curfew”. That’s a temporary tag to be removed when the report has been classified as a bug or a known issue. As of this writing, the bug tracker has 2,406 open reports and 1,323 tagged with “Tracker curfew.”
https://www.blender.org/get-involved/dashboard/
+1 for this effort, so long as it doesn’t devolve into a mere exercise of relabeling bugs as ‘known issues.’ For shuffling reports into differently labeled cabinets brings scant comfort to those reconciling artistic expression against visual limitations. It is still a limitation whether the barrier a Blender shortcoming erects against an artistic goal is called a ‘bug’ or a ‘known issue.’ I caution the Blender Foundation against the too-liberal use of the ‘known issue’ categorization. This *should* be an exercise of re-examining reports to properly situate them in a problem resolution pipeline. Anything less than that – in particular, relabeling just to achieve favorable counts in certain categories – would only be met with skepticism – a skepticism that engenders mistrust for a process that very much needs to be respected. In this regard, I hope the individuals named to the triage team are afforded the utmost respect. As liasions between development and an often frustrated user community, it is their lot to exercise both diplomacy and manage expectations. These are not junior skills. If triage is done poorly then the aim of this Tracker Curfew will just simply fail. I think that the triage team is on par with the development team insofar success of the Blender Foundation is concerned.
Even if all the tracker curfew achieved was to label issues as known issues and have them “artificially” out of the way that would already be beneficial. Knowing that these issues won’t be tackled in the near future sets users expectations in the right place. It also helps the development team to know at a glance that an area needs more attention and should be prioritized (or discontinued even, if the developers can’t maintain it with a reasonable quality).
It seems reasonable to think that along with the increase in the number of Blender’s users, there should also be a proportional increase in the number of software developers willing to help out, at the least with issues that affect their own personal workflow with Blender. If this has not happened, we might ask why. No one has, but I’ll give my $.02 anyway :)
In short, there needs to be a pipeline where a competent software engineer goes in one end, and a competent if not experienced Blender developer comes out the other. A few times now, I’ve started browsing the code, just trying to understand a very basic concept, and found that the more I read, the more confused I become because I encounter concepts that require explanation at a faster rate than I encounter those explanations and I soon reach a point where there is enough uncertainty for frustration to creep in.
A developer oriented document that starts at the very beginning, talks about mission goals, requirements, and then architecture, that defines concepts only in terms of other concepts that have already been explained, would be worth its weight in Mithril. The whole ask a question on a forum, wait for a response, realize that you didn’t know enough to even ask the right question, rephrase the question, wait for another response cycle is just slow enough to mute the enthusiasm that makes someone want to contribute in the first place.
It is, of course, possible to just muscle through the initial learning period. But it also is, of course, still true that the easier it is, the more people will actually do it. I’m hoping that such an effort falls under the onboarding effort that is part of the Professionalizing Blender Development Initiative and referenced by the Epic Games Mega Grant.
1000x YES. I have a couple decades of software dev background, but not a focus in 3d rendering tools. I have spent probably 10-20 hours trying to understand basic architecture and patterns used in some parts of the software to run EXACTLY into the walls you are talking about here.
Having a person with actual technical documentation skill write up an onboarding curriculum would take time, yes, but would dramatically accelerate ability of new developers to produce meaningful results. And I mean results beyond basic “paper cuts” submissions for misspelled words or spacing/layout consistency issues.
What about usibilty issues will they be considered as known issues? for example the Polybuild still has many, I reported a couple back then but they were closed as invalid and there many issues like this laying around.
It depends on the usability issue. Some of them are indeed clear bugs. Others are tasks that require proper scheduling and should be addressed during regular development, roadmaped, …, not as part of bug fixing.
Please require that *all* bugs classified as “known issue” are documented, not just the ones that are not going to be fixed in the next six months. This puts the onus on the developer to write up this behavior in the documentation for the feature(and maybe give it a re-think if it’s too convoluted to write). Also lets people point to something when it’s reported again.
The list of known issues should be enough as documentation, and prevent duplicated efforts. These issues won’t be closed, so anyone can find them before reporting a potential new issue.
Second point: what happens to Known Issues after 3 months? Do they need to need to
be triaged again, sent back to the user for resubmission, or something else?
At every release cycle developers will go over the known issues of their modules and decide which are “upgraded” to “bug” to be schedule to be worked on.
This is very interesting, and a needed plan of action, there is only one thing that I find a bit weird:
– Patches only get reviewed for modules that are in active development. –
Then for example small patches that could improve some old features that are not being actively in development cannot find their way into master? This will discourage small developers or studio developers to share their small improvements IMHO, for example we could still get some small patches for the old particle system, but since the old particle system is not in development it would be impossible to improve it according to this.
That’s not good I think
+1
There needs to be a definition of what “in active development” means;
there have been few improvements to Motion Tracking or Masking since 2.80.
Are they still in active development? Is this just down to whether there is a
maintainer or not?
> There needs to be a definition of what “in active development” means
https://wiki.blender.org/wiki/Modules has a bunch of areas marked as “end of life”.
This is a good example:
**Particles & Hair End of life, to be replaced with new systems**
Ok, but there is no plan to replace hair, and not timeline, or anything planned for hair right now, just the will to replace it.
What happens if tomorrow we have a patch that drastically improve hair collision?
And I say that because Luca Rodd has an improvement that I could try to implement myself, he did the improvment but abandoned it, then I asked him about it and he told me what I would have to do to get the improvmenet.
What if I share a patch that improves hair collisions?
Should I keep the patch to myself or my build?
Should I even dedicate the time to try to implement the Luca improvement if I already know my patch would be ignored?
Because currently this patch would be ignored, but we may not have new Hair for 1, 2, 3 or 4 years we don’t know, so should we be kept with old hair without any kind of improvement for 3 or 4 years even when there may be small improvements?
I think this is not good as it’s planned, a better outcome may be designed for that situation.
AFAIK this is not a problem for the studio who created the patch. They have the functionality, they can build Blender themselves and maintain their patch. They can share the patch, create a branch for the functionality, and other people can use it.
Currently the core Blender developers are drowning in work. Giving them more work doesn’t solve that situation. Nobody wants to say “no”, but that is exactly what has to happen in order to reduce the stress and pressure.
True, I’m not talking about the studio who created the patch, I’m talking about all the Blender users that need better performance or results in some areas that are not currently under maintenance by any dev, but that could be improved by small patches.
What I mean is that this could discourage small developers and studio developers to share their findings and improvements.
This is not give the devs more work (of course it would generate more work, but having control over what it’s included in master together with maintaining quality under an open source project where anyone can collaborate makes it more work, but it is what it is.
Instead of looking as another “drowning the developers gate” I think it should planned as putting in the line of reviews something that could be useful, so maybe there has to be a different approach to reviews when the patches are relatively small, come from external developers and are planned for non-maintained modules.
Of course it’s not the same the full cycles to spectral renderer than a small patch that can improve quite a lot particles performance, but my patch would have been ignored since particles were not under maintainance, and it has been greatly received and appreciated by users, and very needed, and it helped no just us, but other users too, in production, that was the target I had when I did it, when I dedicated my time to the investigation, that could be easy for many of you, but it’s quite a task for someone that does not know Blender’s source code and it’s not versed in C++, I did it to help, not just me, but others that works with particles, even if they are old, they are needed.
What I say is that this is closing the door to small improvements to modules that are not under maintainance, and maybe those improvements could lead to find a maintainer, but if the door is closed from the begining, then this is not an option.
In the same way there is a path to review code for maintained modules, there should be a way to reivew patches for non-maintained modules, maybe upon specific request by the patch developer, with some pre-requirements of testing, code formatting, etc… I’m not saying that EVERY patch of a non-maintained module should be reviewed, but if it’s requested by the patch developer and it follows the development guidelines and style (that should be clearly stated), then there should be a path to get a review for such patch, it should not take so much time out of triaging, and it could provide some quite neat improvements.
Another example is the video sequencer, it started as small patches, and in the end the small-patches developer became the maintainer, but if that developer had been sure that his patches were going to be ignored he would not have made them, or would not have shared them, and we could have ended with a Video Sequencer module still without maintinance and possible removed.
I agree with you a lot. There still is no system to manage feature requests and user needs directly within a tracker system. There is no clear kanban based agile system clearly defined on tasks. This bug purge (which I do think is good to start with a clean tracker for 2020) is welcome, but if it’s the road to the future when things get out of hand for developers… then it definitely is not a good way to keep backers and those who support software development happy.
Also, making patches to old code to improve things that aren’t improving by core devs have a strong gate against the community is also indeed worrying.
Making the tracker smaller is great – cool.
But the key issue of making the tracker easier to use, easier to commit code to branches, and easier to apply agile based software development systems openly with the community still needs work.
I rather think that development time is better spend on the new particle and fluid Sims eventually the old ones should be removed to make place for better code design better maintainability and better art work.
The thing is that we are not talking about development time from teh devs, we are talking about small developments that are done outside of the BF/BI and improves the current tools, no matter if we will have better tools in 2 years (how much until we get Particle Nodes integrated with simulation and with the actual particles SPH? ) we need to produce content today, and if we can get a proper improvement, no matter if it’s small or medium or even big, it will help us.
I know the review takes time, and that’s normal, I’m just asking for a path to get those patches reviewed and avoid discourage other devs to contribute :)
In order to prevent spam, comments are closed 7 days after the post is published. Feel free to continue the conversation on the forums.