Switch to sitespeed.io browsertime
Categories
(Testing :: Raptor, enhancement, P2)
Tracking
(Not tracked)
People
(Reporter: tarek, Assigned: tarek)
References
(Blocks 1 open bug)
Details
Attachments
(1 obsolete file)
We want to stop using our fork and rely on upstream
Assignee | ||
Comment 1•4 years ago
|
||
Assignee | ||
Comment 2•4 years ago
|
||
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•4 years ago
|
||
(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.
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 5•4 years ago
|
||
(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".
Updated•4 years ago
|
Description
•