Part of the performance improvements we planned for Places, the history, bookmarking and tagging subsystem of Firefox, involved changes to the way we generate bookmarks backups.
While the rapid release trains provide a very good userbase for testing a feature, it's only at the release time that the "real world" feedback allows to prioritize improvements.
Unfortunately, at that time, there's the concrete risk of a disconnection:
- the user sends valuable feedback
- the development team is already busy on something else
Thanks to the open and transparent nature of the Mozilla project, the feedback is never lost, very often it naturally converts to bugs and discussions. On the other side this disconnection may cause a delay before actionable items are created.
It's often hard to write cross-platform code for console coloring, and for mach there have not been exceptions. It colorizes build and tests output, so that you can easily scroll and find warnings and failures, but unfortunately only on Unix consoles.
We are not new to this kind of issues in the Windows build environment, and there's a bug filed to properly support that, though, in the meanwhile, we can apply the same trick used with pymake to get colorization on mach. Kudos to Shawn Wilsher and Justing Dolske for first implementing this idea with pymake, now let's also colorize our mach build!
This is a re-post from mozilla.dev.extensions to try to reach a broader add-ons developers public.
Since everyone loves not having to look at tbpl, I'd like to point out some basic hints to make mozilla-inbound sheriffs happier. For any questions, or if you need help with the trees, ask to a sheriff in #developers IRC channel.
If you don't manage an add-on that is using Places bookmarks GUIDs, you can stop reading here.