On 17/10/2015 05:18, John Morrison wrote: > [..snip..] > > However the root problem in this area is that fxa-content-server-l10n > doesn't > appear to be smoothly forward-compatible. Why shouldn't HEAD of l10n always > contain reasonable translations for strings in our code?
Yep. Independently of all the branch/tag/whatever discussion, we need to fix this fragility in our l10n process. There was some good discussion last week in IRC and it sounds like a path forward is fairly clear, so I surfaced it as a bug and put it in "next": https://github.com/mozilla/fxa-content-server-l10n/issues/80 (Apologies if this was already captured better elsewhere, but I didn't recall seeing it go past in my github issuemail). Cheers, Ryan > On 10/16/15 02:23, Shane Tomlinson wrote: >> 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." >> >> 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. >> >> 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. >> >> After looking across a sample of repos, tags appear to be the most >> popular way of marking a particular train's sha. >> >> 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. >> >> 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. >> >> Thoughts? >> >> Shane >> >> ----------------------------- >> >> [1] - https://github.com/mozilla/fxa-content-experiments/pull/25 >> >> >> _______________________________________________ >> Dev-fxacct mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/dev-fxacct > > > > _______________________________________________ > Dev-fxacct mailing list > [email protected] > https://mail.mozilla.org/listinfo/dev-fxacct > _______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
