418129 - Need branch-based OS ignore list

Status: VERIFIED FIXED

Description

[Reed Loden [:reed] (use needinfo?)]

Currently, AUS only supports a global OS ignore list. For the upgrade from Firefox 2 to Firefox 3, it would make sense to have a per-branch OS ignore list so OSes like Win98, etc., could be ignored for Firefox 3 but still work for Firefox 2.

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

Make sense, yes, not sure that it blocks the release of the product.

Comment 2

[Nick Thomas [:nthomas] (UTC+13)]

To flesh it out a bit,
* for a Firefox 2.0.0.x to 3.0.y major update we need to 
 * not update Win32 that's Win95/98/Me (anything older than 2k)
 * not update Mac older than 10.4
 * not update Linux with GTK older than 2.10 (see also bug 418131)
* for 2.0.0.x we'll need to continue ignoring the OS
* for 3.0.y we probably don't need any restrictions (if the builds don't run you can't update 'em!)

I think we'll need this sooner rather than later, perhaps even before Fx3.0.1 comes along (opinions vary). Got any cycles ?

Comment 3

[Tony Chung [:tchung]]

this blocks major update fx2.x -> fx3.x work.  can we get this into the next fix?

Comment 4

[Nick Thomas [:nthomas] (UTC+13)]

It's a server side change, dunno how you want to track that with flags.

Comment 5

[Henrik Skupin (:whimboo)]

(In reply to comment #2)
> * for a Firefox 2.0.0.x to 3.0.y major update we need to 
>  * not update Win32 that's Win95/98/Me (anything older than 2k)

Same should also apply to Windows NT.

Comment 7

[Samuel Sidler (old account; do not CC)]

If 3.0.2 is to be the major update (I'm not saying it is, just say if it were to be), we need this fixed. Mike, what kind of timeline would we be looking at for getting this fixed?

Comment 8

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Any update on this? 

Comment 9

[Michael Morgan [:morgamic]]

Here's what needs to be done:
* write acceptance test for this case
* add configuration for OS -> product/version mappings
* add update exceptions for configured os/product/version

I think this would be granular enough.  The only tricky part is telling the difference between a major update and regular update.  Unfortunately this means that we won't be able to avoid reading the snippets and the logic for this will have to happen pretty late in execution.

Comment 10

[Michael Morgan [:morgamic]]

Not 100% sure when this can be finished by, but it'll take 1-2 days to get it right.  I'll post an update tomorrow or once I have something.

Comment 11

[Samuel Sidler (old account; do not CC)]

Doesn't block 1.9.0.2 but does block MU (since it's server side it doesn't need to block the release).

Comment 12

[Michael Morgan [:morgamic]]

Still writing tests, will finish today.  How much testing time do you guys need before we deploy it?

Comment 13

[Samuel Sidler (old account; do not CC)]

(In reply to comment #12)
> Still writing tests, will finish today.  How much testing time do you guys need
> before we deploy it?

Probably half a day to a day. If it's deployed by Wednesday morning, we'd be great, Thursday morning would probably be fine as well.

Comment 14

[Michael Morgan [:morgamic]]

Only think left for me is to enumerate these values:
 * not update Win32 that's Win95/98/Me (anything older than 2k)
 * not update Mac older than 10.4
 * not update Linux with GTK older than 2.10 (see also bug 418131)

I don't know what these specific os values are.  Does someone have a list?

Comment 15

[Henrik Skupin (:whimboo)]

(In reply to comment #14)
> Only think left for me is to enumerate these values:
>  * not update Win32 that's Win95/98/Me (anything older than 2k)

Look like everything lower 5.0:

95b/c: Windows 4.00.1111 b, Windows 4.03.1214 b, Windows 4.03.1214 c
98:    Windows 4.10.1998
98 SE: Windows 4.10.2222
Me:    Windows 4.90.3000

Comment 16

[Mike Connor [:mconnor]]

Windows NT 4.0 (I don't have the values we care about) also matters.

Comment 17

[Michael Morgan [:morgamic]]

So safe to say anything Windows 4.x can be blocked for 2->3 major update?

Comment 18

[Ted Mielczarek [:ted.mielczarek]]

Linux update URLs look like this now:
https://aus2.mozilla.org/update/3/Firefox/3.1a2pre/20080819050919/Linux_x86_64-gcc3/en-US/nightly/Linux%202.6.24-19-generic%20(GTK%202.12.9)/default/default/update.xml?force=1

The GTK version is lumped into the OS version field.

Comment 19

[Michael Morgan [:morgamic]]

Created attachment 334604 [details] [diff] [review]
v1, applied against AUS2_PRODUCTION

- refactor supportedPlatforms config array
- add boolean method isSupported in patch.class.php
- add logic in main index to skip XML output if not supported
- added acceptance tests for requested operating systems
- fixed some urlencoding issues in Verify.py

Tests here (need VPN):
http://khan.mozilla.org:7777/VerifyAus?test

Test cases explained:
   1.  major update is served for Windows 2000
   2. major update is served for Windows XP
   3. major update is served for Windows Vista
   4. major update is served for OS X 10.4
   5. major update is served for OS X 10.5
   6. major update is served for Linux with GTK > 2.10
   7. no update is served for Windows 95
   8. no update is served for Windows 98
   9. no update is served for Windows ME
  10. no update is served for OS X 10.3
  11. no update is served for Linux with GTK < 2.10

See patch for the specific OS_VERSION strings that are blocked.

Comment 20

[Reed Loden [:reed] (use needinfo?)]

Comment on attachment 334604 [details] [diff] [review]
v1, applied against AUS2_PRODUCTION

>+            'GTK 2.0',
>+            'GTK 2.2',
>+            'GTK 2.4',
>+            'GTK 2.6',
>+            'GTK 2.8'

What about the odd numbers? All _releases_ are even numbers, but there are definitely GTK versions out there that are 2.<odd>.*.

Won't this break things like GTK 2.20, etc.? Latest seems to be 2.13.7 (for 2.14), but 2.20 doesn't seem that far out.

Comment 21

[Michael Morgan [:morgamic]]

Yeah, good point about 2.20.  Odd numbers weren't listed as major releases on wikipedia.  It's been kind of irritating tracking down all these strings.

So... I can just add odd numbers I guess and add the trailing . to make sure we don't mistake a future major release with one of the old releases.

Comment 22

[Michael Morgan [:morgamic]]

Created attachment 334607 [details] [diff] [review]
v2, with adjust GTK stuff

I want to avoid using regexes if possible, so I'll just list the four extras.

Comment 23

[Reed Loden [:reed] (use needinfo?)]

Add "GTK 2.9.", too.

Comment 24

[Michael Morgan [:morgamic]]

Created attachment 334608 [details] [diff] [review]
v3, and... GTK 2.9.

:X

Comment 25

[Wil Clouser [:clouserw]]

Comment on attachment 334608 [details] [diff] [review]
v3, and... GTK 2.9.

I tested by adding a 2.0.0.16 -> 3.0.1 update with Windows NT 4.  Before the patch I got the update, afterwards I didn't.  I think we're ready for qa.

Comment 26

[Michael Morgan [:morgamic]]

This is checked in and tagged. Production push bug is here: bug 451484

QA signed off on staging this evening (juanb, tomcat).

Comment 27

[Reed Loden [:reed] (use needinfo?)]

Not sure which patch you committed, but it's definitely not v3.

Current config-dist.php has:
            'GTK 2.0',
            'GTK 2.2',
            'GTK 2.4',
            'GTK 2.6',
            'GTK 2.8'
... which is wrong.

Please commit the correct patch! :)

Comment 28

[Michael Morgan [:morgamic]]

Checked in the right GTK values.  Thanks for catching this.

Comment 29

[juan becerra [:juanb]]

Tested on Ubuntu 6.06 and no update was offered:

https://aus2.mozilla.org/update/2/Firefox/2.0.0.16/2008070204/Linux_x86-gcc3/en-US/majortest/Linux%202.6.15-26-386%20(GTK%202.8.20)/update.xml?force=1

Tested on recent version of Mind and it got an update offer:

https://aus2.mozilla.org/update/2/Firefox/2.0.0.16/2008070204/Linux_x86-gcc3/en-US/majortest/Linux%202.6.24-16-generic%20(GTK%202.12.9)/update.xml?force=1

Comment 30

[juan becerra [:juanb]]

I meant to type Mint.

Comment 31

[Michael Morgan [:morgamic]]

-> VERIFIED ?