Re: Announcing ./mach busted

2019-04-28 Thread Mike Hommey
On Sun, Apr 28, 2019 at 04:58:59PM -0400, Randell Jesup wrote:
> >TL;DR - In bug 1543241 (alias 'mach-busted'), we now have a central
> >clearinghouse of bugs for broken mozilla-central tooling. You can invoke
> >|./mach busted| to get a list of known outstanding issues, and |./mach
> >busted file| to report a new one.
> 
> In case it's not obvious (it wasn't to me), 'file' is a keyword, not a
> file to include, and all you really need to do is file a bug that blocks
> bug 1543241 (or add that to an existing bug).  We also should name that
> bug, for easy in referencing in the future (I propose "mach-busted" ;-) )

It already has that alias.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Announcing ./mach busted

2019-04-28 Thread Randell Jesup
>TL;DR - In bug 1543241 (alias 'mach-busted'), we now have a central
>clearinghouse of bugs for broken mozilla-central tooling. You can invoke
>|./mach busted| to get a list of known outstanding issues, and |./mach
>busted file| to report a new one.

In case it's not obvious (it wasn't to me), 'file' is a keyword, not a
file to include, and all you really need to do is file a bug that blocks
bug 1543241 (or add that to an existing bug).  We also should name that
bug, for easy in referencing in the future (I propose "mach-busted" ;-) )

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Announcing ./mach busted

2019-04-15 Thread Dave Townsend
This is awesome. It is so frustrating to hit issues that stop you from
being able to build and test your work. Glad that we're making it easier to
solve issues as you find them.

On Thu, Apr 11, 2019 at 9:12 AM Bobby Holley  wrote:

> TL;DR - In bug 1543241 (alias 'mach-busted'), we now have a central
> clearinghouse of bugs for broken mozilla-central tooling. You can invoke
> |./mach busted| to get a list of known outstanding issues, and |./mach
> busted file| to report a new one.
>
>
> Few things burn up productivity quite like broken tooling. If a developer
> cannot build, launch, test, or debug the code, they cannot meaningfully
> work on it.
>
> We’ve made significant progress in recent years towards tools that break
> less often. This work comes in various forms: making the tools more robust
> and automatic, testing them better, sandboxing them, and reducing the
> supported configuration matrix. This is great stuff - but voluminous
> technical debt and limited resources mean we aren’t yet at the doorstep of
> a world where tools never break.
>
> In the short term though, we can substantially mitigate the impact of
> tooling breakage by reducing the average time spent getting people back on
> their feet. Historically, the developer experience in these situations
> tends to look like this: https://bholley.net/images/productivity.gif
>
> This happens because we lack a reliable way to steer developers around
> known pitfalls while they’re being fixed. Filing a bug isn’t a good way to
> get immediate answers, and searching all of Bugzilla is hit-or-miss. An IRC
> ping often works, but one needs to guess which person got all the previous
> pings about this same issue and therefore knows the workaround. In
> practice, this results in a barrage of pings to a few catch-all experts,
> who then have less bandwidth to fix the tools.
>
> My hope is that mach-busted can help by centralizing all the active
> showstoppers in a list that’s easy for both the users and maintainers of
> the tools to scan. This only works if the list stays small - so if the
> proper fix will take time, we should land a temporary fix to make the tool
> fail gracefully with a suggested workaround (see bug 1542862 for an
> example).
>
> It also only works if developers record new problems they encounter with
> |./mach busted file|. You may have already tumbled into the lava, but you
> can save many future lemmings from the same fate.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Announcing ./mach busted

2019-04-11 Thread Mike Conley
\o/

Thank you for this!

On 2019-04-11 12:11 p.m., Bobby Holley wrote:
> TL;DR - In bug 1543241 (alias 'mach-busted'), we now have a central
> clearinghouse of bugs for broken mozilla-central tooling. You can invoke
> |./mach busted| to get a list of known outstanding issues, and |./mach
> busted file| to report a new one.
> 
> 
> Few things burn up productivity quite like broken tooling. If a developer
> cannot build, launch, test, or debug the code, they cannot meaningfully
> work on it.
> 
> We’ve made significant progress in recent years towards tools that break
> less often. This work comes in various forms: making the tools more robust
> and automatic, testing them better, sandboxing them, and reducing the
> supported configuration matrix. This is great stuff - but voluminous
> technical debt and limited resources mean we aren’t yet at the doorstep of
> a world where tools never break.
> 
> In the short term though, we can substantially mitigate the impact of
> tooling breakage by reducing the average time spent getting people back on
> their feet. Historically, the developer experience in these situations
> tends to look like this: https://bholley.net/images/productivity.gif
> 
> This happens because we lack a reliable way to steer developers around
> known pitfalls while they’re being fixed. Filing a bug isn’t a good way to
> get immediate answers, and searching all of Bugzilla is hit-or-miss. An IRC
> ping often works, but one needs to guess which person got all the previous
> pings about this same issue and therefore knows the workaround. In
> practice, this results in a barrage of pings to a few catch-all experts,
> who then have less bandwidth to fix the tools.
> 
> My hope is that mach-busted can help by centralizing all the active
> showstoppers in a list that’s easy for both the users and maintainers of
> the tools to scan. This only works if the list stays small - so if the
> proper fix will take time, we should land a temporary fix to make the tool
> fail gracefully with a suggested workaround (see bug 1542862 for an
> example).
> 
> It also only works if developers record new problems they encounter with
> |./mach busted file|. You may have already tumbled into the lava, but you
> can save many future lemmings from the same fate.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform