Regarding the issue tracking consolidation, I would be very cautious. For
the Shumway project, we moved from Github issues to Bugzilla because the
former are so limited. In particular, it's nigh impossible to properly
follow parts of Servo, which is becoming more and more of a problem the
larger the project grows. In Bugzilla, you can not only set finely-grained
notifications per component, but it's also possible to filter email
notifications in powerful ways. I.e., I have filters set up to tag
notifications for bugs I'm CC'd on, I filter notifications from different
components into different folders, etc. And I'm not even talking about the
lack of powerful dependencies between issues, like Bugzilla has them for
bugs.
SpiderMonkey and related components create roughly the same number of
notifications as Servo, the main project, does. With my filters in place,
it's easy to vaguely follow what's going in general, while ensuring that
the parts that're particularly important to me don't get lost in the noise.
In Servo, this just isn't possible. (Or at least I haven't yet figured out
how to do it.) Just as it wasn't in Shumway, and we tried hard to come up
with a good system before moving to Bugzilla.
Now I know that various factors make it undesirable to move to
bugzilla.mozilla.org, so I'm not arguing for that. I would argue that
having separate issue tracking for individual projects gets us as least
some parts of what Bugzilla can do with components, though. ISTM like the
downsides that incurs are easier to overcome than the ones caused by
monolithic issue tracking in the main project, though.
On Tue, Nov 10, 2015 at 1:50 AM, Lars Bergstrom
wrote:
> https://github.com/servo/servo/wiki/Meeting-2015-11-09
>
> Bonus meeting from last week on Oxidation (Rust/Servo in Gecko):
> https://github.com/servo/servo/wiki/Oxidation-2015-11-05
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
