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. :)
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
Am 11.03.2022 um 07:42 schrieb Ryan Inch via Bf-committers:
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 https://wiki.blender.org/wiki/Process/Addons, 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)
_______________________________________________
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers
--
Thomas Dinges - tho...@blender.org - www.blender.org
Developer Community Coordinator at Blender
Buikslotermeerplein 161 - 1025 ET Amsterdam - The Netherlands
_______________________________________________
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers
