Ubuntu Server Triage

Output Ubuntu Server Launchpad bugs that for triage. The script is used by members of the Ubuntu Server team to determine what Launchpad bugs to review on a particular day or range of days. Giving us programmatic access to a set of bugs to look at. The older method was to look at this page and manually find all the bugs corresponding to a particular bug.

The easiest way to obtain the script and keep it updated is to use the snap:

sudo snap install ustriage

If using the snap is not possible, you can instead obtain it from git and run it by:

# Running with no arguments will get previous day's bugs
python -m ustriage

Dates

Dates must follow the format: %Y-%m-%d (e.g. 2016-11-30, 1999-05-22)

Single Date Argument

If only one date is given then all the bugs on that one day will be found. For example, the following finds all bugs last modified on only the 10th of September:

ustriage 2016-09-10

Two Date Arguments

If two dates are given then all the bugs found on those days and between (fully inclusive) will be found. For example, the following, finds all bugs last modified on the 10th, 11th, and 12th of September:

ustriage 2016-09-10 2016-09-12

Arguments

Follow Bug Links

By default the script outputs links of the form "LP: #XXXXXX". Ubuntu's default browser, gnome-terminal, makes these appear as hyperlinks automatically, saving space and leaving more for the bug titles. If instead you'd like full URLs, use --fullurls.

Open Bugs in Browser

Quite commonly the triager wants to open all bugs in the browser, to read, review and manage them. Via open argument that can be done automatically.

ustriage --open 2016-09-10 2016-09-12

Launchpad Name and Subscription Type

By default this searches for the structural subscription of the ubuntu-server Team. But depending on the use case one might overwrite the team name with --lpname (which can be any launchpad user, doesn't have to be a Team). Additionally, especially when setting a personal name it is common that the filter should be switched to check for bug subscription instead of a structural subscription which can be done via --bugsubscriber.

#  show all bugs user paelzer is subscribed to (without date modification filter)
ustriage --lpname paelzer --bugsubscriber

# show all bugs user paelzer is subscribed to that were modified last month
ustriage --lpname paelzer --bugsubscriber 2016-08-20 2016-09-20

Bug expiration

To have some kind of tracking of the bugs subscribed by ubuntu-server as well as those tagged server-todo we have to make sure that we identify those that are dormant for too long. Therefore by default bug expiration info is now added to the output by default.

Since these lists can be rather huge they are not opened in a browser by default. But if wanted a user can set the option --open-expire

ustriage 2016-09-10 2016-09-12 --open-expire

If instead a user is not interested at all in the expiration he can disable the report by --no-expiration

ustriage 2016-09-10 2016-09-12 --no-expiration

Output format

The default output format is tailored to a quick overview that also can be copy and pasted into our triage status reports.

But if someone wants to get more insight from those lists the argument --extended-format will add more fields to the output. Those are "date of the last update", "importance" and "assignee" (if there is any)

Further options and use cases of bug expiration

The expiration is defined as 60 days of inactivity in server-todo tagged bugs, and 180 days for the other ubuntu-server subscribed bugs. These durations as well as the tag it considers for the "active" list can be tuned via the arguments, --expire-tagged, --expire and --tag. This can be combined with a custom bug subscriber to be useful outside of the server team triage. So the following example for example will list any bugs subscribed by hardcoredev which are inactive for 5 or more days with the tag super-urgent.

ustriage 2016-09-10 2016-09-12 --expire-tagged 5 --tag super-urgent --bugsubscriber hardcoredev

Usage for server bug housekeeping

One can disable the default triage output via --no-show-triage and instead request lists of tagged bugs --show-tagged or just subscribed --show-subscribed. This is pretty handy on bug housekeeping as we use server-todo and subscription to ubuntu-server as our current two levels of bug tracking.

Thereby one can easily check all our current subscribed and server-todo tagged bugs (or any other tag via --tag):

It turned out to be a common need to identify differences since the last meeting. Since the situation in launchpad might have changed (dropped tag, closed the bug, assigned to other teams, changed subscription) and not all of them can be detected from launchpad-api after the fast ustriage now also provides the option to save and compare a list of stored bugs. On a usual run checking tagged bugs one can add -S to save the reported bugs to a file. It is recommended to include the timestamp like: -S ~/savebugs/todo-$(date -I'seconds').yaml

On later runs ustriage can compare the current set of bugs with any such stored list and report new bugs (flag "N") and reports a list of cases gone from the report.

Furthermore a common need is to see which bugs have had any updates recently. The option --flag-recent allows to specify an amount of days (we use 6 usually) that will make a bug touched in that period get an updated flag "U" in the report.

All that combined means that we usually run the following command for our weekly checks

ustriage --no-show-triage --extended --show-tagged --flag-recent 6 -S ~/savebugs/todo-$(date -I'seconds').yaml -C ~/savebugs/todo-2022-02-01T12:45:10+01:00.yaml

Or our bigger backlog of any open ubuntu-server (or any other via --lpname) subscribed bug task. This list can be rather long so --show-subscribed-max reduces it to that many entries from top and bottom of the list. This shows the most recent and the oldest 20 entries that are ubuntu-server subscribed.

ustriage --no-show-triage --show-subscribed --show-subscribed-max 20 --extended-format

Note: The file format on the save/compare feature isn't well defined, do consider it experimental as it might change without warning. OTOH right now being just a yaml list of bug numbers makes it very easy to - if needed - modify it.

Build and release the snap

Snaps like ustriage can be managed via the my snaps interface on snapcraft.io via the snap release management.

There are usually two reasons to build and release a new revision of ustriage:

• Changes we landed in the repository
• Doing no-change rebuilds to pick up updated dependencies The latter are usually needed when we get automated notifications that one such dependency had security updates.

Builds for Code changes

The ustriage snap is configured to be linked to this repository and therefore, whenever we push to the repository it will automatically trigger new builds that one can find in the builds overview.

No change rebuilds

If a rebuild is needed without a code change one can manually hit "Trigger new build" at the top of the builds overview page of the snap.

Releasing new snap revisions

No matter which of the two ways above was triggering the builds, they will automatically create new revisions which will go to the latest/edge channel as seen in the releases overview.

From there, these new revisions can be verified manually (manually because so far we only have superficial tox testing for some basics). Furthermore, tests are mostly manual, because most meaningful functions need valid launchpad credentials to be able to be executed.

Builds for code changes can stay in latest/edge until we want to push it to all users via the channel latest/stable. Rebuilds for security reasons should be pushed to latest/stable right after successful verification.

To do so one can hit "promote", which is a hidden button only shown when hovering over the revision seen on the releases overview. This will show a list of potential channels to promote to, usually latest/stable will be the target. Once that was done for all architectures hit "Save" in the top right and the new release is complete.