1608863 - Switch to sitespeed.io browsertime

Status: RESOLVED DUPLICATE of bug 1607851

(Testing :: Raptor, enhancement, P2)

Description

[Tarek Ziadé (:tarek)]

We want to stop using our fork and rely on upstream

Comment 1

[Tarek Ziadé (:tarek)]

Attachment: Bug 1608863 - switch to sitespeed.io browsertime

Comment 2

[Tarek Ziadé (:tarek)]

Do we want to create a branch on sitespeed.io and use it as a 'stable' branch since master has a lot of activity
even if we pin at a specific version, that could give us the ability to cherry pick fixes if we need to

Comment 3

[Robert Wood [:rwood]]

(In reply to Tarek Ziadé (:tarek) from comment #2)

Do we want to create a branch on sitespeed.io and use it as a 'stable' branch since master has a lot of activity
even if we pin at a specific version, that could give us the ability to cherry pick fixes if we need to

IMO I think having our own 'stable' branch is a good idea so that we have a bit more flexibility.

Comment 5

[Nick Alexander :nalexander [he/him]]

(In reply to Tarek Ziadé (:tarek) from comment #2)

Do we want to create a branch on sitespeed.io and use it as a 'stable' branch since master has a lot of activity
even if we pin at a specific version, that could give us the ability to cherry pick fixes if we need to

It's technically challenging to do that right now because pointing tools/browsertime/package.lock at a git repo isn't (at least, wasn't) supported with the version of Node/npm/whatever in the toolchain builders. I'm sure we could address that, if we wanted to.

I strongly prefer explicitly bumping the hash in tree; that's the best way to ensure reproducible builds (and to just know where things stand). So I'm -1 on a Mozilla-specific branch that can increment "out from under us".