improve survivability/resumability of libwebrtc fast-forward process
Categories
(Core :: WebRTC, task, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox114 | --- | fixed |
People
(Reporter: mjf, Assigned: mjf)
References
Details
Attachments
(9 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
One recurring issue with the fast-forward process has been that it is fairly easy to shoot yourself in the foot in a way that can disrupt one or both of the repositories (mercurial for firefox and git for moz-libwebrtc) to the point that it is easier (necessary) to start over. Solving this issue will also likely have the benefit of making it easier to hand-off work in progress to another person if needed.
My initial thought on this is to use a hybrid of the other 3rd party vendoring processes where a mercurial-based patch stack is contained in tree. We would continue to use that stack of patches in github for the rebase functionality, but after vendoring each upstream commit (meaning rebase conflicts have been successfully resolved), the stack of patches is updated in mercurial. This change would mean that it would be possible to recreate the patch stack for any vendored commit, thus allowing simpler rollbacks to previous commits. If the work in progress is pushed to elm, it would also allow easy access for other team members to take over or help with working on a particular upstream commit.
The additional functionality probably implies converting some of the bash scripts to python.
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 1•2 years ago
|
||
Depends on D175686
Assignee | ||
Comment 2•2 years ago
|
||
Depends on D175687
Assignee | ||
Comment 3•2 years ago
|
||
- use fetch_github_repo.py to get a fresh repro, that is ready for
restoring the patch-stack. - use moz-patch-stack directory rather than previous github branch to
restore previous patch-stack. - since we can now easily restore a mid-fast-forward patch-stack, we
can default to storing moz-libwebrtc under STATE_DIR
Depends on D175688
Assignee | ||
Comment 4•2 years ago
|
||
Depends on D175689
Assignee | ||
Comment 5•2 years ago
|
||
This is possible now that we default to storing the moz-libwebrtc
github repo in the STATE_DIR.
Depends on D175690
Assignee | ||
Comment 6•2 years ago
|
||
Depends on D175691
Assignee | ||
Comment 7•2 years ago
|
||
Depends on D175692
Assignee | ||
Comment 8•2 years ago
|
||
There will be one more patch, the patch-stack based on v110, which will be created after the github repo is updated with Byron's fast-forward stack from moz-mods-chr110-for-rel114.
Assignee | ||
Comment 9•2 years ago
|
||
Depends on D175693
Assignee | ||
Comment 10•2 years ago
|
||
Depends on D175824
Comment 11•2 years ago
|
||
Comment 12•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/828a13519c80
https://hg.mozilla.org/mozilla-central/rev/389c656dad14
https://hg.mozilla.org/mozilla-central/rev/00832d67759d
https://hg.mozilla.org/mozilla-central/rev/0f788f556e6c
https://hg.mozilla.org/mozilla-central/rev/58a9e5ede9bf
https://hg.mozilla.org/mozilla-central/rev/1df0d3439d2d
https://hg.mozilla.org/mozilla-central/rev/e00e7b4066f0
https://hg.mozilla.org/mozilla-central/rev/ad73e938ec23
https://hg.mozilla.org/mozilla-central/rev/aafbdd73e243
Description
•