Mozilla L10n Tech team is working on a new localization/i18n framework for Gecko and Firefox based on L20n project. Since we have several years of experience we're using a new tracking bug and will migrate dependencies from the old one (bug 595812) and close it eventually.

We've decided that it's better to use a whiteboard flag [gecko-l20n] and leave bug dependencies to be just about bug dependencies and feature-landing dependencies. Resolving as INCOMPLETE.

This is too bad actually. With a bug dependency I can watch this bug only and get info on all things fixed with l20n, with the whiteboard flag I have to watch at least one whole component. Dependencies have been used in similar cases all along, why should it be different now?

(In reply to Philipp Kewisch [:Fallen] from comment #2) > This is too bad actually. With a bug dependency I can watch this bug only > and get info on all things fixed with l20n, with the whiteboard flag I have > to watch at least one whole component. Dependencies have been used in > similar cases all along, why should it be different now? Yes, I have the same feeling. I was watching this to follow the work as it lands, but now I have no way to do so unless I constantly search for the whiteboard tag or something...

There are a few answers here: For those of us working on the buglist, we started to realize that the semantics of "this blocks the gecko-l20n bug" wasn't consistent. It wasn't that this was "bugs that matter" or "bugs that block", but more "bugs more or less related, but possibly also like really blocking". In that sense, your expectations to know what's actually mattering in l20n land was probably not satisfied by watching this bug. The other is that as much as mozilla has a long history of using tracking bugs for things, the bugs team with Emma and Benjamin are actually getting rid of that. They've mothballed the Tracking product, for example, as a statement that bugs that track things that might just never get fixed aren't considered useful on their part. Which backs up our experience in the short time we used the tracker. And we had internal problems as we had multiple people working on multiple bugs, and the blocks-depends relationship between the two wasn't crisp enough to communicate what needed to land in one to unblock the other. Which is why we're using that particular relationship to be really about "this blocks me from working on that". Giving the blocks/depends relationship a strongly defined meaning is paramount to us being able to actually ship this thing, which is why we decided to cut away other use-cases. I've contemplated using the see-also relationship between "the cloud bug" and l20n-related bugs, but it didn't seem to be significantly more efficient than just a whiteboard field. see-also might signal if new bugs show up, but I don't think it sends signal if bugs are resolved. Not sure if that's worth another change? I also think that it would continue to have rather ambiguous semantics. With the whiteboard, we're fine with that, not sure if that serves your needs.

As one of the people working on L20n I appreciate the feedback and I'm happy to hear that you're following the project! We've put a lot of work into structuring our work and increasing the transparency of what we do. Please consult https://wiki.mozilla.org/L20n/Firefox which has a lot of information about the timeline, requirements and our progress. To echo what Pike said: we wanted to make dependencies meaningful so that we can clearly guide our day-to-day decisions by the dependency trees. Each feature which we intend to port to L20n is a deliverable which will have its own tracking bug. For instance, we're currently focusing our efforts on bug 1291693 and its dependency tree can tell a pretty comprehensive story: https://bugzilla.mozilla.org/showdependencytree.cgi?id=1291693&hide_resolved=1

I'm not saying that every single bug has to depend on this one. If there are multiple deliverables it would be ok for me to have meta-bugs for each deliverable as long as they either depend on this one or are small enough in number and frequency of filing that they can easily be searched. I would like to be able to follow l20n in a more fine-grained way than a high-level roadmap, and I am not interested in following all of Core/Localization just to do so. Especially if some bugs end up in other components, for example releng land this would mean I'd have to follow a lot more. If Emma and Benjamin are getting rid of tracking bugs I do think there needs to be an alternative. I can't instruct Bugzilla to send me email on a keyword or whiteboard tag, that would be needed in this case. I believe they are also trying to get rid of whiteboard tags, for that matter. On the contrary, there are efforts to document decisions on bugzilla and use the dependency tree for features that depend on this decision. So there are clearly some split directions here. In any case, bugzilla is probably not the best place to discuss this so I am willing to do further discussions elsewhere. I'd really like to be able to stay on top of l20n so I can make changes to Thunderbird rather earlier than later. Things take longer there already and if we wait until milestones are reached we may have no chance at all in keeping up with changes.

Attaching a diff between m-c and larch from December 2016. This is how far we got. We're now repurposing larch (bug 1333519) to land L20n in Firefox for Android first, so I took a dump of the diff to save it in case we'll want to look at it in the future.