<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><tt>So,<br>
<br>
fxa-content-server<br>
fxa-auth-server<br>
fxa-auth-db-mysql<br>
fxa-customs-server<br>
fxa-oauth-server<br>
fxa-profile-server<br>
<br>
**use tags**, set by a grunt task with `grunt version`.<br>
<br>
The other repos use, ... oh wait, there are no other top-level
repos that we<br>
ship to production.<br>
<br>
content, auth, auth-db, customs additionally cut a branch at the
same time,<br>
which isn't necessary most releases, but simply follows a
practice we have<br>
used from the beginning.<br>
<br>
fxa-auth-mailer is an npm+git-url dependency pulled into
fxa-auth-server. It<br>
targets #master, but shrinkwrap controls which actual sha is
used. This also<br>
controls the git sha of fxa-content-server-l10n.<br>
<br>
The production version of fxa-content-experiments, by design,
and by<br>
agreement, is controlled by this file[1] in fxa-content-server.
The<br>
contents of that file determine what version is pulled at
runtime. Commits<br>
to that file are controlled by the standard PR and review
process for<br>
fxa-content-server. I emphasize that this process was chosen to
give the<br>
owners of fxa-content-server flexibility and control over which
experiments<br>
would go live, while ensuring that random commits on master or
other<br>
branches did not go immediately to production.<br>
<br>
I think "unexpected sha was initially slated to go to
production" is a<br>
mischaracterization. Whatever we choose is what will go to
production and no<br>
choice had been made yet. You misinterpreted my response.<br>
<br>
However the root problem in this area is that
fxa-content-server-l10n doesn't<br>
appear to be smoothly forward-compatible. Why shouldn't HEAD of
l10n always<br>
contain reasonable translations for strings in our code?<br>
<br>
John<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="https://github.com/mozilla/fxa-content-server/blob/master/server/config/production-experiments.json">https://github.com/mozilla/fxa-content-server/blob/master/server/config/production-experiments.json</a><br>
<br>
</tt><br>
On 10/16/15 02:23, Shane Tomlinson wrote:<br>
</div>
<blockquote
cite="mid:CAO07_nDvCqTvqYy925mxTN+KNK_LMJ2ROXeVnNK0e4mEnPZ6RA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>Last week we had a mixup with the fxa-content-server-l10n
repo when cutting train 47. The fxa-content-server-l10n repo
has no formal tagging procedure and an unexpected sha was
initially slated to go to production. While investigating
whether the unexpected sha could be used in production, I
saw the fxa-auth-mailer uses neither tags nor branches to
indicate which sha is used for a particular train. I had to
ask jrgm which auth-mailer sha was going to be used in
production. Today Ryan Kelly questioned whether [1] could be
merged into the fxa-content-server-experiments repo or
whether he should wait until Monday, stating "I don't want
to merge it last thing on a Friday evening and have the
change go straight to production - let's deal with it on
Monday when prepping the cut for train-48."<br>
<br>
</div>
Some repos, like the experiments repo, use branches. Some
repos use tags. Some repos tag/branch for every train. Other
repos are only branched/tagged when the code updates, making
me ask "is <train-XXX>, that is 3 trains behind, the
code that is really in production, or has somebody forgotten
to branch/tag?". Point release tags/branches are only done on
the repo that causes the point release.<br>
<br>
</div>
<div>I find this lack of a unified process extremely confusing,
and more than likely a contributing factor to week's snafu and
Ryan's confusion. It should be easy for us to get to a better
place with a unified process that is used across all repos.<br>
<br>
</div>
<div>After looking across a sample of repos, tags appear to be
the most popular way of marking a particular train's sha.<br>
</div>
<div><br>
</div>
<div>My strawman proposal - *all* backend/server repos are
tagged *every* major train. Repos do not need to be tagged at
the same time, but they must be tagged by time the train goes
to production, even if the code has not changed. Client side
libraries that are included via bower would be exempt since
the repos in which they are included specify the exact
sha/version. <br>
<br>
</div>
<div>The process could largely be automated by individual repo
"owners", and at a minimum, verification could be handled by a
script with a list of repos to check.<br>
<br>
</div>
<div>Thoughts?<br>
</div>
<div><br>
</div>
Shane<br>
<br>
-----------------------------<br>
<div>
<div><br>
[1] - <a moz-do-not-send="true"
href="https://github.com/mozilla/fxa-content-experiments/pull/25">https://github.com/mozilla/fxa-content-experiments/pull/25</a><br>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Dev-fxacct mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Dev-fxacct@mozilla.org">Dev-fxacct@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/dev-fxacct">https://mail.mozilla.org/listinfo/dev-fxacct</a>
</pre>
</blockquote>
<br>
</body>
</html>