Old versions of Jetpack have known serious issues, and some of them cause massive memory leakages, especially in newer versions of Firefox. Since we're no longer doing automatic repacks, we need to make an effort to get add-ons with older versions upgraded. Since, according to my understanding, we're going to be sending emails to add-on authors about where to obtain repacked versions of their add-ons and how to update them, that would be a good first step. Beyond that, we need a way to get a list of full reviewed add-ons using older versions of Jetpacks and to notify their authors that if they don't upgrade within a reasonable time period, their add-ons will be downgraded for preliminary review. In the future, depending on how long it's going to take to bundle Jetpack with Firefox, we should have a method to send notifications to add-on authors if they haven't upgraded within a few weeks of the latest Jetpack release, or sooner for releases with major fixes.

Could be a dupe of bug 751466 or bug 773288.

It's definitely not a dup of 773288, but it's related. This is specifically AMO-related, whereas 751466 is more general, but I suppose they can be merged.

The number of leaks that have been fixed in recent versions of JetPack is large, so I'd love to see this happen. Is it possible to fast-track reviews of add-ons if the only change is to the JetPack version?

We can't detect repacks automatically, so the reviewer would need to look at the source anyway. Most SDK add-ons are in a fast-track queue, and reviews are taking a fairly short time as it it.

(In reply to Jorge Villalobos [:jorgev] from comment #5) > as it it. ... as it is.

FYI the new re-packer script we are testing will flag xpi packages that have been re-packed. This will all be better soon. ref: https://github.com/ochameau/jetpack-repacker

How will it flag them, and what will we be able to do with the flag? I think it should be relatively easy to test for whether the only changes from the previous version were in SDK directories, but I'm not sure if it's worth the trouble.

Here's the relevant code: https://github.com/ochameau/jetpack-repacker/blob/master/unpack.py#L408 Basically, we add a property to harness-options.json when running cfx xpi. The main reason we want this is to help us decide what to do with the add-on version number - if things all align, we 'bump' the version in install.rdf, thereby ensuring that the user is prompted to upgrade to the re-packed xpi.

I have a list of full reviewed add-ons using old versions of the SDK who will be warned that they need to upgrade or their add-ons will be downgraded to preliminary status. Jeff, at what version do you want to make the cut-off?

> I have a list of full reviewed add-ons using old versions of the SDK who > will be warned that they need to upgrade or their add-ons will be downgraded > to preliminary status. Jeff, at what version do you want to make the cut-off? That was over 6 weeks ago. How about now?

This is partially done. We downgraded add-ons using non-release and very old versions of the SDK. We still need to message the rest of the devs on the list. That's on me.

(In reply to Jorge Villalobos [:jorgev] from comment #12) > This is partially done. We downgraded add-ons using non-release and very old > versions of the SDK. We still need to message the rest of the devs on the > list. > > That's on me. Will you be able to do this soon?

The emails went out last week. See bug 841121].

> The emails went out last week. See bug 841121. Great! Can you CC me to that bug? I'm not authorized to view it :)

(In reply to Nicholas Nethercote [:njn] from comment #15) > > The emails went out last week. See bug 841121. > > Great! Can you CC me to that bug? I'm not authorized to view it :) It's just an IT bug for sending the messages, nothing particularly interesting :) (In reply to Kris Maglione [:kmag] from comment #14) > The emails went out last week. See bug 841121]. Also, we're now requiring SDK 1.13.2 and above for full review status, and soon something similar will need to be done with 1.14 and per-window private browsing mode, so I think this can be considered fixed.

> Also, we're now requiring SDK 1.13.2 and above for full review status So currently no add-on on AMO which has an SDK older than this has full-reviewed status?

Add-ons that were previously approved continue to be approved. We did downgrade all add-ons using old versions of the SDK, but I don't recall where we drew the line (definitely lower than 1.13.2). For the 1.14 upgrade there's a plan to repack all public add-ons, so it would be after then that the majority of public add-ons would be using a recent version of the SDK.

> We did downgrade all add-ons using old versions of the SDK, but I don't recall where we drew the > line (definitely lower than 1.13.2). I think before declaring this bug to be fixed, it would be helpful to know which version we drew the line at. We would then need to evaluate whether we've fixed any leaks in the SDK since then. Is that OK with you?

I think the cutoff was at ancient versions of Jetpack. I agree that this isn't fixed.

If we drew the line to make add-ons with exposedProps problems, that line would be 1.9. The compat overrides data in AMO should give you a clue. I don't have a good handle on when this was done though.

It looks like we downgraded add-ons with Jetpack <1.0, and non-release versions <1.9, which is definitely insufficient.

<bump> Super-old versions of the add-on SDK's cause bad MEMSHRINK bugs. Please confirm that the AMO has a policy for blocklisting old SDK versions.

There are still 115 add-ons with full review and Jetpack versions < 1.9, most of which are much older than that. If they've already been warned, I think we should downgrade them, and we should consider soft blocking those with considerable user counts and known memory issues.

(In reply to Jet Villegas (:jet) from comment #23) > Super-old versions of the add-on SDK's cause bad MEMSHRINK bugs. Please > confirm that the AMO has a policy for blocklisting old SDK versions. You'll need to qualify what you mean by bad before we can make a call on blocklisting. If comment #22 is where we are at present, we should start working on whatever step is next to push developers forward. I know there's an automatic repack planned for 1.14, but I don't recall what it entails for developers with older versions. Will?

Jorge: yes, here's the plan: https://github.com/mozilla/addon-sdk/wiki/Firefox-22-repack All add-ons build with a version of the SDK <1.14 will be marked incompatible with Firefox 22.

(In reply to Will Bamberg [:wbamberg] from comment #26) ... > All add-ons build with a version of the SDK <1.14 will be marked > incompatible with Firefox 22. Just to be clear, we really need to do this for a variety of reasons including memshrink. It will be a bit painful for some developers, it will decrease the number of compatible SDK-based add-ons on AMO, but it's the right thing to do for users. I think Will has a great plan in place for tackling this, but please review and provide feedback if you have concerns about any of it.

Will, the document linked says the latest possible date for this to happen should be May 25th. Has any progress been made?

(In reply to Kris Maglione [:kmag] from comment #28) > Will, the document linked says the latest possible date for this to happen > should be May 25th. Has any progress been made? Not as much as I'd have liked. As of today I have a list of add-ons that we are not going to try to repack. I haven't yet checked this list, but if it is correct we ought to be able to email these people as soon as I can work with IT to send out the emails. I also have a list of add-ons that passed, and those that failed, automated smoke tests. But there are some discrepancies there - in particular, some add-ons show up in both lists. I need to talk to Jordan, who ran the tests, to sort that out - but he's at a conference this week. We should also be able to start manually smoke testing in the next couple of days, and then we'll be able to notify people whose add-ons failed that they have failed.

We've repacked all of the add-ons that we can. I think it's time to downgrade any public ones not using 1.14, and consider setting compatibility overrides for those using really old versions of the SDK.

(In reply to Kris Maglione [:kmag] from comment #30) > We've repacked all of the add-ons that we can. I think it's time to > downgrade any public ones not using 1.14 Let's get a list and see if it's something that should be done manually or with a script. > and consider setting compatibility > overrides for those using really old versions of the SDK. That's bug 885381.

There are 131 fully reviewed add-ons with old versions of the SDK.

> There are 131 fully reviewed add-ons with old versions of the SDK. So what now? Contact the authors and ask them to repack?

We ran a migration to add compat overrides for those add-ons so they can't be installed or run on versions of Firefox beyond 21. We've already contacted them and asked them to repack, so any remaining public add-ons should probably just be downgraded.

> any remaining public add-ons should probably just be downgraded. Time to do this? :)

I'll do it tomorrow.

Are we done here, Kris?

Sorry, it seems I forgot about this. It's done now.

Thanks, Kris!