(Follow-ups to dev.tree-management please)
Hi all :-)
The vast majority of mozilla-central landings are now via curated merges
from integration/team repositories. This dramatically increases the
chance that the tip of mozilla-central is in a known-good state, meaning
that:
* Integration/project repos pulling from mozilla-central are less likely
to receive breakage from elsewhere.
* A bad landing + tree closure on one integration/team repo doesn't
impact the ability of other repositories to merge into mozilla-central.
* Developers have the choice of a safer repository to use as their qbase
for local development / try pushes.
* Nightly builds are less prone to being broken & requiring a respin [1].
Non-critical mozilla-central landings are already discouraged and as
such are rare. However, the sheriffs [2] would like to formalise this,
by adjusting the mozilla-central tree rules [3] to state that direct
pushes must be for one of the following reasons:
1) Merging from an integration/team/project repository (there is no
restriction on who may make these merges).
2) Automated blocklist / HSTS preload list updates [4].
3) For the resolution (ie: backout or follow-up fix) of critical
regressions (eg: top-crashers or other major functional regression) that
will result in a Nightly respin or must make the imminent scheduled
Nightly at all costs.
4) Anything else for which common sense (or asking in #developers) says
is an appropriate reason for a direct landing on mozilla-central.
Clearly #4 is very fuzzy - but I'm hopeful self-policing has a good
chance of success and so would like to try that first. Note #4 would not
include the landing of new features directly onto mozilla-central if
they have missed the last integration repository merge on the day of
uplift - the correct course of action would be to request
aurora-approval and uplift instead, due to the amount of merge-day
breakage this has caused in the past.
If there are any other cases that should be explicitly mentioned above
instead of relying on #4, please let me know.
A proportion of the current mozilla-central non-critical commits are
made by people inadvertently pushing to the wrong repository. To prevent
these, once the tree rules are adjusted on the wiki the sheriffs
envisage the next step will be switching mozilla-central to a non-open
tree state (name TBD) using the existing tree closure hook. Backouts,
merges & automated bot updates will not need any additional annotation -
others will simply use a (yet to be chosen) commit message string to
signify awareness & adherence to the new tree policy.
We welcome your feedback :-)
Best wishes,
Ed
[1] We've recently disabled the last good revision functionality on
mozilla-central, since it was both not functioning as expected and also
frequently caused delays in Nightly generation when non-tier 1 jobs are
failed or infra issues caused a single build to fail. The net change is
positive, however it increases the need to ensure mozilla-central is in
a known good state.
[2] https://wiki.mozilla.org/Sheriffing
[3] https://wiki.mozilla.org/Tree_Rules
[4] eg: https://hg.mozilla.org/mozilla-central/rev/c401296f71ae and
https://hg.mozilla.org/mozilla-central/rev/beea7a7f3fc3 - though I think
we may wish to move these to an integration repository in the future,
since they have occasionally caused breakage in the past. However that
will require discussion and automation changes, so I believe we should
maintain the status quo initially.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
