Patch reviewing, the long waits involved now and the impact on development.

What I’m talking about the is fact that a lot of people who might’ve otherwise be contributing to Blender on a regular basis by now have instead left the development scene for good because of the impression that the BF doesn’t seem to take patch review as a priority or even as a serious part of moving Blender forward.

Campbell has noted before that perhaps 80 percent of Blender development is paid work, where are all the volunteers then, could the lack of volunteer resources be because the people who would otherwise provide them got tired of waiting for months for a response or even an acknowledgement and decide that perhaps the core team doesn’t want their help? I am left to wonder if Blender could actually be years ahead of where it is now had more resources and time been allocated for patch review and helping volunteers get their work in trunk. Just how many areas of Blender would not be currently orphaned or lack resources compared to now if only that was happening?

One way to fix this for sure would be to convince Ton that there should be a time in every release Cycles where there is less in the way of devs. focusing on their assigned projects and more in the way in getting volunteers up to speed and getting their stuff suitable for inclusion in Master. If not, if we see the majority of new developers largely ignored by the core team, why have a patch tracker at all, just make Blender development available by invitation only and make it clear you don’t want people to just pick up and work on the code.

That’s the way I’m seeing it for now, what do others think, what is the state of the current situation with patches and what can be done to resolve it if it’s currently subpar, inefficient, or broken?

I think a paid dev position should be setup just for patch review… full time .

Good luck filling that (patch review) position. Just curious… has there ever been any attempt at dialog with Ton / core team members about contributions? I see a lot of hand wringing in threads here and a lot of proposals, but without involvement from someone at BF it all seems like wasted effort.

Could you make the headline more dramatic, Ace? :rolleyes:

Sure there are a lot of patches made (206 according to and I can understand why some of the volunteers might feel ignored or frustrated. The “crisis” is that BF is small and already have a lot on their plate. When the choice is between getting bugs fixed or adding more feature patches, I think most would agree that bugs are more important to solve. The bug count is currently @ 140, and the paid devs are doing their best to bring this number down, and on top of that the BI is working on the Gooseberry pilot, with larger structural(?) changes happening to the Blender code. These larger features I also think we can agree are desirable and useful for most, and it would be preferable if they could focus on that. Of course not everyone feels this way. I don’t think the BF/devs deserves to be “blamed” for being exclusive here - as I see it they are just busy.

I don’t think it’s a bad idea to set off some time to mentor “new” developers and other interested, but something gotta give when we only have so many main devs. Could be fewer releases pr. year, or fewer bugs fixed, maybe stressed out devs, loss of focus, I don’t know. Maybe the community could gather some monies for biannually online “seminars”, where a trusted Blender developer, not hired by the BF, gets the paid role as mentor for all interested in submitting patches? Those interested and willing can also hang out in IRC presently and ask questions and get acquainted (some of course already do), just like a large amount of us “normal” users can also help out by testing the various patches already in the tracker. I guess most users have an excuse for not participating more or at all, myself included (I don’t expect anything from all the devs, and can only be thankful for all they do). More active testers in the patch tracker could also help a lot to encourage the submitters, create awareness and maybe even help the reviewers. It does require learning new tools (git, compiling) which requires some dedication, but if some of you are really anxious to see Blender accelerate faster and attract new developers, potentially, it should be a small price to pay. If not, I can only hope you don’t have an opposite effect on the current devs, by criticizing what and how they do their jobs on a product they release for free.

@Ace Dragon, I would appreciate it if you stopped using melodramatic phrasing in your thread titles. It’s hyperbolic clickbait that verges on trolling. If you have a question, just ask it. Leave the drama somewhere else.

The thing is though that the potential developers who have left might also have been ardent bug hunters which would accelerate the bugfixing process (especially since the report count never seems to go down below 100).

and on top of that the BI is working on the Gooseberry pilot, with larger structural(?) changes happening to the Blender code. These larger features I also think we can agree are desirable and useful for most, and it would be preferable if they could focus on that. Of course not everyone feels this way. I don’t think the BF/devs deserves to be “blamed” for being exclusive here - as I see it they are just busy.

That’s the thing, Ton’s intense todo list for the developers could be seen as forcing patch review and the process of helping volunteers to a low priority. Ton has said before that he would like to see more devs. come on board, but he’s not going to get that real easily unless the new devs. can safely assume they won’t be waiting a month or more for a reply.

Ace Dragon, I would appreciate it if you stopped using melodramatic phrasing in your thread titles. It’s hyperbolic clickbait that verges on trolling. If you have a question, just ask it. Leave the drama somewhere else.

Is the new title okay?

You should rename yourself to “Tabloid Dragon” :slight_smile:

The issue is well known by them too, as always is just a matter of manpower since it doesn’t seem this has been addressed yet AFAIK.

May 25th Meeting:

  • Bastien Montagne points at huge and old list of patches that wait for reviews. Ton suggests to do a massive amnesty for patches after the release, provided the submitter is enthusiast and capable to be involved as part of a module team - responsible for maintaining his/her work and fixing bugs.

June 29th Meeting:

  • We try to clean up the patch tracker a bit for the upcoming release, and include some patches that have been in the tracker for some time.

Ace is right, and sometimes, people sensationalize things they feel strongly about.

imagine a 1000 hours of work,

waiting on a 100 hours of work,

and if they wait too long, all of that work will need amended due to version changes.

Basically, the people who write the patches, are in coding limbo, and will probably move on.

I wish I had all the skills to help, but I just don’t.

For what it’s worth, all of the paid developers were once volunteer developers (some for a very long time). And part of the “job” of being a paid developer is (AFAIK) being directly involved with the less exciting development tasks of bugfixing, documentation, and patch review. Non-paid developers can, of course, also contribute to these more boring tasks, but very few do it by choice. If you’re working for free, why spend that time on the tedious things?

So the core of the issue (again), is simply one of manpower. Bugs are getting looked at. Patches are getting reviewed. But there are only a handful of people actively doing that work. It’s going to be slow. It’s not a crisis. It’s the state of things and it’s been that way for a long time… and other projects face the same issue. It gets magnified with the size and scope of the thing being developed (even moreso if the size of core developers remains small).

Free software is about working together. If you submit something to a free open source project, not necessarily this, and you get rejected you should keep developing what you have. You could give up altogether, but then you weren’t really into it. A good idea is to develop things that you personally want to use regardless if they fit a certain pre-existing projects paradigm.

Patch review is complicated,

I think you have to try do patch review for a day or 2 - to really understand why its problematic.

One factor tho - is that its subjective and somewhat confrontational.

Check current list of patches.

Its disputable if we would even want half of these in Blender.
Ideally we would simply close those patches, yet its not that simple, since some are incomplete - or maybe could be acceptable if they were improved (or re-written).

Also, no single person has the authority to reject patches (since each area has its own module owner), it may need discussion between devs and check if some feature should be added.

So for me, if I spend a day reviewing patches it means either…

  • I rewrite a lot of other peoples code for features Im not sure we even need…
  • I write a lot of replies to patch authors asking them to re-work their code so we can use it.
    … and reject some, and get into disagreements with the patch authors.

Said differently, not many patches we can accept without a lot of extra work.
And - a lot of patches make changes we could have made fairly easily if we’d wanted.

So the motivation to spend a lot of time on these kinds of patches isn’t high.

On the other hand, this is only some patches.
We get some really great contributions too (fixes for bugs or significant improvements).

This isn’t all or nothing, we do spend time on patch review, and it is important of course.

Yikes! Didn’t realize that I have six old moldy things on that page. I don’t think any are newer than two years old (I stopped doing Blender stuff after the “Reset to Defaults” debacle) and assumed they’d all been closed. Being so old, none of them would patch against the current trunk so can’t even be tested anymore.

But to use one as an example, T33573 “Simplified Header Statistics with Icons”, we had a very extensive discussion about that here on BlenderArtists two years ago, so it would have been nice to have gotten some feedback from module owners back then rather than have it languish unloved and unnoticed for so long. Even negative feedback would be much more appreciated.

@Harley, re: T33573, its unfortunate - in this case you only got feedback from one of the UI team members (who isn’t so active now).

Replied with details in tracker.

To be fair, William’s “Definite improvement” comment was a year after the patch was added.

Thanks! Really appreciate it.

My personal experience on the patch tracker hasn’t been great. Maybe it’s just that the bad ones wear on me more then the good ones.

Some advice I’d give:

If you post a patch that fixes a current bug from the bug tracker, and link to it from the bug, I think you have very high chances of it at least getting looked at.

Despite what you may think, there are large areas of blender that go pretty much unmaintained because they are old, complex, or specialized. If you post a patch in one of these areas I think you have lower chances.

Even if there is a module owner listed for the area of your patch, that doesn’t mean that they are currently active or that they actively look for patches in that area to review. Don’t think of the module owner’s as maintainers but simply as a list of people to contact. This probably means going on IRC or email and kindly but directly asking them for a review. This can seem kind of aggressive for some patch authors but if you really care about your patch it may be your best option.

With all of that said, when you compare blender to other open source/free software projects, I think the blender devs probably do an above average job. Patch review is usually less fun then coding yourself because it’s really more about dealing with people then coding, so switching over to a full maintainer role isn’t very natural for some devs.

Going back to my earlier example patch that sat for two years before being closed yesterday:

  • The task started with patches that changed the stats display with icons.
  • Ton makes comment on the dev mailing list that he prefers text rather than icons
  • new patch is added that changes the text only without adding any icons
  • patch is closed two years later because of Ton’s comment about preferring text

Should not be difficult to see the logic error there…

I stopped being interested in Blender development a while ago now…

Right-clicking on a UI element and selecting “Reset to Defaults” was added in 2009. It was reported as a bug in 2010 that it doesn’t actually work for anything since it always resets to zero. It was then added to the wiki as a Development “Simple Todo”.

I spent a lot of time making a patch that would reset absolutely everything to defaults values. I made changes based on input from Campbell and then other changes based on comments from Brecht. In the end it was a 3600-line patch with a last comment of “…the way it’s implemented seems fine.” But in the end it died on the vine as Ton said that he prefered just removing “reset to defaults” from the right-click menu.

At that point I decided I wouldn’t do further work until they removed the “reset to defaults” item and/or updated the wiki so that this is no longer on the “simple to do” page. Either thing would take moments to do. But neither has been done to this day and just demonstrates a dysfunction that discourages contribution.

I recently added a new item to my list of things that must change before I care again: restoration of the 253 contributors that were accidentally removed from the “Credits” page after the change to Git. It wasn’t intentional, but is something that is important to correct as quickly as possible.

Thank you Harley for contributing,

sorry about the patch awkwardness.

I wish there was a automatic way to test to see if adding a feature broke others,

how much more memory it used,

cpu time etc.

@Harley: Thanks for trying! That’s one of those many Blender quirks that has always caused me rage. WTF is the point of having default values on properties if the user has no easy way to reset it to default?! I have been thinking about doing my own build with all the patches I want applied simply because of crap like that.