On 15/09/17 18:45, Dan Mosedale wrote:
I wonder if this isn't (in large part) a design problem disguised as a
behavior problem. The existing try syntax (even with try chooser) is so
finicky and filled with abbreviations that even after years of working with
it, I still regularly have to look up stuff and sometimes when I've been in
a hurry, I've done something more general than I really needed because it
was just too painful to figure out the exact thing.
I'd be pretty surprised if developers newer to the mozilla infrastructure
than I didn't end up doing this sort of thing substantially more frequently.
https://ahal.ca/blog/2017/mach-try-fuzzy/ seems like a fine step in the
right direction, and maybe that'll be enough.
But I do wonder if the path to saving substantial time and money in the
long run is to invest some real user-research / UX / design time into
designing a try configurator where it requires effort to do the
unnecessarily expensive thing, as opposed to the current situation, where
it requires effort to avoid the expensive thing.
I think that's a rather uncontroversial opinion. Historically we have
been hampered by the fact that the set of try jobs was basically unknown
and constantly changing, and the code was scattered across many
repositories. Now that taskcluster defines everything in a single place
and the majority of the code is in-tree it will be much easier to
experiment with different frontends that make it easy to select the
right jobs. That's what allowed ahal to write |mach try fuzzy|.
There is also a desire to have better change-based job selection, so
that the default behaviour can be "run the jobs that are most likely to
be affected by the change I just made".
However all of these improvements will take time, and in the meantime
there are problems being caused by too-high backlog, so some changes in
user behaviour will be helpful as we work toward better tools.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
