This came up for Thunderbird 188.8.131.52, which is shipping the Korean locale (ko) again after skipping 184.108.40.206. Patcher2 doesn't generate a 2.0b2 -> 220.127.116.11 update. https://aus2.mozilla.org/update/1/Thunderbird/2.0b2/2007011615/WINNT_x86-msvc/ko/betatest/update.xml There are less than 5 pings a day for 2.0b2 ko builds, so we're not missing a great swath of users, but it'd be great to plug the hole at some point.
Summary: [patcher2] Update not generated if locale not skipped for one release → [patcher2] Update not generated if locale skipped for one release
This happens for Firefox also... anything that uses updates.
Priority: -- → P3
Assignee: build → nobody
QA Contact: mozpreed → build
Hit this on Firefox 3.0b4 for 3.0b2 el and es-AR.
Component: Release Engineering → Release Engineering: Future
QA Contact: build → release
I'm looking into this. Setting up patcher is very painful, so I took a detour to bug 444266 to put some basic documentation into it. It looks like there is a mechanism (MozAUSConfig::ReadPastUpdates()) which scans all the old releases and makes sure that all the old update channels go somewhere: # # Parses all the past-update lines, and adds the past update channels to the # update-TO release. Not that useful? # It looks like this code is doing for channels what we want to happen for locales. Not sure when I'll have time to get further, so not taking the bug for now.
(In reply to comment #3) > I'm looking into this. Setting up patcher is very painful, so I took a detour > to bug 444266 to put some basic documentation into it. > > It looks like there is a mechanism (MozAUSConfig::ReadPastUpdates()) which > scans all the old releases and makes sure that all the old update channels go > somewhere: > > > # > # Parses all the past-update lines, and adds the past update channels to the > # update-TO release. Not that useful? > # > > > It looks like this code is doing for channels what we want to happen for > locales. > > Not sure when I'll have time to get further, so not taking the bug for now. > Followed this up, this just reads the "past-update" entries (as it says in the comment, duh), so not useful for the purposes of this bug Notice that MozAUSConfig::ExpandConfig() does build up a list of locales for each previous release, so the data needed here is already available. There is some logic in CreateUpdateGraph() that tries to figure out which locales intersect, going to focus on understanding that function next.
Mass move of bugs from Release Engineering:Future -> Release Engineering. See http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.
Component: Release Engineering: Future → Release Engineering
8 years ago
Assignee: nobody → rail
Do we want to see partial or complete updates in the snippets? Providing complete mars in the snippets will be easier, because we eliminate the partial mar generation step (and download prev. complete mars of course).
Completes are fine in this situation IMHO.
Created attachment 475478 [details] [diff] [review] [WIP] Use one of the previous release WIP patch, tested a bit. At the moment this patch generates partial updates using one of the previous releases, but it not ideal: Partial mar name and bouncer link don't contain the version used for partial mars (4.0b4-4.0b5 instead of 4.0b1-4.0b5 for example), which is good for automation but doesn't reflect the content of the mar. If we are OK with this, the patch is almost done (need to test it in staging using different scenarios).
First off, sorry for not getting to this for ages, but this patch scares me a bit. patcher being opaque doesn't help any. What testing have you done on it ? If the patch gets smaller and we lose the partial naming problem by only doing complete updates then I'm definitely in favor of that.
I tried to document the changes I've done, but unfortunately it's hard to understand them without running patcher in debug mode with and without these changes. Probably it will be better to use this bug report as a test case for AUS3, so I mark it as P5 and assign it to Nick (just to not get it lost in the future).
Assignee: rail → nrthomas
Priority: P2 → P5
Attachment #475478 - Flags: review?(nrthomas) → review?
Rail, thanks for your heroic effort on patcher2 but I think we should just fix this in AUS3. In my current head-model we get it for free by removing explicit from -> to mappings. In the meantime we can bridge any gaps manually as we have the few times in the past we've run into this. So far the Fx 4.0 betas have all had additive changes to shipped-locales, l10n-merge has probably helped there.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WONTFIX
To be clear, is there a bug on file tracking this ability for when aus3 comes around... That is, "skipped release with a locale needs to be sure updates work from older releases to a newer release with it" or some such?
I don't recall a specific bug on that. However this should just fall out 'for free' with AUS3, since serving an update only requires that the locale was built for start and end point of the update, rather than every release in between.
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.