It appears that the l10n-drivers submitted an incorrect changeset for the Macedonian build for Firefox 3.5 RC 3. Consequently, there was a missing entity in the "Find updates" sub-menu in the Help menu of the mk version. Can we use this bug to explore if/how a customized one off-repack for Macedonian would happen? Bug 501343 gives some more background.
So, what will it be? I have people with expectations here :)
Damjan, we need to ask you and your community for a bit of patience. This is on the build team for the most part, and they just had one hell of a time shipping a lot of software. I hope they partied hard, and pick this up as soon as they're sober again. We need to figure out if we're running into some awkward pitfall, like braking software updates in a different surprising way :-/. That thinking is better done with your head on. Once we make the call here, though, it should be a pretty quick turnaround.
Component: Release Engineering: Custom Builds → Release Engineering
QA Contact: custom-builds → release
Component: Release Engineering → Release Engineering: Custom Builds
QA Contact: release → custom-builds
Let's merge bug 501892 into this one, as they're the same thing in terms of impact and work and the steps we need to do to get them up.
Depends on: 501596
Summary: Create a one off-repack for Macedonian [mk] version of Firefox 3.5 → Create a one off-repack for Macedonian [mk] and Serbian [sr] version of Firefox 3.5
John tells me that we're going to wait until 3.5.1 to fix these.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
I just talked with beltzner and we're not yet determined on how we are going to handle the issue. We might not respin in the end, yes. Note that I don't appreciate the style of the messaging here. I'm in the process of writing a detailed mail to both Filip and Damjan.
(In reply to comment #6) > I just talked with beltzner and we're not yet determined on how we are going to > handle the issue. > > We might not respin in the end, yes. > > Note that I don't appreciate the style of the messaging here. > > I'm in the process of writing a detailed mail to both Filip and Damjan. Apologies. I was just relaying what I was told. I'll step back here and let you/beltzner/john deal with this.
(In reply to comment #7) > (In reply to comment #6) > > I just talked with beltzner and we're not yet determined on how we are going to > > handle the issue. > > > > We might not respin in the end, yes. > > > > Note that I don't appreciate the style of the messaging here. > > > > I'm in the process of writing a detailed mail to both Filip and Damjan. > > Apologies. I was just relaying what I was told. I'll step back here and let > you/beltzner/john deal with this. Axel: Sorry if there was any confusion here, Ben was just relaying what I'd heard from beltzner. We were not trying to do any public messaging in this bug, just trying to accurately update our bug-tasks with the information we had. From your email this afternoon, it looks like this is now confirmed as WONTFIX, so this bug can stay as-is. However, if I misunderstood your email, or if the situation changes, feel free to reopen this bug and move to RelEng:Future while discussions continue. Sound reasonable?
Axel, and the rest of Mozilla folk: In the interest of transparency, can you please shed some light on our decision to wait for 3.5.1 here in the bug? I have been getting some heated emails because of this, so it seems that people do not fully grasp the reasons for the decision. I think that the dust will settle faster if you were to explain what went on. I am firmly convinced that waiting until 3.5.1 to re-introduce the affected locales is the only rational engineering decision.
Marking VERIFIED. To elaborate on the background for this: We didn't manage to get one-off builds spun, and 3.5.1 isn't that far out, so "we" decided to wait with shipping mk and sr versions for 3.5.1, and have them working fine then. We intend to manually put up upgrades for those on the broken versions of 3.5. The update experience there will be a tad challenging, i.e., only automatic updates will be picked up. There is no way to beef up the download or so by manual interaction. Once the update is downloaded, the UI notifications for a new update being available will trigger, and the Help menu entry will change. The dialog for that menu item will still show an xml parsing error. Closing Firefox and restarting it will apply the update OK though.
Status: RESOLVED → VERIFIED
Component: Release Engineering: Custom Builds → Release Engineering: Releases
Product: mozilla.org → mozilla.org
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.