mozilla-aurora unexpectedly in releases/gecko.git, and not fast forwardable

RESOLVED FIXED

Status

Release Engineering
General
RESOLVED FIXED
5 years ago
a year ago

People

(Reporter: hwine, Assigned: hwine)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [re-vcs-sync][re-b2g])

(Assignee)

Description

5 years ago
IRC report from mvines of not-able-to-fastforward error on git.m.o:releases/gecko.git "aurora" branch (expected due to recent uplift m-c -> m-a)

aurora branch (hg.m.o:releases/mozilla-aurora) isn't expected to be in releases/gecko.git

Investigate & remediate
(Assignee)

Comment 1

5 years ago
At time of report, advised mvines to not mirror either the 'beta' (from mozilla-beta) or 'aurora' (from mozilla-aurora) as immediate way to unblock.

16:05 < m1> hwine: hey, anything funny happen on the aurora branch over the
            last two days?
16:06 < hwine> m1: yes - our normal pre-release merge activity....
16:06 < hwine> ... but I didn't think you "saw" aurora anywhere
16:07 < m1> hwine: ah, so it's normal to expect that the g.m.o sha1s for aurora
            to be completely non-linear?
16:08 < hwine> m1: where are you seeing them on git.m.o?  but yes normal for
               activity surges
16:09 < m1> hwine: we're falling down again cause of a non-fastforward changes
            to the mozilla/aurora branch of
            http://git.mozilla.org/?p=releases/gecko.git
16:09 < m1> hwine: we'll just stop mirroring that branch for now probably
16:09 < m1> but i just wanted to confirm that this is "expected"
16:10 < hwine> m1: yes - the lack of non-fastforward ability is NOT expected,
               but it may take a while to sort out
16:11 < hwine> m1: not mirroring mozilla-aurora or mozilla-beta is good interim
               idea
16:11 < hwine> m1: I'll open a bug and cc you one it
16:11 < m1> ok, we'll do that for now
(Assignee)

Comment 2

5 years ago
Found and stopped the source of aurora branch updates to git.m.o:releases/gecko.git. 

They are perfectly valid and correct conversions, so no concerns around repository corruption or sha1 validity.

This was an early version of gecko.git accidentally left running (and now shut off) that published to git.m.o in the early days of the project. When that version was relocated to another machine (for more disk space), the older version was not shut down properly. (As a side note, this does demonstrate the repeatability of the conversion process, as this instance was also converting and publishing mozilla-central to the master branch of gecko.git - something also done in the main production conversion.)

The mozilla-aurora branch was only supposed to be mirrored to gecko.git for a very short period, while the gecko18 code base lived on that branch. We know that our firefox train uplift process will not always produce a fast-forwardable changeset.

Given this information, dropping severity to normal
Severity: major → normal
(Assignee)

Comment 3

5 years ago
(In reply to Hal Wine [:hwine] from comment #1)
> 
> 16:10 < hwine> m1: yes - the lack of non-fastforward ability is NOT expected,
>                but it may take a while to sort out

correction - we don't expect a pure mozilla-aurora conversion to always be fast forwardable. We do expect to only make fast forwardable changesets available in releases/gecko.git
(Assignee)

Comment 4

5 years ago
Root cause was prior conversion instance not properly shut down, during time gecko-18 was on the mozilla-aurora train.

That instance shut down, and appropriate actions taken with downstream repos.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
Component: Tools → General
Product: Release Engineering → Release Engineering
You need to log in before you can comment on or make changes to this bug.