Proposal: Introduce a dev-curfew on open patches

Archive Blender Development
, ,
1

Currently, there are 1211 differential revisions/open patches. One of the older ones is dating back to Dec 3 2013 by @dfelinto.

Many of them does not have any response whatsoever, and others are undecided if they are a valuable contribution and just left hanging for years.

All of these patches are made with the intent to contribute to Blender. People have spend valuable time coding them and offers them as free gifts for the community.

I know it is time consuming to do patch reviews, but for the sake of common decency, maybe a curfew could be introduced, say a month, within which the module teams have to decide and reply if a patch(if properly developed), will be a valuable contribution or not. Or in other words a ‘green-light or red-light’ reply within a month.

As compared to the one week curfew bug-reporters get, a month should be enough? And those patches which might contain valuable code or ideas, but left unfinished, could get a “library or resource” label.

67 Likes
2

I’m not in a position to judge this from a developer’s point of view, but as a user, this idea sounds fantastic!

Having read through quite some patches and the discussion around it seems to me that as soon as there are two opposing arguments in the code-review the progress stalls (especially UI related things).
Some patches seem to die after some back and forth in code-review about the question of where to put a tick box or if there should be an extra theme option or not.

As I said, I’m no developer and therefore I have no clue about the technical debt of adding non-perfect code, but as a user, a non-perfect feature is better than no feature at all.
Have a look at this patch about cat-eye bokeh from 2017: https://developer.blender.org/D2922
I could have used that feature for a few projects already but it seems it went no further because it wasn’t perfect and could have been more optimized.
As a user this sucks, I’d rather have it not perfect than not at all for years.

Of course, the devs have to deal with a huge number of patches and obviously there is a need to ensure code-standards and quality. It’s a tough task to find a good balance.

Thanks for all the hard work devs!

13 Likes
3

True, happens all the time. To avoid this situation For each patch, a team-member of that specific module, should be in charge for the communication(final say/conclude on discussions), and if the patch is green-lit, have the responsibility for consulting the patch-coder, until the patch is ready to be committed or close the patch, if that state is never reached.

3 Likes
4

I agree, the biggest problem is that so much stuff is left alone and forgotten.

2 Likes
5

Seems a very good idea to me. It’s a pity that all that valuable work should be lost.

Therefore, in my opinion, it should be easier to try-out these patches. Right now, the documentation to build your own Blender-version is too technical for the average user.

May be the idea of a downloadable “sandbox” to play with?

6

In principle, it is a good idea.
However I’m affraid it is technically impossible.
A downloadable sandbox needs to be compiled and that takes some time and processing power.
And given the number of patches that would need to be tried-out, that would take far too much ressources.
Besides, compiling blender isn’t that hard, really!

7

I agree with this. Purely from a developer relations point of view. I submitted my first patch a while back. It was basically a trivial feature, but it was an accomplishment getting Blender building, finding my way around the code, and figuring out some basic things. I got some comments and design feedback which I addressed, and the patch was approved, but never landed. I even asked in DevTalk, and was told it would be merged eventually. It feels rude to prod more.

As a potential contributor, I found that quite discouraging. I understand not every patch can be accepted, but it’s kind of worse being in limbo. And of course, with master having moved on quite a bit, it probably needs some attention to merge properly.

28 Likes
8

And then you get people like Pablo Vazquez on his youtube videos telling developers to contribute to blender… At this point in time I think what they only care about is more money flowing to the development fund.

1 Like
9

I don’t think that’s quite fair. Developers have a lot of competing priorities, I just think processes can be improved, and dedicating some time to clearing the backlog would be a good idea.

11 Likes
10

If Pablo was that kind of guy he would be working for Pixologic or Autodesk already.

7 Likes
11

Come on now, this is a very unfair comment and it achieves nothing more than fueling anger.

There is a huge road from the realm of ideas/intentions to the actual, practical implementation of things, especially with so many moving parts.
It is clear that this issue arises from a fault in organization/priority management, but it is in no way an act of evil! The blender team has been growing tremendously in quality, but instilling order or better structure onto an already moving mechanism is absolutely no easy task. There are a lot of fires that demand attention simultaneously, and injecting anger fuel instead of being constructive only widens the breach between the team and the community.

18 Likes
13

As a user I’d would totally agree with this. I’ve used a fair share of “imperfect”, “half-baked” or partially working features implemented as limited addons that have saved my life countless times. I’d also rather have an unfinished or unpolished feature then no feature at all.

Unfortunately we probably have only ourselves to blame collectively as community for why this is impractical. Many users don’t understand work in progress, experimental features, development priorities, lack of resources and disproportionate user-developer ratio.
They act entitled if something doesn’t work as perfectly as they’d like to all the time, and expect pristine implementations everywhere.
I can totally understand that from a developer point of view this will mean increase in bug reports, complaints, angry users, more feature requests disguised as bug reports, more code to maintain, fixing other people’s bugs, which snowballs into even more time triaging and less time actually working on new features.

10 Likes
14

My suggestion is mainly to avoid the situation where good coders and potentially great contributors give up on improving Blender, simply because their patches doesn’t get any response, or an undecided response, or send on a wild goose chase. Or in other words, they leave Blender development with a feeling of their work and the time they invested in it, isn’t taken seriously. This should be avoided and could be avoided with a well defined patch-reviewing system.

My suggestion is by no means a suggestion to force unfinished hacks into Blender. There are already too many of them, and the trouble is when they’re in, no one will work on a proper solution any more, and users will have to live with crazy workflows like binding a camera to a marker for switching cameras, instead of doing camera switching in the sequencer like in the rest of the industry.

18 Likes
16

Do you think the review process itself is the actual issue or is there also a lack of upfront communication?

1 Like
17

Imho there is nothing wrong with the review process itself, it’s the lack of resources available to actually go through the process that seem problematic.

The number of qualified developers to do reviews is low, and the ones that are qualified already have a sizable workload with actual development., so review tends to get neglected.

It’s somewhat of a catch 22, the devs are fully booked since there are not enough developers, and we can’t easily onboard new developers to ease that pain since there’s no devs with time do code review.

15 Likes
18

The system may not be perfect, but In my (short) experience so far, blender has been much better at incorporating patches than most open source projects.

My experience with other open source projects is that you spend days debugging something, exactly pinpointing the bug, writing a detailed report with a patch, only to have it sit unresponded on a forum for years.

So far all my Blender bugreports from the last couple of weeks were at least responded to, and most of them even fixed. @AndrewC: maybe you were too modest? If it was already approved I’d think sending some reminders every few weeks is not too bad?

4 Likes
19

In the spring the number of bug-reports where that high, that Ton decided on a bug-curfew, and people where hired, the triaging process became swift and the bug numbers dropped significantly. And since the bcon3 period is reserved for bug fixing, most bugs are also fixed(unless they’re ‘parked’ eternally with a Known Issue label).

So bug-handling was improved, because it was prioritized. The same thing needs to happen with patches. Ex. right now it is common to see devs prioritizing doing their own bug-fixing instead of reviewing contributed bug-fixing-patches of a similar importance. Question is if it isn’t a better investment to do the review of the contribution, because the contributor could develop into a valuable bug-fixer or patch-reviewer? But maybe the decision in each individual case should be discussed in the thursday meetings?

Devs reviews of patches of other devs also seems like it could be better organized. It is not uncommon to see finished patches hanging for months waiting for the final acceptance from a fellow dev.

The final group of patches are contributed new-feature-patches, which often are never decided if they are found useful or not. The lack of resources is often mentioned, but new/feature green-lightning in the meaning: “yes, this is a good idea, we would like to see this committed in Blender if it meets these criterias …”, doesn’t need a code review first time around. It is mainly a decision to let the contributor know that his/her continued efforts will pay-off if they succeed in meeting the criterions described. This is quite important, as many contributors submit unfinished new-feature patches to ‘test the waters’. This would also be a natural thing to discuss in the thursday meetings, where the module teams already are gathered. If there are more module team members, it should also be decided who is going to be in charge of what part patch review, but maybe the module leader always should have the final review before it is committed? But this should ultimately be decided within the module teams(so the “neurosurgeon” doesn’t end up spending all the time on curing people with a “trivial cold”).

I know there is an argument that new-feature-patches should first be discussed elsewhere like on devtalk or right-click-select, but I’m sorry to inform you guys, that this is not working at all, since typically no devs engage in these discussions at all, and therefore doesn’t result in the needed green or red light conclusion.

Finally, it should be discussed and communicated what the actual responsibility areas of the module teams are. Ex. if a module leader of the Text Editor thinks it should be in maintenance mode only, it must be communicated to contributors, as their time is valuable too. Or if the UI team thinks that their area of responsibility is only the 3D View and the elements connected to it and ex. doing UI work on the VSE is just “rearranging the deckchairs of the Titanic”. And if the idea of consistency in the UI only means UI features in other editors than the 3d view also needs to be implemented there, but not the other way around(in recent months several new features has been implemented this way). Then this should be communicated.

14 Likes
20

This is so funny, because people other forums always complain about Autodesk not giving any resources to their developers and never having enough developers (and that the best developers left already).

I honestly suspect that Blender is currently the most well funded 3D modeling software out there today (remember Autodesk is 99% sales and support staff).

I’m still waiting to hear anything about the standards and practices that Ton Roosendaal wanted to implement more than a year ago after they got their first big contribution, but maybe I missed it.

1 Like
21

This is suggested when people have feature requests. It is not a milestone in the review process for developers. They are encouraged to look in those places for features that are wanted by the community, but it has nothing (or almost nothing) to do with the review process.

This is what I mean with upfront communication. It is literally impossible to note everything down properly and keeping it up to date, such that potential contributors can find everything that is needed easily. From my point of view, the way to go is simply asking them directly whether certain features are even wanted. The place where this should happen is likely Blender Chat . This is something I wish was the common approach for new contributors and communicated clearly here https://www.blender.org/get-involved/developers/ . In my opinion, this could easily lower the frustration level of quite a few people, including the core developers.

In any well maintained software project, consistency is (or should) be very important. That’s not only the case for the UI, but also the code on many levels.
That’s also something where you can’t write everything down. You can cover the basics, but if a patch is quite involved, there has to be a lot of communication going on to get a common ground regarding the UI, UX, but also when it comes to the technical integration.
If especially a new contributor arrives with a finished non-trivial patch, you can be sure there are plenty of inconsistencies, or maybe it doesn’t even fit properly into Blender or blocks other developments that are on the way.

In my experience, there is no standard path you can follow to get a patch to a level where it gets accepted. But upfront communication is very important. If there is an agreement that a feature would be welcome, it may not be the best way to directly producing a patch for review. Often, a hacky prototype may be the way to go to get a better intuition or to get some artist feedback. At other times, something different is needed. Sometimes, many such iterations make sense, at other times none are needed. The question here is, should or how much time should the module teams invest in those sort of tasks? In my opinion, that would be very important.

Getting features accepted is a process with many hurdles. One of the most difficult ones is communication. That’s why I think your proposal could help to clear the pending patches for now, but it doesn’t solve one of the core problems.

3 Likes
22

My understanding is that they wanted to incorporate more standard software development practices. As far as I can see, that’s exactly what they have been doing. What was your expectation?

4 Likes