for franken-fox (see bug #360127), return complete updates instead of empty snippets? For certain malformed aus urls, we return an empty snippet. yesterday rob helmer suggest that we could returning snippets with just complete mars (and no partials) for these users, as a complete would fix the franken-mac state, assuming that the updater application was working.
Could this potentially mess up partner builds, or is the franken-fox scenario limited to non-partner releases?
> Could this potentially mess up partner builds, or is the franken-fox scenario > limited to non-partner releases? the frankenfox scenario is not limited to non-parter builds, but we would be returning complete-parter mars for them, as they are on different channels, right?
We do not have any such thing as complete-partner MARs at this point. Partner builds (from 2.0 forward at least) use the standard MARs, because they do not change files, only add the extension.
Would it be possible to break a 1.5.x partner build by upgrading to 2.0 and disabling the partner extension because of the major version change (install.rdf in .xpi isn't compatible w/ 2.0.0.x)?
(this is assuming there _are_ 1.5.x partner builds)
Yes. This is why we are going to explicitly disable partner updates from 15x -> 200x until we have generated custom MARs.
Note, users who are stuck here aren't always frankenfox users. cbeard has a laptop which no longer gets updates. he gets null snippets from AUS. His explanation was that he got some sort of build that was the first before an in-place respin. I believe cbeard and joduin have looked into this, and have some rough ideas of how many users are stranded in this spot. john / chris, can you follow up with some details?
(In reply to comment #7) > cbeard has a laptop which no longer gets updates. he gets null snippets from > AUS. His explanation was that he got some sort of build that was the first > before an in-place respin. Can you clarify what an "in-place respin" is?
> Can you clarify what an "in-place respin" is? did we have any release where we put up bits and then we (quickly) replaced them with the correct bits. I want to say we did that at some point during the past year (for mac, or both mac/windows), and the "bad bits" were up for only a short time. sorry, my memory is fuzzy and I don't have email on this. cbeard seems to have crisper details.
a new case of Frankenfox. The Build ID is correct for 184.108.40.206, but the Version Information under the Firefox Logo (220.127.116.11) is wrong. Trying to get update Logfiles.
You need to log in before you can comment on or make changes to this bug.