ServerTeam

Differences between revisions 1 and 58 (spanning 57 versions)
⇤ ← Revision 1 as of 2005-05-28 20:52:42 →
Size: 10401
Editor: adsl-213-190-44-43
Comment: imported from the old wiki
← Revision 58 as of 2020-01-29 02:18:53 → ⇥
Size: 20451
Editor: bryce
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= ServerTeam =

== Ubuntu Linux Server Team ==

The server team, under the able stewardship of Thom "I Bleed For Servers" May, aims to ensure that Ubuntu installs cleanly on data-center grade servers from all major manufacturers. While linux support for server hardware is now generally excellent, the servers themselves often present unusual challenges for the installer. Team Leader: Thom May.


=== Goals ===

 * Make Ubuntu first class general purpose server platform, with special emphasis on ease of use for the admin.
 * Diversify even more range of hardware platforms Ubuntu could use as a server system on.
 * Make sure Ubuntu servers scale nicely with workload.
 * Make Ubuntu an attractive server platform for orgs and coprporations.
 * Bring ubuntu to the state which allows it to seemingly assimilate in clustering environments.

=== Issues ===
 
Ubuntu is a desktop system common perception, how to change?

 * Education, Documentation: Ubuntu as a router, web/nfd/Samba/print/mail/http/content/telephony server.
 * Tools: make server bleeding edge available to skilled admins, make everybody a skilled admin in the future with easier tools and the right interfaces.
 * Marketing : Talk about how Ubuntu is already integrating nicely in hetrogeneous networks. (i.e. win/novell/linux/sun ...)
 * Special editions : Ubuntu Internet Server, Ubuntu Telephony Platform, Ubuntu LAN Server , Ubuntu DevHub Server ....


=== People ===


 * SivanGreen (documentation, planning, testing)
 * JeffBailey
 * Ghe Rivero

From JeffBailey Tue Feb 8 23:25:43 +0000 2005
From: Jeff Bailey
Date: Tue, 08 Feb 2005 23:25:43 +0000
Subject: Thoughts I'd like to note down of things that I really want
Message-ID: <20050208232543+0000@https://www.ubuntulinux.org>

Things I would love to see in the server distro:

* Some sort of /etc/iptables.d/ where packages could drop pieces discribing what they need opened on the firewall, and have a default deny all firewall installed as part of base.

* mailman come with the right pieces to integrate with exim4 and postfix. (And sendmail, but I know I'm the only one who loves sendmail here.. *sigh*)

* config lint checking at every server 'restart'. apache, bind9, and many others come with a pre-flight check. This should be run as part of a /etc/init.d/FOO restart, to make sure that the server can safely restart, and leave the server alone if the config file is not suitable.

* Remove inetd by default. It's too easy to have something silently add itself there.



From NiallSheridan Wed Feb 9 13:54:59 +0000 2005
From: Niall Sheridan
Date: Wed, 09 Feb 2005 13:54:59 +0000
Subject: groupware
Message-ID: <20050209135459+0000@www.ubuntulinux.org>

How about a groupware server? Perhaps based on opengroupware, as it is web-based, but client plugins for Outlook and Evolution exist?

From MarkRzepa Wed Feb 9 15:09:51 +0000 2005
From: Mark Rzepa
Date: Wed, 09 Feb 2005 15:09:51 +0000
Subject: System monitoring and self healing
Message-ID: <20050209150951+0000@https://www.ubuntulinux.org>

It would be nice to see a server that monitors all it's services (apache, bind etc...) and maintains a "last known good" state, it if detects any problems with one of it's services, it should try and fix the problem by doing things like restart the service or it will automatically rollback any changes that have been made since it's "last know good" state. This could include restoring configuration files or downgrading packages to a previous version.

From JeffBailey Thu Feb 10 20:55:27 +0000 2005
From: Jeff Bailey
Date: Thu, 10 Feb 2005 20:55:27 +0000
Subject: Audit logging for Apt
Message-ID: <20050210205527+0000@https://www.ubuntulinux.org>

Apt should syslog what it did (before and after)

From MarkRzepa Fri Feb 11 00:26:41 +0000 2005
From: Mark Rzepa
Date: Fri, 11 Feb 2005 00:26:41 +0000
Subject: RE: Audit logging for Apt
Message-ID: <20050211002641+0000@https://www.ubuntulinux.org>

Generating meaningful reports based on the logged data would be an asset.
e.g. Monthly Package Update Report
     6 packaged updated
       4 due to security fixes
       1 due to bug fix
       1 due to new version release

From GheRivero Thu Mar 3 21:58:35 +0000 2005
From: Ghe Rivero
Date: Thu, 03 Mar 2005 21:58:35 +0000
Subject: Central Managment
Message-ID: <20050303215835+0000@https://www.ubuntulinux.org>

There should be a central control panel to see the state of the differents servers (Uptime, disk space, pending updates, services running), mainly in a Web interface to be available everywhere. The comunication between servers and the central can be done using XMLRPC over ssh. (Some thing like the RedHat Network but much better)

From GheRivero Thu Mar 3 22:29:09 +0000 2005
From: Ghe Rivero
Date: Thu, 03 Mar 2005 22:29:09 +0000
Subject: SELinux
Message-ID: <20050303222909+0000@https://www.ubuntulinux.org>

Default kernels and policy for the most used servers (web, mail) should be provided and active bu default

From AndrewMitchell Fri Mar 4 11:32:20 +0000 2005
From: Andrew Mitchell
Date: Fri, 04 Mar 2005 11:32:20 +0000
Subject: SELinux tools
Message-ID: <20050304113220+0000@https://www.ubuntulinux.org>

Kernels are enabled with the needed options (except networking hooks, it seems), and a policy is in selinux-policy-default that needs fixed up before hoary. A policy just for common daemons would be like Fedora's targetted policy.

From GheRivero Sun Mar 6 23:43:12 +0000 2005
From: Ghe Rivero
Date: Sun, 06 Mar 2005 23:43:12 +0000
Subject: Central Managment
Message-ID: <20050306234312+0000@https://www.ubuntulinux.org>

Something is been doing at the moment. http://savannah.nongnu.org/projects/ulnc/. It uses XMLRPC over ssh and python to access the servers, get info of them, manage package system. More improvement and a GUI is necesary.

From MatthewGibbons Mon Apr 11 01:23:21 +0100 2005
From: Matthew Gibbons
Date: Mon, 11 Apr 2005 01:23:21 +0100
Subject: apt-get install ubuntu-sbs
Message-ID: <20050411012321+0100@https://www.ubuntulinux.org>

I currently maintain a number of Microsoft Windows Small Business Servers, and to be honest, they are more of less a joy to administer. Out of the box you get integrated DHCP/DNS, shared files, shared printing, Exchange (with POP3 connector), MSSQL, firewall, intranet, and backup. I would like to see the same approach taken with ubuntu-sbs (this being a meta-package with dependencies to include all the necessary services). I have done some work along these lines already, but lack direction on Exchange replacement (Hula?).

From AndrewTimberlake-Newell Fri Apr 15 17:51:50 +0100 2005
From: Andrew Timberlake-Newell
Date: Fri, 15 Apr 2005 17:51:50 +0100
Subject: Paying attention to Mom and Pop
Message-ID: <20050415175150+0100@https://www.ubuntulinux.org>

Mine is just a bit similar to Matthew's. I'm currently planning a system for a small business with a globe-trotting sales force and needs for a server to synchronize and backup files via VPN...maybe with some later use as email/database. They're a touch phobic of non-MS systems, and I've been searching high and low for a distro targeted for migration from SBS...one which at least clearly bills itself as doing the job and lists all the noteworthy features. Maybe even a highlighted set of instructions for migration from SBS to distro X.

From JimCheetham Mon Apr 18 00:40:29 +0100 2005
From: Jim Cheetham
Date: Mon, 18 Apr 2005 00:40:29 +0100
Subject: UbuntuDownUnder?
Message-ID: <20050418004029+0100@https://www.ubuntulinux.org>

Anyone (besides me :-) planning on attending the upcoming UbuntuDownUnder? I'd like to meet a few people interested in server issues ...

From shermann Mon Apr 18 23:15:27 +0100 2005
From: shermann
Date: Mon, 18 Apr 2005 23:15:27 +0100
Subject: Ubuntu running as Server
Message-ID: <20050418231527+0100@www.ubuntulinux.org>

I replaced now my gentoo 2005.0 with ubuntu hoary 5.04
there r a couple of pitfalls and the debootstrap installation installs a nice workstation system after `base-config new` call <- has to be changed. After all, a nice work...StephanHermann

From JoelWagler Tue May 3 05:20:26 +0100 2005
From: Joel Wagler
Date: Tue, 03 May 2005 05:20:26 +0100
Subject: small buisness server.
Message-ID: <20050503052026+0100@https://www.ubuntulinux.org>

I'd like to see the sbs server Like Matthew Gibsons. I'd like to see samba/ldap/groupware/backup/fileserver/print server/etc all properly setup and integrated in a server. I think Open Groupware might be a good choice as a groupware server. A groupware server ideally should
* Not depend on Java (open source issues)
* Integrate well with evolution, outlook, thunderbird, and other opensource clients
* Have a web interface.
* Be an "exchange" replacement.
* Integrate well with other products. Use open standards, choice of DB's, mail servers ideally.

In general you should be able to put an ubuntu server in and easily replace a microsoft server. Windows clients/ and Ubuntu clients should be well supported (Bonus would be Mac OS as well)


From JoelWagler Fri May 13 08:51:20 +0100 2005
From: Joel Wagler
Date: Fri, 13 May 2005 08:51:20 +0100
Subject: SME server
Message-ID: <20050513085120+0100@https://www.ubuntulinux.org>

Hello, all I think a good idea of what an ubuntu server edition would be SME server (http://www.contribs.org). It's a linux, rpm based :( distro that integrates a lot of server stuff into a common interface. It has things like ldap, samba, ftp, ssh, vpn, dns, email, website, fileserver (quotas), backup, etc and all configurations can be accessed from a nice web interface. X windows is not even installed.

From PieterduPreez Sat May 28 17:18:54 +0100 2005
From: Pieter du Preez
Date: Sat, 28 May 2005 17:18:54 +0100
Subject: SME Server
Message-ID: <20050528171854+0100@https://www.ubuntulinux.org>

I cannot agree more. I am a Linux newbie and I have a home server, Apapche, LDAP, Samba, Mail, Proxy etc etc and it is on-line and available 100%. I run about 10 websites on it, have multiple users etc. SME server is a good approach for general users and given the uncertainty and lack of progress in the development of newer versions may just be ready for a "takeover" by Canonical		 = Ubuntu Server Team =

<<Include(ServerTeam/Header)>>

~+The [[http://launchpad.net/people/ubuntu-server|Ubuntu Server team]] works to enable and promote the use of Ubuntu Server, the number one cloud OS.+~

We specifically focus on three key areas:

 1. Providing a robust and stable infrastructure for scale-out computing deployments.
 2. Supporting the latest scale-out computing workloads and architectures.
 3. Providing the right tools for orchestrating services within a scale-out computing environment.

== Communication ==

If you want to contact the ServerTeam use the following resources:

=== Mailing List ===

Join our mailing list at https://lists.ubuntu.com/mailman/listinfo/ubuntu-server.

You can read an archive of messages at https://lists.ubuntu.com/archives/ubuntu-server/.

=== IRC ===

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

The [[https://wiki.ubuntu.com/UbuntuBots|ubottu]] IRC bot makes it easy to share an extensive set of [[http://ubottu.com/factoids.cgi|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 [[https://wiki.ubuntu.com/UbuntuBots|ubottu]] for more details.

== Getting Involved ==

There are different areas where you can help the Ubuntu Server Team. Here are a few ideas:

=== Help on Mailing List & IRC ===

You can lend a hand with people's questions and problems on the above mailing list and the IRC channel. Ask and answer questions, provide suggestions, and provide input in our periodic calls for input.

=== Test, Test, Test ===

If you have server-type hardware or can spin up VMs and containers, you can make sure that Ubuntu is supported and works well on it. You can also test software and features worked on by the Ubuntu Server Team.

=== Improve Documentation ===

You can head to the [[https://help.ubuntu.com/community/|community documentation]] to check that server related pages are up to date or help to get the Ubuntu Server Team wiki pages into shape. You can also [[https://ubuntu.com/server/docs|help with the Ubuntu Server Guide]], the official Server documentation.

=== Verify SRUs ===

Whenever we fix a bug in past stable releases, we need somebody who is not the developer making the fix to verify that the package fixes and doesn't cause any obvious regressions. It is vital that we have people test these updates before they are sent to all users.

The full process for doing so is here:

[[QATeam/PerformingSRUVerification]]

Here is the [[http://people.canonical.com/~chucks/SRUTracker/sru-tracker-bugs.html#verified_bugs|list of server bugs needing verification]].

=== Triage Bugs ===

The goal of triage is to move bugs that are in a NEW status to a CONFIRMED or INVALID status.

To get started:
 1. Choose a bug from [[https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.importance%3Alist=UNDECIDED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=ubuntu-server&field.bug_commenter=&field.subscriber=&field.component-empty-marker=1&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&field.tag=&field.tags_combinator=ANY&field.has_no_package.used=&search=Search|the New,Unconfirmed bug list]] and subscribe to it.
 1. Work with the user to identify the issue using the INCOMPLETE status.
 1. Once the bug is reproducible and the process to reproduce it is clearly documented in the bug thread set the status to CONFIRMED. If it turns out that there isn't any bug set the status to INVALID.
 1. You can unsubscribe from the bug as your role as a bug triager is finished.
 1. Read more bug triaging resources:
    * [[BugSquad/KnowledgeBase]]
You should also subscribe to the [[https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs|ubuntu-server-bugs mailing list]] where all the bugs are sent. You can also view the [[https://bugs.launchpad.net/~ubuntu-server/|list of bugs related to the ServerTeam]] and help triaging them.

=== Improve Packages ===

You can have a look at the [[https://bugs.launchpad.net/~ubuntu-server/+packagebugs|list of packages]] looked after by the Ubuntu Server Team to see if some needs packaging work.

This is a excellent way to gain experience to become a [[MOTU]].

== Ubuntu Server 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.

{{{#!wiki comment
contact davidpbritton if you want these bit.ly vanity links modified
}}}
 * [[http://bit.ly/ubuntu-server-next|Top 20 Bugs ("server-next")]]
 * [[http://bit.ly/ubuntu-server-bitesize|Bite-sized Bugs]]
 * [[http://bit.ly/ubuntu-server-recent|Recently modified Bugs]]
 * [[https://bugs.launchpad.net/~ubuntu-server/+subscribedbugs|Full Backlog]]

=== Process ===

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 [[https://launchpad.net/~ubuntu-server|Ubuntu Server Team]] the triager subscribes ~ubuntu-server to it. If possible a task is scheduled e.g. on [[https://trello.com/b/U9HhWyT0/daily-ubuntu-server||Daily Ubuntu-Server Trello]] 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 non-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: https://launchpad.net/~ubuntu-server-active-triagers/+members

=== Direct team subscriptions ===

We subscribe ~ubuntu-server directly to a bug to track our community bug backlog when the bug meets the following criteria. When the bug no longer meets these criteria, we unsubscribe it:

 1. Anything that, if the bug turns out to valid, is something that would be under the ~ubuntu-server remit to fix (common use cases but not obscure ones - but nothing stops an individual volunteering to work on an obscure use case, of course).

 1. By definition, if it's something that we wouldn't fix and request volunteers even if we had time, then it doesn't warrant a subscription.

 1. This subscription is for the Ubuntu Server triage community and is not for tracking of internal Canonical customer requests. Whether a Canonical customer has made a request in relation to a particular bug makes no difference and provides no additional priority under this process. A Canonical customer bug may still be subscribed if it qualifies under these criteria.

 1. If the bug is assigned to someone on our team, leave it subscribed. No need to subscribe, and feel free to unsubscribe.

==== server-next ====

Since the backlog is bigger than what can be achieved in a short time, there is the extra classification via the tag ''[[http://bit.ly/ubuntu-server-next|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.

The rules of the server-next tag are as follows:

 1. Must not tag unless bug is actionable. Doesn't mean it must have a patch, only that a developer has enough information to work on the bug, even if it means more debugging.

 1. Tag only if one of these two things are true:
   1. Delays will discourage this excellent community contribution.
   1. If you believe it affects a major use case for Ubuntu server users. In this case you should also set the bug Importance.

 1. The set of all bugs tagged server-next must be kept small. If it grows, the lowest priority bugs tagged server-next must be removed until the list isn’t too big.

 1. This tag is for the Ubuntu Server triage community and is not for tracking of internal Canonical customer requests. Whether a Canonical customer has made a request in relation to a particular bug makes no difference and provides no additional priority under this process. A Canonical customer bug may still be tagged if it qualifies under these criteria.

 1. If the bug is assigned to or otherwise owned by someone on our team, there is no need to tag it.

 1. Remove the tag when the bug is assigned to or otherwise owned by someone on our team.

=== 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 -> add the server-triage-discuss tag to the bug and bring it in the next standup

 * '''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
  * if unsure, add the server-triage-discuss tag and bring it up at the next standup

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.

=== Tooling ===

To assist with the triaging there is [[https://github.com/powersj/ubuntu-server-triage/||ubuntu-server-triage]].
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:

 * [[https://wiki.ubuntu.com/ServerTeam/KnowledgeBase/BugTriage|Bug Triage Workflow]]
 * [[https://wiki.ubuntu.com/ServerTeam/KnowledgeBase/BugSubscriptionAndTagging|Bug Triage Tags and Subscriptions]]
 * [[Bugs/Importance|Definitions for bug importance levels]]
 * [[Bugs/Status|Definitions for bug status settings]]
 * [[DebuggingServer|Server specific triage responses]]
 * [[Bugs/Responses|Additional predefined response templates]]

== Ubuntu Server Packaging ==

We are transitioning to a [[UbuntuDevelopment/Merging/GitWorkflow|git-based workflow]] for handling package changes. This also allows us to use Launchpad Merge Proposals and request Reviews before publishing a new package version.

=== Requesting a review ===

There are three review teams within canonical-server:
 * ''canonical-server-core-reviewers'': members are Ubuntu Core Developers and can upload any package
 * ''canonical-server-motu-reviewers'': members are Ubuntu MOTU developers and can upload to Universe
 * ''canonical-server-packageset-reviewers'': members are Ubuntu Server Developers and can upload Server related packages
To find out which team should review your branch, use the `ubuntu-upload-permission` tool from the `ubuntu-dev-tools` package and select the most specific team:
{{{
$ ubuntu-upload-permission --list-uploaders <package>
}}}
A second review slot should always be requested for the ''canonical-server'' team, as we want the merge proposal to always show up in the [[https://launchpad.net/~canonical-server/+activereviews|active reviews page]] for the ''canonical-server'' team regardless if a review slot was taken or not. Launchpad [[https://bugs.launchpad.net/bugs/1708172|bug #1708172]] was filed about it, but for now we will use this workaround.

All this translates to the following `git ubuntu` command:
{{{
$ git ubuntu submit --reviewer canonical-server --reviewer <reviewer team> --target-branch <target>
}}}
In this command, `<target>` depends on which Ubuntu release you are targeting:
 * `ubuntu/devel`: for the current development version of Ubuntu
 * `ubuntu/<name>-devel`: for the `<name>` Ubuntu release. For example, if preparing an SRU for Xenial, the target reference path would be `ubuntu/xenial-devel`.

Alternatively, you can go to [[https://launchpad.net/people/+me/+git]], select your repository, a branch within, and then "propose for merging". The details to be filled out are:
 * target repository: that will be `lp:~usd-import-team/ubuntu/+source/<sourcepackage>`
 * target reference path: the same as `<target>` in the `git ubuntu submit` command above
 * reviewer: ''canonical-server-core-reviewers'', ''canonical-server-motu-reviewers'' or ''canonical-server-packageset-reviewers''. This depends on the package, see previous discussion about using the `ubuntu-upload-permission` tool to find out.
After proposing the merge, request a second reviewer slot for ''canonical-server'' and you are set.

Eventually you will get review comments. These can of a few types:
 * just a comment. Can also be a non-formal review from someone outside the server team.
 * approval (also known as a +1)
 * needs information: the reviewer didn't understand something, or wants clarification
 * needs fixing: the reviewer didn't agree with something and is requesting that it be changed
 * disapprove: the approach to the problem is incorrect (also known as a -1)
 * abstain (also known as a +0)
 * resubmit: you should resubmit the proposal, possibly because the package has changed while this review was up
If you need to work on something in your merge proposal, you should set its status back to "work in progress" to signal others that you are addressing the issue. This will have the effect of removing the proposal from the queue and then people can concentrate on reviewing other branches while you work on yours. If you have [[https://trello.com/b/U9HhWyT0/daily-ubuntu-server|Server Trello board]] rights, you should also move the review card back to the "Doing" list. Once you are done, place it again in the "Review Requests" list and change the status of your MP to "needs review".

=== Reviewing a Merge Proposal ===

First of all, never claim the ''canonical-server'' review slot. That slot should remain unclaimed as its sole purpose is to facilitate viewing all merge proposals in a single page. You should only claim the review slot of one of the canonical-server reviewers teams. You are welcome to add a review comment anytime, however.

If you have [[https://trello.com/b/U9HhWyT0/daily-ubuntu-server|Server Trello board]] rights, once the review is claimed, move the corresponding Trello card in the server board from the "Review Requests" list to the "Review-Doing" one.

=== Developer & Packaging Resources ===
We are focusing on server related packages in main and universe. Developers can use the [[http://tinyurl.com/triaged-ubuntu-server|Triaged Ubuntu Server bugs]] list to prioritize their work.

For packaging information, head to the [[MOTU|MOTUs, the Master Of The Universe]].
 * There is the [[PackagingGuide]].
 * [[PackagingGuide/Lists/DocumentationResources]] and [[MOTU/School]] have information related to packaging.
 * [[UbuntuDevelopers]] explains how to become an official packager.
 * [[https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu|ubuntu-motu mailing list]] and #ubuntu-motu on irc.freenode.org are good places to ask for help.

For Ubuntu release specific resources, the [[https://wiki.ubuntu.com/|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 [[http://lists.ubuntu.com/mailman/listinfo/ubuntu-devel|ubuntu-devel mailing list]] and #ubuntu-devel on irc.freenode.net are the places where ubuntu developers can be found.

For server packages stuck in proposed from migrating to release:
 * [[https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#ubuntu-server|Proposed Migration - Server]]
 * [[ServerTeam/ProposedMigrationNotes]]

----
[[CategoryServerTeam]]<<BR>>
CategoryUbuntuTeams

Ubuntu Server Team

The Ubuntu Server team works to enable and promote the use of Ubuntu Server, the number one cloud OS.

We specifically focus on three key areas:

  1. Providing a robust and stable infrastructure for scale-out computing deployments.
  2. Supporting the latest scale-out computing workloads and architectures.
  3. Providing the right tools for orchestrating services within a scale-out computing environment.

Communication

If you want to contact the ServerTeam use the following resources:

Mailing List

Join our mailing list at https://lists.ubuntu.com/mailman/listinfo/ubuntu-server.

You can read an archive of messages at https://lists.ubuntu.com/archives/ubuntu-server/.

IRC

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.

Getting Involved

There are different areas where you can help the Ubuntu Server Team. Here are a few ideas:

Help on Mailing List & IRC

You can lend a hand with people's questions and problems on the above mailing list and the IRC channel. Ask and answer questions, provide suggestions, and provide input in our periodic calls for input.

Test, Test, Test

If you have server-type hardware or can spin up VMs and containers, you can make sure that Ubuntu is supported and works well on it. You can also test software and features worked on by the Ubuntu Server Team.

Improve Documentation

You can head to the community documentation to check that server related pages are up to date or help to get the Ubuntu Server Team wiki pages into shape. You can also help with the Ubuntu Server Guide, the official Server documentation.

Verify SRUs

Whenever we fix a bug in past stable releases, we need somebody who is not the developer making the fix to verify that the package fixes and doesn't cause any obvious regressions. It is vital that we have people test these updates before they are sent to all users.

The full process for doing so is here:

QATeam/PerformingSRUVerification

Here is the list of server bugs needing verification.

Triage Bugs

The goal of triage is to move bugs that are in a NEW status to a CONFIRMED or INVALID status.

To get started:

  1. Choose a bug from the New,Unconfirmed bug list and subscribe to it.

  2. Work with the user to identify the issue using the INCOMPLETE status.
  3. Once the bug is reproducible and the process to reproduce it is clearly documented in the bug thread set the status to CONFIRMED. If it turns out that there isn't any bug set the status to INVALID.
  4. You can unsubscribe from the bug as your role as a bug triager is finished.
  5. Read more bug triaging resources:

You should also subscribe to the ubuntu-server-bugs mailing list where all the bugs are sent. You can also view the list of bugs related to the ServerTeam and help triaging them.

Improve Packages

You can have a look at the list of packages looked after by the Ubuntu Server Team to see if some needs packaging work.

This is a excellent way to gain experience to become a MOTU.

Ubuntu Server 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.

Process

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 subscribes ~ubuntu-server to it. If possible a task is scheduled e.g. on https://trello.com/b/U9HhWyT0/daily-ubuntu-server 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 non-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: https://launchpad.net/~ubuntu-server-active-triagers/+members

Direct team subscriptions

We subscribe ~ubuntu-server directly to a bug to track our community bug backlog when the bug meets the following criteria. When the bug no longer meets these criteria, we unsubscribe it:

  1. Anything that, if the bug turns out to valid, is something that would be under the ~ubuntu-server remit to fix (common use cases but not obscure ones - but nothing stops an individual volunteering to work on an obscure use case, of course).
  2. By definition, if it's something that we wouldn't fix and request volunteers even if we had time, then it doesn't warrant a subscription.
  3. This subscription is for the Ubuntu Server triage community and is not for tracking of internal Canonical customer requests. Whether a Canonical customer has made a request in relation to a particular bug makes no difference and provides no additional priority under this process. A Canonical customer bug may still be subscribed if it qualifies under these criteria.
  4. If the bug is assigned to someone on our team, leave it subscribed. No need to subscribe, and feel free to unsubscribe.

server-next

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.

The rules of the server-next tag are as follows:

  1. Must not tag unless bug is actionable. Doesn't mean it must have a patch, only that a developer has enough information to work on the bug, even if it means more debugging.
  2. Tag only if one of these two things are true:
    1. Delays will discourage this excellent community contribution.
    2. If you believe it affects a major use case for Ubuntu server users. In this case you should also set the bug Importance.
  3. The set of all bugs tagged server-next must be kept small. If it grows, the lowest priority bugs tagged server-next must be removed until the list isn’t too big.
  4. This tag is for the Ubuntu Server triage community and is not for tracking of internal Canonical customer requests. Whether a Canonical customer has made a request in relation to a particular bug makes no difference and provides no additional priority under this process. A Canonical customer bug may still be tagged if it qualifies under these criteria.
  5. If the bug is assigned to or otherwise owned by someone on our team, there is no need to tag it.
  6. Remove the tag when the bug is assigned to or otherwise owned by someone on our team.

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 -> add the server-triage-discuss tag to the bug and bring it in the next standup

  • 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

    • if unsure, add the server-triage-discuss tag and bring it up at the next standup

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.

Tooling

To assist with the triaging there is https://github.com/powersj/ubuntu-server-triage/. 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:

Ubuntu Server Packaging

We are transitioning to a git-based workflow for handling package changes. This also allows us to use Launchpad Merge Proposals and request Reviews before publishing a new package version.

Requesting a review

There are three review teams within canonical-server:

  • canonical-server-core-reviewers: members are Ubuntu Core Developers and can upload any package

  • canonical-server-motu-reviewers: members are Ubuntu MOTU developers and can upload to Universe

  • canonical-server-packageset-reviewers: members are Ubuntu Server Developers and can upload Server related packages

To find out which team should review your branch, use the ubuntu-upload-permission tool from the ubuntu-dev-tools package and select the most specific team: 

$ ubuntu-upload-permission --list-uploaders <package>

A second review slot should always be requested for the canonical-server team, as we want the merge proposal to always show up in the active reviews page for the canonical-server team regardless if a review slot was taken or not. Launchpad bug #1708172 was filed about it, but for now we will use this workaround.

All this translates to the following git ubuntu command: 

$ git ubuntu submit --reviewer canonical-server --reviewer <reviewer team> --target-branch <target>

In this command, <target> depends on which Ubuntu release you are targeting:

  • ubuntu/devel: for the current development version of Ubuntu

  • ubuntu/<name>-devel: for the <name> Ubuntu release. For example, if preparing an SRU for Xenial, the target reference path would be ubuntu/xenial-devel.

Alternatively, you can go to https://launchpad.net/people/+me/+git, select your repository, a branch within, and then "propose for merging". The details to be filled out are:

  • target repository: that will be lp:~usd-import-team/ubuntu/+source/<sourcepackage>

  • target reference path: the same as <target> in the git ubuntu submit command above

  • reviewer: canonical-server-core-reviewers, canonical-server-motu-reviewers or canonical-server-packageset-reviewers. This depends on the package, see previous discussion about using the ubuntu-upload-permission tool to find out.

After proposing the merge, request a second reviewer slot for canonical-server and you are set.

Eventually you will get review comments. These can of a few types:

  • just a comment. Can also be a non-formal review from someone outside the server team.
  • approval (also known as a +1)
  • needs information: the reviewer didn't understand something, or wants clarification
  • needs fixing: the reviewer didn't agree with something and is requesting that it be changed
  • disapprove: the approach to the problem is incorrect (also known as a -1)
  • abstain (also known as a +0)
  • resubmit: you should resubmit the proposal, possibly because the package has changed while this review was up

If you need to work on something in your merge proposal, you should set its status back to "work in progress" to signal others that you are addressing the issue. This will have the effect of removing the proposal from the queue and then people can concentrate on reviewing other branches while you work on yours. If you have Server Trello board rights, you should also move the review card back to the "Doing" list. Once you are done, place it again in the "Review Requests" list and change the status of your MP to "needs review".

Reviewing a Merge Proposal

First of all, never claim the canonical-server review slot. That slot should remain unclaimed as its sole purpose is to facilitate viewing all merge proposals in a single page. You should only claim the review slot of one of the canonical-server reviewers teams. You are welcome to add a review comment anytime, however.

If you have Server Trello board rights, once the review is claimed, move the corresponding Trello card in the server board from the "Review Requests" list to the "Review-Doing" one.

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.

For server packages stuck in proposed from migrating to release:

CategoryServerTeam
CategoryUbuntuTeams

ServerTeam (last edited 2022-02-10 14:05:02 by paelzer)