Hi,
I am not trying to have a go at anyone, nor say that my bugs are top priority. However, I have two which have been multiple years (one is 2 years old and one is 3 years old)
Apart from ‘prodding’ the thread, is there anything on our end we can do to get these re-looked at? Both of them are regressions moving from 2.79 to 2.8, which never have been tackled.
Thanks
Carlo
Would help if you included the ticket numbers.
did some digging and it’s likely T63064 and T76246 they are known issues/todos with no-one scheduled to work on, it’s a matter of priorities, so much work todo and only few hands to do it. just because a ticket has been open for a long time, doesn’t necessarily raise it’s priority.
I didnt want to say the ticket numbers exactly, because it was more about the overall process, rather than these specific ones.
Just how should I check in on it? Me posting on the thread seems to gain no response at all.
This is an open-source project, so literally anyone in the world is free to fix those things. But none of those people are forced to either.
It is possible that you will get the pleasant surprise of some volunteer popping up with the skills and interest in fixing those “known issues”, but it is also very possible that they will both remain untouched until the next time that area of code is refactored and the behavior might then change.
If anyone fixes those issues it will be shown on those reports. In the mean time your posts asking about them aren’t really going to cause any action on their own.
The short answer is there is just not enough developers. We have millions of users but only dozens of programmers, most of whom are volunteers. We are all working as fast as possible, but there is more work than people to do it.
Totally understand the opensource nature of the project, and that there are a bunch of volunteer developers (including myself) that do contribute from time to time.
its a case of, there are issues with blender which are long lasting. Blender (whilst there are volunteers), still does employee a fair few developers to work on the program. Thats the whole point of the development fund.
I would much rather them say, its never going to get tackled. or its on someones to-do list, and they will get to it within the next 1,3,5 years, thats totally fine aswell.
As you can tell by the actual bug reports, I am trying to be patient with it, and respectful. I just think there can be a bit more done in terms of management.
I hear ye.
I also think that the sheer volume of the work out there makes managing, fixing, improving etc. things a Herculean task. So I think that those two issues referenced above are not as high priority as the other things the core devs are working on.
Personally, once I’ve gotten some other items implemented, and become more familiar with the core code, I’d like to tackle that collections copy and paste merging issue. Sounds useful and perhaps not too difficult to implement. So I’ll holler at you in that thread when I have bandwidth. Other community devs out there by all means could hop in too on those and work on them.
It is our fault that these kinds of things are not always communicated well. Had those reports been flagged as bugs then that would be a signal that they are things that should be fixed, and those get various priority levels to imply how quickly we hope that they will be resolved.
But those were (correctly) triaged as not bugs, but as “known issues”. So they are just considered “nice to have” improvements that we would welcome. They are not on anyone’s “to-do” list and might not ever get fixed. But there is utility in having them in the system like this, rather than just closed as “not bug”. This is because they can be considered if anyone is doing other work in that area of code. So while adding or changing other functionality it is nice to keep in mind this other wanted behavior.
But those were (correctly) triaged as not bugs, but as “known issues”
But this is the thing. They were always saying that there wouldnt be any regressions moving from Blender 2.79 to Blender 2.8… To me this is a bug, which ‘should’ be fixed. But thats getting more in the specifics of the bug.
To me, a task that is outstanding for years on end, starts to become higher priority, as its been waiting a long time. I just want a more formal way of saying, hey guys, can you take a look at this when you have the chance. I dont want to put pressure on it or anything, just that its not forgotten.
But this is (sadly) a misconception. The priority of a task depends on a number of things. The number of people who are bothered by the problem is one thing. If the task holds up other development is another. For a task which is deemed ‘low priority’ depending of those 2 factors, the age doesn’t really matter.
It’s not ideal, but with the amount of programmers available (paid or not) and the amount of work (all very important to someone) to do it’s just how it is.
In my opinion, the risk of allowing bug reports to remain in place for years with no movement, is people deciding the bug tracker is no longer worth using and will just complain on the forum instead. In the past (before devtalk existed) there were people who decided to do exactly that because they lost trust in the development process.
I do get that some things do not get fixed because the code in that area is a mess and it is going to get an overhaul anyway, but the choice to not fix other issues just puzzle me because it concerned a modernized area and it did not seem like a lot of work would be needed. I had a report talking about how the bridge tool for Bmesh set to ‘pairs’ could not make use of the face normal to determine where the pairs were, and it was decided it will not be fixed even though an addon bundled with Blender already had the solution.
Both of the tasks I am referencing, would influence more than 90% of blender users in a good way. There have been many other tasks that have been merged in to one of them because people continue to flag it as an issue.
I just feel like there should be some review process of older items, to either allocate resources to them, or to close them out and say we are not going to do it. Leaving it limbo just is frustrating for a regression.
One of our big pain points for us, is one of the copy/pasting functions… With 2.79 being so old now, we are now weighing up whether this pain point, will outweigh the pain of being on such an old version of blender. As a result we have started coding up our own python script to replicate the functionality, it will be slower than the inbuilt functions, but atleast it works.
They currently have bug-fixing / weeks, where developers are dedicated to bug fixing, couldnt this be extended to a old reports day / week? specifically to tackle order reports? even if it was once a quarter / year, it probably would be enough to keep the community happy.
Regardless, I feel like there needs to be a bigger discussion about this with the core development team.
Which is the same for more or less all tasks that are being worked on.
Which is what marking them as a ‘known issue’ means. So this has been done.
It’s just useful to keep these sort of tasks around, because
If something is marked as ‘known issue’ , that’s not the same as ‘leaving it in limbo’. That’s quite explicitly saying: we’re not going to spend resources on this. At least not right now.
Now I do agree the communication about what the various statuses mean could be clarified (a lot). I only found out it works this way quite recently when I was doing some bug-triaging work and was told to handle a case this way.
Which is the same for more or less all tasks that are being worked on.
So what is the process to prioritise tasks on a paid developer, who is working on bug reports in areas they are not interested in?
Which is what marking them as a ‘known issue’ means. So this has been done.
So these tasks ‘will’ be done? Is there a indication of how many more years (or decades) it will be?
- If the same issue is reported more often, it’s useful to not open new tasks all the time but merge them min the existing report. This also gives an indication if the demand for the feature increases enough that it really needs to be done now.
The problem is, that its been a significant amount of time since 2.79 which both of these bugs were a regression of, so people are just like oh this is the way it is now and dont know any better, rather than creating new reports saying the same issue.
I just cant help but feel there should be a way, formal way, of saying hey guys, this tasks has been open for a while, can anyone take a look at it at some stage without pressure.
If something is marked as ‘known issue’ , that’s not the same as ‘leaving it in limbo’. That’s quite explicitly saying: we’re not going to spend resources on this. At least not right now.
I read that as “We arent closing it out because we may spend resources on it evenutally, not right now”
But still one of the tasks I have in question is a To-Do, not Known Issue. Point still stands that something should be done about it.
I read that as “We arent closing it out because we may spend resources on it evenutally, not right now”
from a code.blender.org post on the subject.
Known Issues
A known issue is a confirmed report, which contains all the information required in order to be fixed, but that is not planned to be fixed in the next 6 months. Known issues are a way to document shortcomings, identify areas that need more developers, and to give an honest statement about issues that won’t be fixed in the foreseeable future.
Yes, that means that if YOU want to work on it then we will welcome the improvement. I’m sure this has already been explained in this thread.
There is no process for that. The blender foundation prioritizes its own tasks. It is independent and doesn’t need to do what contributors want. Which is good because otherwise the BF would have been ‘bought out’ a long time ago by some big company with deep pockets.
I can see why I confused you. Sorry about that. It’s is still somewhat correct what you say. It does mean we may perhaps spend resources on it someday. But it doesn’t mean we will spend resources on it, it just means we don’t want to forget about it. (I’m just some nobody, by the way. In no way affiliated with official blender. Just a curious code and user like yourself).