If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Repos not controlled by Mozilla should not track master in b2g-manifest

RESOLVED WONTFIX

Status

Firefox OS
GonkIntegration
--
major
RESOLVED WONTFIX
3 years ago
a year ago

People

(Reporter: emorley, Unassigned)

Tracking

({sheriffing-P1})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
+++ This bug was initially created as a clone of Bug #910745 +++

Broken out from bug 910745 since it morphed along the way.

To avoid confusion, this bug is about:
* B2G trunk, not releases (the latter is fixed by bug 910745).
* Only third party repos not controlled by Mozilla (eg codeaurora repos). 

(In reply to Ed Morley [:edmorley UTC+0] from bug 910745 comment #3)
> For each manifest listed at https://github.com/mozilla-b2g/b2g-manifest (eg:
> https://github.com/mozilla-b2g/b2g-manifest/blob/master/emulator.xml), we
> should make sure that any repository whose upstream is not on a Github
> Mozilla owned account has an explicit "revision=<rev_or_tag>". This will
> prevent us from indiscriminately pulling master from repos not under our
> control - repos which the sheriffs do not have commit access to perform a
> backout.
> 
> This will mean that devs making changes to third party repositories will
> need to both land their change in that repository and also update the
> manifest - however I don't believe this is too onerous a requirement to
> ensure that B2G builds conform with:
> https://wiki.mozilla.org/Sheriffing/Job_Visibility_Policy#8.
> 29_Must_avoid_patterns_known_to_cause_non_deterministic_failures
> 
> Note: I'm explicitly not saying we should make these changes for repos owned
> by the Mozilla Github account, since sheriffs have access to those.

Whilst yes, sheriffs can pin repos after the fact (and this is the whole point of the b2g manifests bumper), we don't automatically pull in the tip of sqlite or other upstream libraries into gecko - we shouldn't be doing so for B2G - from a risk/correctness POV.

Also, from yet another incident in bug 1027618:

(In reply to Michael Vines [:m1] [:evilmachines] from bug 1027618 comment #11)
> But seems like you should always use SHA1s when pulling from CAF.  Using a
> branch ref will certainly break you from time to time as we push commits
> when our trees are green.   For this same reason we always use SHA1s when
> pulling from g.m.o

Comment 1

3 years ago
Who will be in charge of bumping these?
(Reporter)

Comment 2

3 years ago
Someone from B2G.
Hi Ed, In case of partner fixed some POVB bug, we need to sync the latest source from 3rd party repos. Is there any existing process to update the manifest where 3rd party repos were locked.
(Reporter)

Comment 4

3 years ago
(In reply to Kai-Zhen Li from comment #3)
> Hi Ed, In case of partner fixed some POVB bug, we need to sync the latest
> source from 3rd party repos. Is there any existing process to update the
> manifest where 3rd party repos were locked.

Not documented anywhere afaik - but it would just mean editing the revision for that repo in the desired job types at https://github.com/mozilla-b2g/b2g-manifest/
(Reporter)

Updated

a year ago
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.