ServerTeam
Size: 10401
Comment: imported from the old wiki
|
Size: 20451
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
#ubuntu-server on Libera Chat IRC |
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:
- Providing a robust and stable infrastructure for scale-out computing deployments.
- Supporting the latest scale-out computing workloads and architectures.
- 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:
Choose a bug from the New,Unconfirmed bug list and subscribe to it.
- Work with the user to identify the issue using the INCOMPLETE status.
- 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.
- You can unsubscribe from the bug as your role as a bug triager is finished.
- 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:
- 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).
- 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.
- 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.
- 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:
- 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.
- Tag only if one of these two things are true:
- Delays will discourage this excellent community contribution.
- If you believe it affects a major use case for Ubuntu server users. In this case you should also set the bug Importance.
- 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.
- 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.
- If the bug is assigned to or otherwise owned by someone on our team, there is no need to tag it.
- 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.
There is the PackagingGuide.
PackagingGuide/Lists/DocumentationResources and MOTU/School have information related to packaging.
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.
For Ubuntu release specific resources, 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.
For server packages stuck in proposed from migrating to release:
ServerTeam (last edited 2022-02-10 14:05:02 by paelzer)