I know what needs doing at specific points in the release:

• when we get an email about shipit, we create the release and add the graphid and mark the shipit checkbox
• when we get an email about channels/publish, we do the appropriate steps
• when we get errors we investigate

But I'm missing some overview:

• which releases to keep an eye on (we can look at the releases/ folder but this includes completed releases, which can be noisy when we have a lot of releases this week, and can include checking a lot of files)
  • evidently i didn't know about the release status command
• we now have a new bugzilla query we need to add to, as well as remember about the trello board

I think it would be awesome to add a dashboard template for the overview. Whenever we rebuild a specific release's md file, either on an update or sync or create, we could also rebuild the dashboard page, and it would be as up to date as the rest of the release files. Then whoever is on releaseduty can keep an eye on this single page rather than polling a number of files/webpages.

This could also have a troubleshooting tips section (or point to a troubleshooting how to page) - how to do trickier manual operations, or what types of things go wrong and what types of fixes generally work.

We could also update the template with reminders of things that we currently have in the trello board.

to make it easier to see who added them

https://github.com/taskcluster/taskcluster-cli

Similar to the definition of a Census, this tool systematically acuires and records information about the releases of a given product.

It would be great to generate a status page with links to all releases in flight. Something like https://github.com/mozilla/releasewarrior/blob/master/releases/status.md with a stable URL.

May I get access to this repo, please?

and remove the other commandline options.

Also, if we can simplify so we can just refer to published_release as publish etc, that'll make it easier to type. As long as the md templates specify what they mean, I think we're good.

I'm unclear on how these tasks relate to the (obsolete?) checklists in wikimo.

Some sort of guidance in both locations would be handy.

Today, I realized we've got a lot of outdated FUTURE releases. I cleaned them out in: 2ac8a5c
I just tested what happens when such a release is created: The file gets read, but not deleted. Sadly, this log line is lying:

removing FUTURE/ data file: /home/jlorenzo/git/mozilla/releasewarrior/releases/FUTURE/devedition-devedition-57.0b8.json

QA started update tests when Firefox 52.0b3 was done with "update verification tasks". Hence, they gave approval, before we sent the cdntest email.

That would great to have a command like:

$ release complete firefox beta 52.0b3
These tasks have not been done: 
   * emailed_cdntest

Are you sure you want to complete firefox beta 52.0b3? [y/N] y 

this should be a section for releaseduty to help troubleshoot and practice.

e.g.

nthomas> r+
17:45:06 build2 ?
17:45:56
<•rail> I'm going to create a clone of that task, but using different revision
17:46:21
<•nthomas> does that work with deps, or doesn't matter because this is a leaf?
17:47:31
<•rail> yeah, IIRC that task is on the edge of the graph, nothing depends on it
17:48:13
<•nthomas> ok, once you're done could you describe that in some detail so I can go fishing next time
17:48:29
<•rail> sure
17:50:18
<•nthomas> cheers
17:50:56
<•rail> created https://tools.taskcluster.net/groups/Co8iBgS1RnKVNOWMZm0TUg/tasks/Co8iBgS1RnKVNOWMZm0TUg/details by cloning the failed task (Actions -> Edit Task) and replaced all revision entries with the new one

We discovered yesterday that emails when Fennecs builds are ready, weren't sent anymore. (Per @rail , the postsigning task is dead. That's why no email is sent.)

Even with that email not being sent out, QA is able to figure out when builds are ready. (@MihaiTabara said they monitor archive.m.o).

This makes me wonder if we should stop sending manually a one-line email when it's QA's turn to take part of the show 😃

A short explanation and the steps to follow would be enough.

as per: sylvestre's email with subj "Moving sign off and automation notification from release-drivers ML"

I believe archive is what we want: https://help.github.com/articles/archiving-repositories/

I have moved over all relevant files. But I'd like to keep this read-only for a while while I port over open issues.

We leave ourselves notes in releases/FUTURE/PRODUCT-BRANCH-VERSION.json.
However, we skipped fx 53.0.1 and shipped a 53.0.2, so we skipped the future note.

We might want to remove the VERSION from the FUTURE json.

I admit to being way behind on the state of release duty, but in the old days, we sometimes "collided" on handling commands manually.

• Does releasewarrior ensure all tasks are idempotent? Or will that still be up to humans to coordinate?
• If 2 folks perform a task at the same time, does that produce a merge conflict in the data files? How do folks correct?

Fair to say the above are out of scope, but should give that some mention in the docs, imo.

Adding issies via command line is nice, but sometimes you want to pass some formatting characters without worrying about shell expansions. It would be great if we can add something like --issue --editor which would open your editor of choice ($EDITOR from env?), similar to git commit.

such as

•rail> https://aus5.mozilla.org/update/6/Firefox/55.0.3/20170824053622/WINNT_x86_64-msvc-x64/zh-TW/release/Windows_NT 10.0.0.0 (x64)/ISET:SSE3,MEM:16384/default/default/update.xml
3:52 PM https://aus5.mozilla.org/update/6/Firefox/55.0.3/20170824053622/WINNT_x86_64-msvc-x64/zh-TW/release/Windows_NT%2010.0.0.0%20(x64)/ISET:SSE3,MEM:16384/default/default/update.xml?force=1
3:54 PM you can use force=-1 to simulate background updates
3:54 PM looks like they are throttled
3:54 PM
Aki Sasaki nice
3:55 PM i'd still like an update url expander in the client :)
3:56 PM i should have thought of https://github.com/mozbhearsum/build-tools/blob/update-status/scripts/updates/update-status.py though

Releasewarrior could be a great place to store the progress of a merge day.

An interesting consequence of this (called out by @rail): the merge day documentation will be able to live in this repo!

I imagine that there wil be code commits to this repo around the same time that release data commits happen. Because of this, it may be possible for someone to pull with the intention of getting new data, but end up getting new code that breaks them.

It may be beneficial to move the release data files to their own repo to avoid this. This could also open up the possibility of separate data files by product, or perhaps even rendering a web UI with gh-pages.

Not sure if this is a bug or not, will resume to debugging later.
Case: When we add graph2 for RC builds / ESR , shouldn't it be displayed instead of graphid 1 for release status?

I was surprised to find that releasewarrior threw an exception when I wasn't in the releasewarrior directory. This might be related to #2 in that it's somewhat caused by the tool and the data it manages being so closely tied together.

One way to fix this could be to require a local config (perhaps one that could be generated automatically) that points at the data.

I followed https://github.com/mozilla/releasewarrior/blob/master/how-tos/setup-staging-release.md to try to get jamun setup for release promotion, but it didn't work. There's at least a couple of issues:

• Nightlies don't run on per-push builds after merging central -> jamun
• The Balrog configuration examples don't make it clear whether you need to point at Balrog admin, or the public interface

Reading over https://github.com/mozilla/releasewarrior/blob/master/how-tos/relpro.md#when-2, I was surprised to see that QE is able to authorize shipping non-Betas. Is that actually true? I thought they could only authorize shipping non-beta1 betas.

Hm, rather than an option per checkmark (e.g. --shipit --cdntest etc.) we should probably have a single option that takes an enum arg, e.g. --checkbox {shipit,cdntest,publish,...}.

2 sections: completed and in-progress
This would help in talking about in-progress chemspills and major releases.

If releaseduty is going to address nightlies hen we should update release warrior with relevant bugs so people across timezones have status

i.e. this was opened today
Suspend Nightly updates on Windows due to bug 1403951
https://bugzilla.mozilla.org/show_bug.cgi?id=1404016

someone in the next timezone should be aware of status of they have to revert this change

There's a sort of duplication of effort:

• On one hand, you have to start a release by (manually) submitting it on ship-it. This notifies release-drivers via email
• On the other hand, on releasewarrior, you have to:
  • release create firefox beta 52.0b2 (for instance)
  • release update --shipit firefox beta 52.0b2

It'd be good if ship took care of the last 2 steps

Probably there is nothing interesting there.

I found it somewhat jarring that there are multiple date formats in various places:

• sometimes year is 4 digits, sometime only 2
• sometimes there are leading zeros ('0'), sometimes not

Personally, I'm a strong believer in ISO-8601 dates. The confusion of 'what century is it' is not something I wish for the next generations.

The patches s/b easy -- the challenge will be picking a 'flag day' to convert the existing data. Or maybe git can handle rename-with-content-change as well. We'd find out. :)

This may be related to issue #9.