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 <larsb...@mozilla.com> 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
