Commit on project branch 'Elm' closed a backed out revision destined for central
Categories
(Conduit :: Phabricator, defect, P2)
Tracking
(Not tracked)
People
(Reporter: mgaudet, Assigned: zeid)
References
Details
I'm a reviewer on a patch stack that was backed out.
The patches were backed out, which re-opened the revisions as expected.
Then, the original landing ended up in the Elm repo, which caused the patches to be closed again -- it appears that the revert did not make it to Elm. So now the stack is closed, despite being reverted and needing to be re-landed on central.
I don't think commits in Elm (or other project branches) should be affecting revision status.
| Assignee | ||
Updated•4 years ago
|
Comment 1•4 years ago
|
||
I just noticed what looks like basically the opposite of comment 0, affecting a patch stack of mine.
This stack was pushed to autoland, then backed out; then it was updated and re-landed, and merged successfully to central. So the phab revisions were closed.
Then, around 10 hours later, it appears that the original (buggy) landing and its backout were merged to Elm, and because the last thing merged there was the backout, the revisions have been reopened. So now phabricator shows them as "ready to land", while in fact they're already on central.
It's unclear to me whether manually doing "close revision" in phab (for each patch in the stack) at this point will put things into the correct state, or if that would just add to the confusion...? I don't think whatever happened on elm should have touched the state of the phab revisions there...
| Assignee | ||
Comment 2•4 years ago
|
||
This is happening because Elm repo's .arcconfig is still pointing to MOZILLACENTRAL (as the call sign). This needs to be changed to ELM.
Happy to create a revision to update that -- I'm currently cloning the repo, so unless someone beats me to it I will submit a patch.
| Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Description
•