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'.
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 30 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.
Current members of Ubuntu Server bug triage:
Assignment of daily bug triage is completed as an agenda item of the server team's IRC meeting.
Helpful Guides and Definitions:
For packaging information, head to the MOTUs, the Master Of The Universe.
There is the PackagingGuide.
UbuntuDevelopers explains how to become an official packager.
ubuntu-motu mailing list and #ubuntu-motu on irc.freenode.org are good places to ask for help.
We're focusing on server related packages in main and universe.
Developers can use the Triaged Ubuntu Server bugs list to prioritize their work.
Ubuntu Server Daily Builds
In order for our users latest testing software of various server software we have the Ubuntu Server Dailies PPA. To get software added one has to do the following:
Add yourself to the Ubuntu Server Edgers Launchpad group here.
- If the project that you wish to add is not apart of launchpad, register the project and import the code into a launchpad branch.
Follow the instructions on how to build a daily package here.
- Create a PPA in the Ubuntu Server Edgers group, the format for the PPA is the following:
Display Name: <project> Edgers Archive
- Description: Fill with relevant informaion
PPA Name: server-edgers-<project>
- Create your recipe
- Publish to a blog post that the ppa is available to users.
Stack package names policy
Integration work on specific server stacks (Mail stack, cluster stack, etc...) sometimes result in specific integration binary packages. In order to provide a coherent user experience, those binary packages should follow the following naming rule:
As an example, mail stack packages could be named "mail-stack-delivery", "mail-stack-relay"...
Decision from 20100525 team meeting.
Server support resources
The server team offers support for server-related questions in #ubuntu-server.
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.
New test plans should be defined as new pages below Testing/Server. Example: Testing/Server/MyTestPlan.
Ubuntu Server iso testing follows the process described in Testing/ISO. We focus on testing the ubuntu-server isos following the Server installation test cases. The Iso testing tracker is used to track test results.
You can register with the iso testing tracker and subscribe to the ubuntu server testcases so that you'll be notified whenever a new ubuntu-server iso needs to be tested.
The Ubuntu Test Automation Harness introduces new way of creating end-to-end automated test cases without having to worry about the provisioning side of things. This tool is an attempt to unify the current automated testing for Ubuntu Jenkins.
Most, but sadly not all bigger software projects fortunately have functional tests being part of their build process and if stable enough that is usually enabled in deb packaging. Furthermore most packages have a dep8 test associated to guarantee basic verification of more complex tests. But then for server packages in particular sometimes the required constraints or setup can be too complex for a dep8 test. As we go a long we often develop manual or scripted tests for those. I successful and reasonable they might end up being executed regularly in the server regression tests. But if not we at least leave the breadcrumbs for the next one needing it at Verification Tests
Ubuntu Server Guide
Here are the steps to modify the Ubuntu Server Guide and ask the DocumentationTeam to review your changes:
- Create a directory where you'll put your local working version of the Ubuntu Server Guide:
$ bzr init-repo ubuntu-docs $ cd ubuntu-docs
- Get the ubuntu-docs files that have the latest version of the Ubuntu Server Guide:
$ bzr branch lp:ubuntu-docs $ cd ubuntu-docs
NB: that command can take some time as the whole history of the branch has to be downloaded from Launchpad.
Update the Ubuntu Server Guide files using your favorite editor. They can be found in the serverguide/C/ directory.
- Once your changes are complete, commit them:
$ bzr commit
And send them to the ubuntu-doc mailing lists with the bzr send command:
$ bzr send --firstname.lastname@example.org
Alternatively you can attach a diff of your changes to the associated bug report (do this before you commit your changes).
$ bzr diff > doc-change.patch
There is alot of useful information about making changes to system documentation in the DocumentationTeam/SystemDocumentation wiki page.
The WikiGuide has guidelines for contributing to the help website.
If help is needed, the ubuntu-doc mailing list and #ubuntu-doc on irc.freenode.net are good places to ask around.
The Ubuntu Team wiki, at https://wiki.ubuntu.com/, is focused on documentation for Ubuntu community contributors rather than for end users
The Ubuntu Team wiki is the central location where Ubuntu developers exchange ideas and track their progress.
UbuntuDevelopment gives an overview of the development processes.
The ubuntu-devel mailing list and #ubuntu-devel on irc.freenode.net are the places where ubuntu developers can be found.
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 montly report is a subpage under ServerTeam/ReportingPage. It's a summary from the Meeting minutes and the "a Month in the archive" post.
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 http://irclogs.ubuntu.com/.
Publishing the minutes
Once the meeting is over, minutes are prepared to summarized the outcome of the meeting.
Move the agenda from ServerTeam/Meeting to agenda section.
Copy in the IRC logs from the "Minutes" link at the end of the meeting. This can be found on http://ubottu.com/meetingology/logs/ubuntu-meeting/
- Updated 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.
Update ServerTeam/Header to announce the next meeting date.
Update the Agenda for the next meeting at ServerTeam/Meeting
- In particular, remove completed ACTIONS, add new ones
- Update the list of Chair/Scribes
- move yourself to the back
- send an email to the person who will chair next week