Closed Bug 418129 Opened 16 years ago Closed 16 years ago

Need branch-based OS ignore list

Categories

(AUS Graveyard :: General, defect)

defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: reed, Assigned: morgamic)

References

Details

(Whiteboard: [MU+][server side])

Attachments

(1 file, 2 obsolete files)

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.
Flags: blocking-firefox3?
Make sense, yes, not sure that it blocks the release of the product.
No longer blocks: 394046
Flags: blocking-firefox3? → blocking-firefox3-
Target Milestone: 4.x (triaged) → 3.0
Assignee: morgamic → nobody
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 ?
Severity: major → critical
OS: Linux → All
Hardware: PC → All
this blocks major update fx2.x -> fx3.x work.  can we get this into the next fix?
Flags: wanted1.9.0.x?
It's a server side change, dunno how you want to track that with flags.
Whiteboard: [MU+]
Blocks: 442105
(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.
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?
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.2?
Whiteboard: [MU+] → [MU+][server side]
Assignee: nobody → morgamic
Status: NEW → ASSIGNED
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.
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.
Doesn't block 1.9.0.2 but does block MU (since it's server side it doesn't need to block the release).
Flags: blocking1.9.0.2? → blocking1.9.0.2-
Still writing tests, will finish today.  How much testing time do you guys need before we deploy it?
(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.
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?
(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
Windows NT 4.0 (I don't have the values we care about) also matters.
So safe to say anything Windows 4.x can be blocked for 2->3 major update?
- 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.
Attachment #334604 - Flags: review?(clouserw)
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.
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.
Attached patch v2, with adjust GTK stuff (obsolete) — Splinter Review
I want to avoid using regexes if possible, so I'll just list the four extras.
Attachment #334604 - Attachment is obsolete: true
Attachment #334607 - Flags: review?(reed)
Attachment #334604 - Flags: review?(clouserw)
Add "GTK 2.9.", too.
:X
Attachment #334607 - Attachment is obsolete: true
Attachment #334608 - Flags: review?(clouserw)
Attachment #334607 - Flags: review?(reed)
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.
Attachment #334608 - Flags: review?(clouserw) → review+
This is checked in and tagged. Production push bug is here: bug 451484

QA signed off on staging this evening (juanb, tomcat).
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
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! :)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Checked in the right GTK values.  Thanks for catching this.
Status: REOPENED → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → FIXED
I meant to type Mint.
-> VERIFIED ?
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.