555729 - Add Lorentz versions to Socorro

Status: RESOLVED FIXED

(Socorro :: General, task)

Description

[Benjamin Smedberg]

Please add a new branch and new versions to Socorro:

branch: Lorentz
versions: 3.6.3plugin1, 3.6.3plugin2pre, 3.6.3plugin2, 3.6.3plugin3pre

Comment 1

[K Lars Lohn [:lars] [:klohn]]

For clarification:

Our "branches" table/view includes three columns: 'product', 'version', 'branch'. 

For us, 'branch' means the geko version. Are you saying there is a geko version called "Lorentz"?  Does it correspond with a more traditional X.Y.Z version number?  We don't appear to have an admin interface for adding geko versions... so we'd have to probably start an IT request for that.

We also need to do a quick audit on compatibility of the version name.  There are some places for which at 15 character version name outside of the traditional pattern X.Y[pre|b?] may not be parsed or stored correctly.

Comment 2

[Benjamin Smedberg]

The Lorentz branch is a branch of 1.9.2, but it's important to track them separately in crash-stats so that we can compare whether crashes appear only in lorentz builds (3.6.3plugin*) or also in regular 1.9.2 builds (3.6.3pre/3.6.3).

Comment 3

[K Lars Lohn [:lars] [:klohn]]

 what's your priority for this?  How soon do you need this working in production?

Comment 4

[Benjamin Smedberg]

I'd like to have the beta out to users by the end of the week and be able to correlate crash data early next week, if possible.

Comment 5

[Laura Thomson :laura]

More info from bsmedberg:

- It's actually its own branch (http://hg.mozilla.org/projects/firefox-lorentz) and should be tracked as such
- No formal rules for length/type of text in version strings (yet)
- "plugin" in the string does denote Lorentz branch
- We will likely see other strings where we see "plugin" soon (ie "jm")

Things to check at our end (via lars):
- Will this branch and versions fit in the schema?
- Will throttling cope?
- Bit of work needed on normalizeVersionToInt
- Will the longer version string work in the UI (QA needed here)
- Can we add this version from the admin interface or do we need to file an IT request?

Comment 6

[Laura Thomson :laura]

Re schema, they're all varying, product(30), version(16), branch(24), so it will all fit.  (the longest version up there is 15 chars)

Comment 7

[K Lars Lohn [:lars] [:klohn]]

We're going to have some problems with existing throttling rules.  Collector looks to specific positions within a version string for determining beta versions.  Direct indexing was done because it tested as much faster than a regular expression. Speed is a primary concern for Collector.
 
In this rule:
  ("Version", lambda x: x[-3:] == "pre" or x[3] in 'ab', 100.0), # queue 100% of crashes with version ending in "pre" or having 'a' or 'b'

the first half of the predicate will still work, but the second half will likely not work.  The new format doesn't show what a Beta release would look like.

Comment 8

[chris hofmann]

It seems like really all we need to track unique crashes from the Lorentz work is to have a unique branch/product version.

Why couldn't these just be identified as something continuing to branch of 3.6.x?  e.g. firefox 3.6.3.1b1, firefox 3.6.3.1b2,  firefox3.6.4.b3...  and for how ever long it takes to get out of beta and become the next 3.7.X release.  branches would correspond with numbers like 1.9.3.1b1, 1.9.3.1b2, 1.9.4b3...

seems like we should have a standard way of identifying these kinds of releases if we plan to do more of them in the next months.

Comment 9

[chris hofmann]

er, that last comment should have been 

 > how ever long it takes to get out of beta and become the next 3.6.X release

Comment 10

[Benjamin Smedberg]

Please don't re-open the "what version number is Lorentz" discussion, there are a whole bunch of factors, including AUS and conflicting nightly version/buildids. The current pluginN version numbers are the best consensus.

Comment 11

[Laura Thomson :laura]

We're going to take care of the 1.6 push Thursday, and then focus on this.  I anticipate getting this change out next week.  Just don't want to shove it into 1.6 since it touches a lot of code and may cause a good number of regressions.

Comment 12

[K Lars Lohn [:lars] [:klohn]]

We've got some loose ends to tie up before can produce a reliable solution. We NEED well defined rules because the throttling rules require us to tear these things apart to look at and make decisions based on the constituent parts.

  "versions: 3.6.3plugin1, 3.6.3plugin2pre, 3.6.3plugin2, 3.6.3plugin3pre"

in pigeon regular expression:

(major).(minor).(release-alphanumeric-string)["pre"]

looking at this, I see no examples of beta releases. 

(major).(minor).(release-alphanumeric-string)["b"(beta-enumerator)|"pre"]

that can only work if (release-alphanumeric-string) is always of the form (numeric)(alphabetic)(numeric): 

Is "3.7.2plumb3" the third beta release of "3.7.2plum" or the third release of "3.7.2plumb"?  

Is "3.7.2plumb3b1" an allowable version string?

=====

We also tear apart version numbers to concoct a relative ordering:

    3.7 < 3.7.1b1 < 3.7.1b2 < 3.7.1 < 3.7.2

where would 3.7.1plumb4 fit in that ordering?

Comment 13

[Benjamin Smedberg]

Although version strings can be arbitrary strings in theory, we don't actually have a 3.6.3plugin, just 3.6.plugin1, so 3.6.3plugin3 would be the third beta.

3.7 < 3.7.1b1 < 3.7.1plumb4 < 3.7.1 < 3.7.2

Because plumb comes alphabetically after b.

https://developer.mozilla.org/en/Toolkit_version_format covers the comparison rules.

Comment 14

[K Lars Lohn [:lars] [:klohn]]

just found out about https://developer.mozilla.org/en/Toolkit_version_format which moots several of the issues in Comment #12.  The new version strings are within the syntactic standard defined by that document.

a version consists of dot delimited instances of version parts: <number-a><string-b><number-c><string-d>   ;all fields optional

While that document defines the syntactic standard, it is mute on the semantic standard.  When Socorro throttling is supposed to pass through 100% of beta releases, what standard should be used to determine if something is beta?  The method used by Socorro right now is too simplistic to fit this form as it requires a 'b' in a specific position.   In comment #13, it is implied that anything with a non-empty "string-b" part of the rightmost "version part 4-tuple" is to be considered a "beta" version.  Is this correct?

Comment 15

[Benjamin Smedberg]

Yes, if there is something in string-b it is non-release alpha or beta.

Comment 16

[Laura Thomson :laura]

Once this is staged (bug 557709) we can test and see if we need to spin off a UI changes bug.

Comment 17

[Laura Thomson :laura]

(In reply to comment #16)
> Once this is staged (bug 557709) we can test and see if we need to spin off a
> UI changes bug.

Lars points out we don't need to wait for staging.

Comment 18

[Ryan Snyder [:ryansnyder] [:rsnyder] [:rysny]]

Committing 1 minor change in the UI.  3.6.3 was being overridden by 3.6.3plugin1 in the navigation bar.

As a reminder, the Lorentz versions will need to be added via the Branches Admin page in production.

==

Sending        webapp-php/application/libraries/release.php
Transmitting file data .
Committed revision 1930.

Comment 19

[K Lars Lohn [:lars] [:klohn]]

backend changes to handle lorentz version strings has been staged and passes tests

when pushing to production, the beta throttling rule will have to be changed.  This has been documented at http://code.google.com/p/socorro/wiki/SocorroUpgrade#Collector_Config_Changes  These instructions will repeated in the 1.6 production push request.

Closing this bug to show that it is ready for production.