550023 - [tracking bug] releng blockers for an automated Fennec 1.0.1

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Aki Sasaki (not active)]

We definitely could spin a Fennec 1.0.1 under duress, where "spin a 1.0.1" involves many manual steps and human error.  We'd very much like to avoid that unless there's a zero-day that forces our hand.

I've been describing the blockers in an overview and kept a running list in my head; this bug should track the work in a more specific and shareable way.

Some of these may rely on back-porting some mobile-browser changes to the relbranch (if 1.0.1 is spun off the relbranch).

Comment 1

[Aki Sasaki (not active)]

The following are definitely nice-to-haves, not blockers.  Noting these in a comment rather than the bug dependency chain.

Bug 537426 - clobbering mobile release build directories
Bug 543109 - moving candidate build to releases/
Bug 542413 - version bumping.  Tempted to put this in the blocker list, but we did get through 1.0 without it.
Bug 542579 - separate the multi and en-US builds.  This is blocked on separating the two builds in nightlies, but if that happens before 1.0.1 this bug will become a blocker.

Comment 2

[Aki Sasaki (not active)]

(In reply to comment #1)
> This is blocked on
> separating the two builds in nightlies, but if that happens before 1.0.1 this
> bug will become a blocker.

This is bug 525327.

Bug 537296 - Fennec desktop release builders would be another nice to have.

Comment 3

[Aki Sasaki (not active)]

Adding some blockers that are already resolved, for:

- tracking
- context
- knowing what patches may need to land on relbranch

Comment 4

[Aki Sasaki (not active)]

Per Stuart in IRC, we need to ship Xulrunner with 1.0.1.

This means that just writing the automation to work with mobile-browser trunk doesn't work; I need to have it work on the relbranch, which is significantly further behind.  And I also have to have it work with trunk for 1.1.