(In reply to Edwin Takahashi (:egao) from comment #9)
I understand their frustration, but I would like to point out that
--full flag exists to precisely permit developers to access the unfiltered list.
True, but the hope is that using
--full is a rare edge case that is only there for power users who know what they are doing. The risk comes with devs developing a habit of using it even when not necessary.
The problem I'm trying to address by adding to the blacklist is to prevent the situation where a user select all with
mach try chooser or
mach try fuzzy. Even worse, for
mach try syntax the user will in many cases select
all for a lot of things because figuring out what syntax works is too long.
Yes, this is a problem, and yes your solution would help improve it. Another way to solve this is to remove the
all alias to
./mach try syntax and put a hard cap on the number of tasks in
./mach try fuzzy. This will also annoy developers, but I think it might be more palatable for them.
valgrind are low-value tasks whose consumer isn't even well defined yet, let alone exist in some cases.
Yes those might be good candidates for the list.
I'm adding predominantly build tasks here, because this loops back to the topic discussed in the Smart Scheduling meeting this (2020/04/23) morning, that most of the build tasks aren't even clear why they run, who consumes them, or have any tests using the build as dependency.
A task that is unclear / has no ownership will still cause a backout just the same as well maintained one. If it is truly unmaintained, it shouldn't be running on mozilla-central in the first place.
Those are the situations I'm trying to catch with this extended blacklist. They aren't made permanently unavailable; just removed from the regular view unless developers explicitly know that they want to schedule such tasks.
Understood. I'm not saying the list should be empty (
valgrind seems like a prime candidate for it for instance). I'm just pointing out the negative side of diverging try from mozilla-central. I don't know how to weigh the cost in CI against the cost in developer salary / morale, we don't have data for it.