Getting Involved

Knowledge Base

Team Blog


Product Info


Ubuntu Cloud Portal

New bugs

NEXT MEETING: Tuesday 2017-07-25 at 1600 UTC - #ubuntu-meeting - AGENDA

NEXT BUG SQUASHING DAY: Wednesday 2017-06-28 - #ubuntu-server


The knowledge base contains development, test, and operational resources specific to the Ubuntu Server team. If you have any questions, don't hesitate to contact other ServerTeam members.

Bug Triage

Goal: To successfully review every bug filed against Ubuntu Server related packages

A review involves analyzing a bug to determine if the bug is valid and if sufficient information was provided. If the bug is both valid and provided with sufficient information, the bug is marked as triaged and will be worked to closure by a member of the server team. Otherwise, the bug will be responded to and marked as 'Incomplete' for more details, 'Invalid' for not a real bug, or 'Won't Fix'. In certain (rare) cases bugs might stay in new/confirmed which reflects we need to look into it again more deeply to triage in a better way.

This is a list of the various queues of interest to the server team. They are a good place to go if you are looking for a good "what to do next" bug.

Daily Bug Triaging

Bug triage is completed for all bugs last updated on a particular day. An assigned member of the server team will look at all bugs that were updated on the previous day. For example, the member with responsibility on Friday will review all the bugs updated on Thursday. For the weekend, the member with responsibility on Monday will review all the bugs updated on Friday, Saturday, and Sunday.

This process is expected to take less than 90 minutes per day. This is not meant to be a full root cause analysis (RCA) investigative time, instead only determining if further attention is warranted and sufficient information has been provided.

If a bug is considered to be a benefit to the majority of users and needing further attention by the Ubuntu Server Team the triager subcribes ~ubuntu-server to it. If possible a task is scheduled e.g. on for the team or by the triager subscribing/assigning himself to look into it later if possible. Please do note that the classic consideration of a bug being "actionable" is flagged place in the launchpad bug status. We might in some cases e.g. only want to track the bug and therefore subscribe ~ubuntu-server. But On the other hand a triager has to be clear that a totally un-actionable bug is likely to appear as expiring 180 days later, so if possible drive the bugs further via clarifications, questions, more bug tasks, subscribing subject matter experts and so on.

Current members of Ubuntu Server bug triage:


Since the backlog is bigger than what can be achieved in a short time, there is the extra classification via the tag server-next. That tag is set by the Triager (or anyone else working on doing the Root-Cause-Analysis or a Fix) to reflect that this is an issue that shall be tackled by the Teams resources "next".

Another reason to add server-next in some cases is to preserve high quality contributions of the community. An example might be a report that the user already bisected and created a patch for - in those cases the benefit diminishes by bit rot way too fast, so handling that next helps to retain the work the reporters did. And vice versa it might encourage one or the other to provide more high quality bugs.

The goal is to have this list around ~20 bugs most of the time, if dropping below we can refill with candidates from the ~ubuntu-server subscribed bugs. But if it grows significantly out of this range it is non-realistic to expect those issues to be handled in time, we should communicate so to the reporters.

Daily Bug Expiration

There are two levels of expiration. The tooling will help to report these to the Triager. Eventually we want those lists of expiring bugs to be zero, and if they are not at least clear them on the day they expire.

Note: especially initially these lists are rather huge and working through all of them takes various subject matter expertise, any help getting those re-triaged is highly appreciated.

  • Server-next expiration - default after 60 days

    • If we considered a bug actionable and added it to server-next, but then no update happened in 60 days that usually means something went wrong. Often bugs are blocked on external constraints. This needs to be evaluated as a case-by-case decision. Most common cases are, that it turns out:
    • that the bug is not solvable/reasonable the way it was planned -> re-triage, maybe drop server-next

    • that it is actually fixed or otherwise progressed without update -> update bug

    • that we failed to give it the required focus -> bring up in IRC meeting and the, search Developers who could assist, post excuse and explanation on the bug

  • Server subscription expiration - default after 180 days

    • If nobody touched a bug for 180 days (~= 1 release cycle) it is reasonable to check for changed conditions. Quite often e.g. a patch one was waiting on is available now. In other cases a newer release fixed it already. Essentially anything that is listed here needs to be fully re-triaged to ensure the list is reflecting the current status. It also can after this time be used as a metric how many more people chimed in got dupped on the bug (importance/#affected). Most common cases are, that it turns out:
    • that recent releases upstream or even already in Ubuntu have the fix -> re-triage, consider tagging server-next for SRU

    • that the bug should have been supported by the community but nothing happened -> re-triage importance, consider dropping ~ubuntu-server subscription

    • that a bug that was formerly considered a real case is not qualifying anymore (e.g. alternative solutions
      • have taken hold as "the" way to do it) -> re-triage importance, consider dropping ~ubuntu-server subscription

Overall for all of these we have to be honest to the bug reporter, try to understand why an issue was not worked on and explain it if possible. Also if we drop server-next or the ~ubuntu-server subscrription for any of the reasons above always add a explanatory comment. If reporters disagree with our re-triage they will report on the bug and it will show up in the daily triage duty the next day to be reconsidered with that point of view taken into consideration.

Triage Task Assignment

Assignment of daily bug triage is completed as an agenda item of the server team's IRC meeting. Mostly each of us has a fix day per week, and we share Monday (which are all reports Fri-Sun) on a rotation.


To assist with the triaging there is By default it will list the bugs of the current days Triager, but it can be controlled via commandline arguments. That way one can easily do tasks like "last wednesdays tirage duty" if one was away a few days.

Furthermore it will list the expiring bugs that should be re-triaged.

Additional Resources

Helpful Guides and Definitions:

Developer & Packaging Resources

We are focusing on server related packages in main and universe. Developers can use the Triaged Ubuntu Server bugs list to prioritize their work.

For packaging information, head to the MOTUs, the Master Of The Universe.

For Ubuntu release specific resources, the Ubuntu Team wiki is the central location where Ubuntu developers exchange ideas and track their progress.


The server team utilizes IRC to offer support for server-related questions. The team sits on freenode in the #ubuntu-server channel.

The ubottu IRC bot makes it easy to share an extensive set of factoids to others in an IRC channel. E.g. typing !ask | noobie will cause ubottu to tell noobie that folks should just go ahead and ask their questions. Ubottu can also conveniently show the channel information on bugs and packages. See ubottu for more details.


For an overview of our test areas and opportunities please see the server testing section of the overall Ubuntu testing project.


This area is involved with updating and creating new content for the Ubuntu Server Guide and the community help website. We are working with the DocumentationTeam and focus on server related topics.

Team policy


The Membership policy is described in Membership.


The ServerTeam has a section in the monthly report. We try to get status reports on a weekly basis on the day preceding the IRC meeting. The ReportingPage is used to gather the outcome of the tasks done by the ServerTeam members during the week.

The monthly report is a subpage under ServerTeam/ReportingPage. It's a summary from the Meeting minutes and the "a Month in the archive" post.

The subpage is automatically included in the monthly team report with a macro as defined in the ServerTeam wiki page.

IRC Meeting

We hold IRC meeting regularly to report about current tasks and define new ones. The Meeting page presents the Agenda for the next meeting.

MootBot can be used to record the meeting.

irclogs are available on

Publishing the Minutes

Once the meeting is over, minutes are prepared to summarize the outcome of the meeting.

  1. Go to MeetingLogs/Server and use the form to create a new entry using the format YYYYMMDD. This will create a new page for you with the ServerTeamMeetingLogTemplate.

    1. Move the agenda from ServerTeam/Meeting to agenda section.

    2. Copy in the IRC logs from the "Minutes" link at the end of the meeting. This can be found on

    3. Update the minutes section with a summary of each section. You can template to work from using the IRC minutes you found the IRC logs from. Then fill in each section with your summary.
  2. Update ServerTeam/Header to announce the next meeting date.

  3. Update the Agenda for the next meeting at ServerTeam/Meeting

    1. In particular, remove completed ACTIONS, add new ones
    2. Update the list of Chair/Scribes
      1. move yourself to the back
      2. send an email to the person who will chair next week
  4. Publish the minutes to the ubuntu-devel <> and ubuntu-server <> mailing lists. Use the subject "Server team meeting minutes: YYYY-MM-DD"


ServerTeam/KnowledgeBase (last edited 2017-06-27 14:21:14 by ahasenack)