Release automation should use l10n shipping dashboard to get signed off l10n changesets

RESOLVED DUPLICATE of bug 415895

Status

Release Engineering
General
P5
normal
RESOLVED DUPLICATE of bug 415895
8 years ago
4 years ago

People

(Reporter: rail, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [automation])

(Reporter)

Description

8 years ago
To avoid double work of the L10N team we should use L10N shipping data (somewhere at https://l10n-stage-sj.mozilla.org/shipping/) to recreate l10n-changesets files or even use the data without touching l10n-changesets files.
+1

AIUI, l10n-changesets is just used for tagging?  Everything after that uses the release tags to work with?

If that's the case, our tagging step could fetch the L10n shipping data from the dashboard, and use that to tag the l10n repositories - bypassing the need for l10n-changesets in our repo completely.
Yeah, l10n-changesets is just used for tagging.

I don't think pulling changesets at tagging time is the right way to go here. It's important for archeology purposes to known exactly what changesets the automation was fed -- I'm not sure how we can guarantee that if we're pulling at run time.

I'd be on board with some sort of automated system that met the following requirements:
* revisions used for each locale are dumped somewhere permanent by the automation -- a checked in file, maybe something in the candidates dir (though we remove those, eventually). It's specifically important that the automation is responsible for this so we know *exactly* what it got from wherever it polls.
* l10n team remains responsible for sign-off
(In reply to comment #2)
> Yeah, l10n-changesets is just used for tagging.
> 
> I don't think pulling changesets at tagging time is the right way to go here.
> It's important for archeology purposes to known exactly what changesets the
> automation was fed -- I'm not sure how we can guarantee that if we're pulling
> at run time.

I don't see the difference between somebody taking the output of the dashboard and checking in that file and then using that to tag, and the automation getting the same contents from the dashboard and using that to tag.

If we want to check the resulting list of changesets in somewhere before or after tagging starts, great, but there's no reason the list of changesets has to be baked into the buildbot process as part of a reconfig.
(In reply to comment #3)
> (In reply to comment #2)
> > Yeah, l10n-changesets is just used for tagging.
> > 
> > I don't think pulling changesets at tagging time is the right way to go here.
> > It's important for archeology purposes to known exactly what changesets the
> > automation was fed -- I'm not sure how we can guarantee that if we're pulling
> > at run time.
> 
> I don't see the difference between somebody taking the output of the dashboard
> and checking in that file and then using that to tag, and the automation
> getting the same contents from the dashboard and using that to tag.
> 
> If we want to check the resulting list of changesets in somewhere before or
> after tagging starts, great, but there's no reason the list of changesets has
> to be baked into the buildbot process as part of a reconfig.

I don't disagree about reconfigs -- there no reason why it needs to be done at config time (yes, that sortof goes back on what I just said).

I'm on board with this at the abstract level, but there's a lot of potential problems to address. I mentioned some in my previous comment, and here's some more questions I have:
* Do we want the automation to depend on another external system?
* What happens if it's down, will we be able to override easily or are we blocked until it's back up?

It also seems like we'd need a system on the web end for saying "give me the changesets for firefox x.y.z" rather than just "what is currently green"

Comment 5

8 years ago
https://l10n-stage-sj.mozilla.org/shipping/l10n-changesets?ms=fx3.6.2 works for all changesets. The db might be wrong for one or two historically, though. I'm not sure how to synchronize about 3.6.4 with build1 being on a different list than build2. Right now, their codes are fx3.6.4build1 and fx3.6.4build2.

I expect the l10n team to keep going through the sign-offs on a regular basis and thus when it's time to ship, the list of pending sign-offs should usually be zero, or at least small. There's the chance to poke someone from the l10n team, or just leave the sign-offs pending.

If the shipping dashboard is down, we're out of luck. With a locally landed copy of the last release, we could at least make a release-drivers decision on whether to block on the dashboard coming back up, so that's probably a good idea.

Updated

8 years ago
Priority: -- → P5
Whiteboard: [automation]

Updated

7 years ago
Blocks: 478420
Looks like this is a dupe of 415895.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 415895
(Assignee)

Updated

4 years ago
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.