Add-ons Policy Clarification/Discussion

Archive
1

I started this discussion on the mailing list, but thought I should post a link to it here as well to reach as many add-on creators as possible.
https://lists.blender.org/pipermail/bf-committers/2022-March/051295.html

I’ll post links here to the replies as they come in.

Edit: Because of some technical difficulties I’m having with the mailing list and the increased editing and wider viewing available here, Thomas and I have decided it would be better to move the discussion here.

For brevity, here is the content of my initial email:

Hey Thomas et al., I would like to discuss the new add-on policies with
you in regard to their practical application and the needs of add-on
developers.

A. I use a custom url for the report a bug button in Blender that points
to BlenderArtists. I do this for two reasons:
a. to point people to my feedback thread on BlenderArtists.
b. I use a much broader definition of a bug than the C/C++ side of
Blender does, so to prevent conflicts with the triaging team I point
users to the BlenderArtists thread to report bugs.

Originally, I kept the default behavior of linking to the tracker, but
after discussions with Brendan Murphy we decided on the current setup as
a good enough solution at the time. However, with the new policies in
place it sounds like this will no longer be adequate. So, In an effort
to accommodate both my development needs and the new policy, I would
like to propose three things:

 1. An additional triage policy that states that reports relating to

add-ons be left to the add-on maintainers to handle, even if they do not
keep to Blender’s definition of a bug. (this is partially stated in
Process/Addons - Blender Developer Wiki, but add-ons aren’t
mentioned at all in the Triaging Playbook)

 2. That a "User Feedback" button be added next to the "Report a

Bug" button in the add-on’s preferences.
2a. That an exception to the blender.org domain requirement be
added for user feedback to preserve add-ons’ current user feedback setups.
2b. If 2a isn’t possible, I think the next logical place would
be to move feedback threads to the User Feedback section of devtalk, but
since you don’t want to take feature requests in devtalk and have talked
about removing the entire section, this seems rather pointless.

 3. That external "Report a Bug" links are allowed to remain until

#1 & #2 are in place.

B. I accept design discussions in my add-on’s task and use it as a
central place to keep track of the development of my add-on, so it is
ever growing. While this perfectly suits my development and has
benefits from a Git/Phabricator point of view, I have seen from
discussions in chat that this is not something that is being
encouraged. Since an add-on is pretty much self-contained and there are
benefits to maintaining a main task for it, I propose that main add-on
tasks be explicitly allowed in a written policy and encouraged.

C. One of the new policies is this: “Base line is that each add-on that
gets bundled, is meant to function at the same quality level as other
Blender features. What we require from C/C++ we also require from Python
scripts, not only technically, but also following Free Software
principles.” which would seem to suggest that add-ons will now require
review for almost every commit, but Blender does not currently have the
resources to provide these reviews, plus I haven’t seen any evidence
that community add-ons are followed closely enough for most developers
to give a meaningful review outside of basic syntax and style. So can
you provide clarification as to what exactly is meant by this policy?

D. Would it be possible for bundled add-on authors to be notified when
things that will affect their add-ons are discussed, such as the recent
SPDX license or MVert struct changes, so that they aren’t caught off
guard and may have a voice in the discussion if desired? I’m not asking
for a personal email to be sent to every author, but adding the add-ons
(Community) tag to relevant Diffs is real easy and should do the job.

E. Can add-ons have bug fixes included in LTS release updates? If they
are allowed, what types of fixes would be accepted (since add-ons are
mostly self-contained I would hope that the type of fixes allowed into
the LTS update would be left to the discretion of the author/maintainer,
but if this isn’t the case, then what would be accepted)? And can
add-ons please be noted in the relevant policy documents?

Thanks.
Ryan Inch (Imaginer)

3 Likes
2

Reply by Thomas Dinges:
https://lists.blender.org/pipermail/bf-committers/2022-March/051296.html

Edit: Quoting here for brevity

Hey Ryan,

Thanks for your mail on this topic. Disclaimer: The following is my
opinion, a formal decision is up to the BF admins and the add-on module
team. :slight_smile:

A)

I don’t think external links for bug reports are explicitly covered by
the current key-requirements. They only mention to “offer the full
documentation on blender.org”.

The reason for these requirements are mainly to have everything on
blender.org, for users to make full use of the add-on without requiring
to access external sites or download additional extensions. In my
opinion this doesn’t strictly include its development. Some developers
maintain their add-on Github and just commit a new version to the
blender repository once in a while.

B)

Phabricator is a development platform and not the proper place for user
feedback and discussions. Development tasks are already interrupted by
user questions and off-topic discussions. I rather have the same rule
for everything (Blender itself and Add-ons) and not encourage people to
use Phabricator as a discussion platform.

Devtalk is the correct place for this, as long as this call for feedback
is initiated by the developer. We have feedback threads there already
(for example for Cycles). So feel free to open a feedback task there.

C)

They don’t require review for every commit, but review is always highly
encouraged. The same rules should apply for both Blender code and
add-ons, that’s the main reason for this point.

D)

API changes and implications for add-ons should always be communicated
properly. Tagging the add-ons project in related patches is a good idea.

E)

Add-on bugfixes can be included in LTS updates. But it should be fixes
alone and not new features. Same rules apply here again like for
general Blender code.

Best regards,

Thomas

2 Likes
3

You are welcome, and thank you for your opinion Thomas. :slight_smile: It was my hope with this thread to start a discussion so that the needs of bundled add-on developers could be accounted for in the formal decision by the BF admins. Unfortunately, this hasn’t really happened so far, but I am still hopeful that my proposals, along with the new policies in general, can be discussed by the community with the BF admins directly, here, like what is being done with the call for community participation in the new development platform.

As to the points you made, I would like to take this opportunity to discuss a few of them.

A)
You mention that the policy only states that add-ons have their documentation on blender.org, but I get the feeling that the spirit of the new rules is to have everything on blender.org to provide a unified experience for users. As you said, some developers maintain their add-ons externally, and this may actually be a better setup, but it also raises some practical concerns as to split development where users may still report bugs on blender.org, and developers working on the C side will likely just commit to that repository rather than making pull requests on add-ons’ external development platforms for any api updates, etc… All of that would be, of course, solvable, but I think it should be discussed and then laid out in policy documents to facilitate smooth, professional, development.

B)
I get wanting a unified approach to everything, but the needs of bundled add-on development compared to the needs of Blender development on the C side are different. Add-ons are much smaller, and are essentially mini-applications themselves, so without some central spot to anchor to, it’s really easy for them to disappear in the onslaught of information about everything else. I already have a feedback thread on Blender artists, but a thread isn’t really suited to keeping track of development. I do try to keep the more technical discussions on the development task, and at the moment it also does double duty as a landing page, so I feel it is mainly on topic, but as I mentioned above, perhaps it is better to move add-on development to external repositories if that is in line with the spirit of the new rules and the appropriate procedures are documented. And the external repositories could end up being on blender.org, depending on what is decided on for the new development platform.

C)
If the same rules should apply to Blender code, as you say, and add-ons, then for most commits the rule would be: no review, no commit (at least that has been what you’ve expressed in the past). I still don’t think that Blender has the resources to properly do this, especially if add-ons are being developed externally and new versions are only merged back in once in a while.

D)
Thanks, I think it will be very helpful to have add-ons being tagged when proposed API changes and such are being discussed adopted as standard procedure.

E)
Ah, okay, thanks. I did ask about this in a thread for the 2.83 LTS and never received a reply. Who should I talk to if I want to have a fix included in an LTS version, or would I just commit fixes I deem appropriate to the relevant branch? The current policy is to only port fixes for severity 1 issues, so would that be equivalent to just actual crashes of Blender, or include python tracebacks as well? What about performance bugs?

Thanks.
Ryan Inch (Imaginer)

4

@ideasman42 Do you have any thoughts on this?

@Ton Since you’re the one that drafted these new polices, can you provide some insight? As it is, the new policies are ambiguous and it leaves bundled add-ons in a bit of a tough spot (IMO).

@ThomasDinges I still welcome your opinion if you want to keep on discussing this.

I also think what I’ve mentioned here ties in with the new development platform being discussed and how bundled add-ons will/could work with that: Developer.blender.org - Call for comments and participation - #70 by Imaginer

5

Update from @ThomasDinges on blender.chat after some discussions he had with Ton and other developers in Amsterdam:

Having add-on development / bug reports / patches happening on blender.org is prefered, but having it outside is ok too. Ton brought up the idea of having an online repo for add-ons (something like addons. blender . org) where fully functional add-ons can be browsed and downloaded from. In the end if this should move forward, there needs to be a developer / module team to tackle these.

He further clarified that the online repo idea would be only for browsing/downloading add-ons, not development.

1 Like
6

Hi,
this is all very vague still. It’s only an idea to have an online platform for add-ons to browse and download them from. The Mozilla add-ons portal came up as example.

For this to move forward, someone has to coordinate the discussions and planning though.

1 Like