800277 - Update generation has problems when latest-1 --> latest partial isn't generated

Status: RESOLVED WONTFIX

(Release Engineering :: Release Automation: Other, defect, P3)

Description

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

We did this for Thunderbird 16.0.1, asking for partials from 15.0.1 but not 16.0, and I'm expecting Firefox to fail out in the same way (partials from 13.0.1, 14.0.1, 15.0.1 but not 16.0). 

The patcher config bump looks sane-ish,
  http://hg.mozilla.org/build/tools/rev/4ce5fbf76272
It leaves from as 15.0.1. The update verify config fails with

/tools/python-2.6.5/bin/python tools/scripts/updates/create-update-verify-configs.py -c tools/release/patcher-configs/mozRelease-thunderbird-branch-patcher2.cfg --platform win32 --output tools/release/updates/mozRelease-thunderbird-win32.cfg --release-config-file mozilla/release-thunderbird-comm-release.py -b http://hg.mozilla.org/build/buildbot-configs --channel betatest -t THUNDERBIRD_16_0_1_RELEASE

pulling from http://hg.mozilla.org/build/buildbot-configs
searching for changes
no changes found
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
Traceback (most recent call last):
  File "tools/scripts/updates/create-update-verify-configs.py", line 122, in <module>
    locales.remove(locale)
ValueError: list.remove(x): x not in list
This turns the job red but doesn't actually halt it, so we continue to commit the config, generating snippets, uploading them etc.

And we don't have any 16.0 -> 16.0.1 complete updates generated.

Comment 1

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

In lib/python/release/updates/patcher.py's getFromVersions you can cast to a tuple(set( <original lookup> )) to avoid duplication and the ValueError, but that doesn't help with testing the latest-1 release.

Comment 2

[Rail Aliiev [:rail]]

getFromVersions() tries to return a tuple of versions by adding all past versions to "from" version http://hg.mozilla.org/build/tools/file/37ed4b2108ba/lib/python/release/updates/patcher.py#l49). In our case 15.0.1 is a "from" version (http://hg.mozilla.org/build/tools/rev/4ce5fbf76272#l1.20) and at the same time it's in 'past-update' section (http://hg.mozilla.org/build/tools/rev/4ce5fbf76272#l1.56)

The script iterates over all versions http://hg.mozilla.org/build/tools/file/37ed4b2108ba/scripts/updates/create-update-verify-configs.py#l115 and tries to remove ja-JP-mac form win32 twice and fails.

As a possible solution we can return a set:
-        return tuple([self['current-update']['from']] + [v[0] for v in self['past-update']])
+        return tuple(set([self['current-update']['from']] + [v[0] for v in
+                                                             self['past-update']]))

Comment 3

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

I wonder if we should WONTFIX this and insist we always have a partial from the last version. In the case of 16.0/16.0.1 we had on the order of 5 million ADI on 16.0 around the time 16.0.1 shipped, and of course there's a bunch of lag in those numbers. IIRC it's an implicit assumption in patcher anyway.

Comment 4

[[e-mail] (:bhearsum)]

If this is a simple fix I feel like we should take it -- it's certainly a valid bug IMO. If it's non-trivial to solve, and we can get a promise that we'll always partials from the "from" version, WONTFIX sounds good to me.

Comment 5

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

(In reply to Nick Thomas [:nthomas] from comment #0)
> And we don't have any 16.0 -> 16.0.1 complete updates generated.

I should have said snippets there, but it's this bit I'm flagging the scope of. We've never used a patcher config like
    from  15.0.1
    to    16.0.1
 past-update 15.0.1 16.0 ...
 past-update 16.0 16.0.1 ...
before, where we expect completes updates for 16.0 to 16.0.1. You probably have a better idea of how hard it is to do this in create-snippets.py.

Going back to my earlier argument, unless we yank a .0 almost immediately we will always enough users to justify generating partials for a .0 to .0.1 update. It might be more applicable to betas if there was a nasty startup crash, but even then the feedback loop might be too slow.

Comment 6

[[e-mail] (:bhearsum)]

(In reply to Nick Thomas [:nthomas] from comment #5)
> (In reply to Nick Thomas [:nthomas] from comment #0)
> > And we don't have any 16.0 -> 16.0.1 complete updates generated.
> 
> I should have said snippets there, but it's this bit I'm flagging the scope
> of. We've never used a patcher config like
>     from  15.0.1
>     to    16.0.1
>  past-update 15.0.1 16.0 ...
>  past-update 16.0 16.0.1 ...

Ah, I see. In my head I'm seeing the patcher config unchanged from the current one, that is:
from 16.0
to   16.0.1
<partials>
 <15.0.1>
 </15.0.1>
 ...
</partials>
past-update 15.0.1 16.0

Essentially, "from" isn't relevant when talking about which releases get partials in my head. (In fact, now that we don't support multiple channels in the same patcher config we could even get rid of "from" and "past-update" and replace them with a list of versions that should get completes, perhaps a "completes" line.)

Comment 7

[[e-mail] (:bhearsum)]

(In reply to Ben Hearsum [:bhearsum] from comment #6)
> (In reply to Nick Thomas [:nthomas] from comment #5)
> > (In reply to Nick Thomas [:nthomas] from comment #0)
> > > And we don't have any 16.0 -> 16.0.1 complete updates generated.
> > 
> > I should have said snippets there, but it's this bit I'm flagging the scope
> > of. We've never used a patcher config like
> >     from  15.0.1
> >     to    16.0.1
> >  past-update 15.0.1 16.0 ...
> >  past-update 16.0 16.0.1 ...
> 
> Ah, I see. In my head I'm seeing the patcher config unchanged from the
> current one, that is:
> from 16.0
> to   16.0.1
> <partials>
>  <15.0.1>
>  </15.0.1>
>  ...
> </partials>
> past-update 15.0.1 16.0
> 
> Essentially, "from" isn't relevant when talking about which releases get
> partials in my head. (In fact, now that we don't support multiple channels
> in the same patcher config we could even get rid of "from" and "past-update"
> and replace them with a list of versions that should get completes, perhaps
> a "completes" line.)

So, if we wanted to support not doing partials for the immediately previous release, we'd have to add back in some notion of "oldVersion", because right now "from" is calculated by finding the highest version listed in partialUpdates.

Until this bug is fixed, we cannot do a release without including the immediately previous release in the partials list. For 16.0.1, this means that we should've done a partial for 16.0.

Comment 8

[[e-mail] (:bhearsum)]

Fixed by funsize?

Comment 9

[Rail Aliiev [:rail]]

Will be fixed by release promotion and funsize.