Here is something that got me thinking recently: should we use the same workflow with regards to marking bugs as fixed for l10n bugs that we use for development bugs? Let me try to explain.
For development, the process takes place simultaneously on several branches. For example right now, we work on trunk (mozilla-central, Firefox.next), 1.9.1 (releases/mozilla-1.9.1, Firfox 3.5) and 1.9.0 (CVS trunk, Firefox 3.0.x). When a bug receives a patch, it first lands on trunk, and the bug is marked as fixed. Then it lands on branch(es), after getting needed approvals, and the bug is given the fixed-* keywords, for instance, fixed1.9.1.
I have a feeling that this workflow doesn’t fit well into the localization process. The localization efforts often focus on only one branch. In the current case, that’s 1.9.1. Some localizers like to keep their 1.9.1 and central repos in sync, and that’s great, but we don’t require them too. If they prefer working on 1.9.1 only, that’s perfectly fine. After all, strings on trunk have higher probability of changing, so it’s understandable that someone prefers to wait until they stabilize. I.e. until they land on a more stable branch.
So translations land first on 1.9.1, and for many localization, they will only be pushed to central after the 3.5 release, at which point central will no longer be central, but will be given its own branch. The process will start over: the localization efforts will focus on this branch, because this is where the next major release of Firefox will come from.
As you can see, for localization the workflow is reverse: we first translate on the more stable branch, and then port over to the dev branch (trunk). And this is what made me start thinking whether we should change the rules of marking the bus as fixed.
Why is this a problem? Let’s take Assamese as an example (just because it illustrates my point quite well and I’ve been working on it recently). Bug 443139 is the Firefox 3.5 release tracker for Assamese and it’s blocked by a couple of bugs that will need to be resolved before we can release Assamese version of Firefox. In fact, most of them have been already resolved, so we’re really close to releasing Assamese. Congrats to the Assamese team :)
If you look for example on the “Firefox 3 RSS reader setup for Assamese” bug (bug 443145), you’ll notice that it was marked as fixed and has a fixed1.9.1 keyword. That’s because it was fixed on both trunk and branch. So the bug’s status is now “resolved fixed” (thanks to the landing on trunk), and it doesn’t block the release tracker anymore.
But now take a look at the “Search engine setup for Firefox 3 for Assamese” bug (bug 443142). The fix landed on 1.9.1 only, so the bug has the fixed1.9.1 keyword, sure. But since it hasn’t been yet fixed on central (for Firefox.next, mind you), the bug’s status is “new”, and it is still blocking the 3.5 release tracker. Why the lack of landing on central should block a 3.5 release?
That’s a problem for me, because it makes using and following the tracker bugs harder. Of course the right question to ask here is “if we mark this bug as resolved fixed right now, how do we make sure that the fix lands for Firefox.next, too?”. I don’t have a good answer to this yet. But even in the current workflow, if the fix lands for Firefox.next after mozilla-central gets branched again, will we mark the bug as fixed, or maybe just add a fixed1.9.2 keyword? (or a different one, depending on what the name of the branch will be).
I don’t have any concrete proposals right now to address the problems described above. I feel that we should just resolve bugs as fixed when the fix lands on current next-major-release branch (1.9.1 these days). We should still use keywords to make it easier when looking back at fixed bugs to figure out on which branches they were fixed. Lastly, next time we branch from trunk, we should somehow make sure all the fixes are included. I’m not yet sure how, though.
What do you think? I wanted to share my thoughts on this out in the public. I’d be grateful for your comments!