Proposal: Introduce a dev-curfew on open patches

Archive Blender Development
, ,
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 https://blender.chat/channel/blender-coders . 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
23

So as I said, then I probably missed it. How can you see it? Where have they written about it?

1 Like
24

How about really old patches though, they may be probably incompatible with current blender code. Can you say with some degree of confidence, that most of pre-2.8 patches can’t be merged into blender code without rewriting?

1 Like
25

Well, certain developers tend to throw in a screwed ball in the discussion of a new-feature-patch and out of the confusion this causes, they conclude that the feature should be discussed devtalk first and then the patch is left to rot, while the contributor gives up on contributing to Blender. I seen this happen numerous times.

Any patch more than a week old needs to be adjusted to Master. That’s just the way it is.

26

I haven’t seen anything written about it so far, but if you look closely, you can see that there have been massive changes. (Being a developer and coordinator who is used to working in teams certainly helps to identify them :slight_smile: )

It became necessary to have development coordinators with the increased team size. This has led to many positive effects.
On paper the module owners existed for a while, but now they finally started to make use of this structure as well as refining it. My impression was that the decision making process has improved a lot and even significant changes in the UI/UX have become possible. Previously, my impression was that everyone could join the UI/UX discussions, but there was no clear goal and there was no team with the power to actually make decide and there were no processes for this. This still looks like work in progress, as it doesn’t seem to always work, but it surely has improved a lot.
I only mentioned the UI/UX because that is clearly visible for everyone. In the other areas, the module teams have been revived as well. On top of that, they added roles like lead architect and admins to further help the decision making process.
Just knowing what is currently happening and what are the next steps is very valuable in a development team. Also knowing whether everything is on track for the release is very important, such that the priorities can be shifted if necessary. But doing that properly takes a lot of time. https://developer.blender.org/project/board/2/
The coordinators also take care that the developers are working in the bug tracker as needed. Even though it may sound like a logical thing to do, that’s surprisingly difficult to achieve without a coordinator once the team reaches a certain size (in my experience at least).
They also introduced days to clean up the code overall. This only became possible with the increased team and is going to be invaluable in the future.

Without all that, something like a roadmap (Modules Roadmap – June 2020 — Blender Developers Blog) would not have been possible. We have seen things like roadmaps in the past, but those were more like wishlists.

Edit: I wasn’t a fan of the way Blender was developed for quite along time. The funding for the open projects meant that most developers could only be hired for a limited time. Once they got used to work in the team, they had to leave with all their valuable know how. I am glad they massively pushed the development fund and it became successful!

2 Likes
27

If it is about discussing actual development, the devtalk forum is for sure one of the places to go to.
Regarding everything else you mentioned, let me refer to my previous answer to you where I talk in depth about the value of upfront communication. Do you think in the case(s) you are mentioning pure patch review would solve the overall issue?

28

Thank you!

I think I finally got an answer to a question I’ve been asking all year.

29

I haven’t written that much about the actual review process, except that I would suggest that a module team-member is appointed to be responsible for the development of the patch, after the module team has decided to greenlight it. Being responsible just means, being the one who is incharge of the reviews and communication with the contributor until it is ready to be committed, or given up if it turns out the be dead end.

Personally, I think it’s a misunderstanding to call the module heads for “module owners”, I think they should be called “leaders”, in the sense that they are the ones to have the vision and drive the ambition for the module and guide contributors and module members in that direction. They should not be owners in the “house owner” sense, where you do what you want with your home, and buy people to do whatever you need done, which you can’t do yourself.

What worked out well in the UI team was that William took responsibility for that leadership and had visions for the UI, but now he has left Blender development for a new job.

1 Like
30

All I’m wondering is what happened to this:
image

:thinking:

31

I think they hired David Drayton (was the UX Lead for Cinema4D at some point), but it’s not clear from meeting notes if he only with project for asset manager stuff or for rest of ui too.

3 Likes
32

Interesting.
If that’s the guy behind the wonderful C4D UI/UX, then that’s a step in the right direction. But yeah, if he’s only going to work on the asset manager, that’s a waste of brain power, the asset manager is nothing. There are huge UI/UX issues that needs to be addressed.

33

Imagine having to review a fairly extensive patch that touches different files, approving it, then later discover a bug, but the original author has no obligation to try and fix (although most would). The module owner is left with a piece of contribution which either they add to their plate of things to fix, or revert back and build up apprehension towards the next contribution. Maybe I’m just cynical to think this.

I do like the idea about a patch curfew, but the task could just as well fall within the community developers to “prune” the bad stuff and suggest patches that are feasible. Don’t need module owners for that.

2 Likes