KnowledgeBase
Differences between revisions 162 and 178 (spanning 16 versions)
|
Size: 11577
Comment:
|
← Revision 178 as of 2019-12-10 22:29:10 ⇥
Size: 16
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| <<Include(ServerTeam/Header)>> ||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents(1)>>|| = Overview = The knowledge base contains development, test, and operational resources specific to the Ubuntu Server team. If you have any questions, don't hesitate to [[ServerTeam/Contact|contact]] other ServerTeam members. = Bug Triage = '''Goal:''' To successfully review every bug filed against Ubuntu Server related packages A review involves analyzing a bug to determine if the bug is valid and if sufficient information was provided. If the bug is both valid and provided with sufficient information, the bug is marked as triaged and will be worked to closure by a member of the server team. Otherwise, the bug will be responded to and marked as 'Incomplete' for more details, 'Invalid' for not a real bug, or 'Won't Fix'. 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]] == Daily Bug Triaging == Bug triage is completed for all bugs last updated on a particular day. An assigned member of the server team will look at all bugs that were updated on the previous day. For example, the member with responsibility on Friday will review all the bugs updated on Thursday. For the weekend, the member with responsibility on Monday will review all the bugs updated on Friday, Saturday, and Sunday. This process is expected to take less than 90 minutes per day. This is not meant to be a full root cause analysis (RCA) investigative time, instead only determining if further attention is warranted and sufficient information has been provided. Current members of Ubuntu Server bug triage: * [[https://launchpad.net/~paelzer|cpaelzer]] * [[https://launchpad.net/~ahasenack|ahasenack]] * [[https://launchpad.net/~nacc|nacc]] * [[https://launchpad.net/~powersj|powersj]] * [[https://launchpad.net/~racb|rbasak]] === 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". The goal is to have this list around ~20 bugs most of the time, if dropping below we can refill with candidates from the ~ubuntu-server subscribed bugs. But if it grows significantly out of this range it is non-realistic to expect those issues to be handled in time, we should communicate so to the reporters. === Daily Bug Expiration === There are two levels of expiration. The tooling will help to report these to the Triager. Eventually we want those lists of expiring bugs to be zero, and if they are not at least clear them on the day they expire. Note: ``especially initially these lists are rather huge and working through all of them takes various subject matter expertise, any help getting those re-triaged is highly appreciated.`` * '''Server-next expiration''' - default after '''60 days''' If we considered a bug actionable and added it to server-next, but then no update happened in 60 days that usually means something went wrong. Often bugs are blocked on external constraints. This needs to be evaluated as a case-by-case decision. Most common cases are, that it turns out: * that the bug is not solvable/reasonable the way it was planned -> re-triage, maybe drop server-next * that it is actually fixed or otherwise progressed without update -> update bug * that we failed to give it the required focus -> bring up in IRC meeting and Trello, search Developers who could assist, post excuse and explanation on the bug * '''Server subscription expiration''' - default after '''80 days''' If nobody touched a bug for 180 days (~= 1 release cycle) it is reasonable to check for changed conditions. Quite often e.g. a patch one was waiting on is available now. In other cases a newer release fixed it already. Essentially anything that is listed here needs to be fully re-triaged to ensure the list is reflecting the current status. It also can after this time be used as a metric how many more people chimed in got dupped on the bug (importance/#affected). Most common cases are, that it turns out: * that recent releases upstream or even already in Ubuntu have the fix -> re-triage, consider tagging server-next for SRU * that the bug should have been supported by the community but nothing happened -> re-triage importance, consider dropping ~ubuntu-server subscription * that a bug that was formerly considered a real case is not qualifying anymore (e.g. alternative solutions have taken hold as "the" way to do it) -> re-triage importance, consider dropping ~ubuntu-server subscription Overall for all of these we have to be honest to the bug reporter, try to understand why an issue was not worked on and explain it if possible. Also if we drop ''server-next'' or the ''~ubuntu-server subscrription'' for any of the reasons above always add a '''explanatory comment'''. If reporters disagree with our re-triage they will report on the bug and it will show up in the daily triage duty the next day to be reconsidered with that point of view taken into consideration. === Triage Task Assignment === Assignment of daily bug triage is completed as an agenda item of the server team's IRC meeting. Mostly each of us has a fix day per week, and we share Monday (which are all reports Fri-Sun) on a rotation. === 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]] = 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. = 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. = Testing = For an overview of our test areas and opportunities please see the [[Testing/Server|server testing section]] of the overall Ubuntu [[Testing|testing project]]. = Documentation = This area is involved with updating and creating new content for the [[https://help.ubuntu.com/lts/serverguide/|Ubuntu Server Guide]] and the [[https://help.ubuntu.com/community/|community help website]]. We are working with the DocumentationTeam and focus on server related topics. = Team policy = === Membership === The Membership policy is described in [[ServerTeam/Membership|Membership]]. === Reporting === The ServerTeam has a section in the [[TeamReports| monthly report]]. We try to get status reports on a weekly basis on the day preceding the IRC meeting. The [[ServerTeam/ReportingPage| ReportingPage]] is used to gather the outcome of the tasks done by the ServerTeam members during the week. The monthly report is a subpage under [[ServerTeam/ReportingPage]]. It's a summary from the Meeting minutes and the "a Month in the archive" post. The subpage is automatically included in the [[TeamReports| monthly team report]] with a macro as defined in the ServerTeam wiki page. == IRC Meeting == We hold IRC meeting regularly to report about current tasks and define new ones. The [[ServerTeam/Meeting| Meeting]] page presents the Agenda for the next meeting. [[ScribesTeam/MootBot|MootBot]] can be used to record the meeting. irclogs are available on http://irclogs.ubuntu.com/. === Publishing the Minutes === Once the meeting is over, minutes are prepared to summarized the outcome of the meeting. 1. Go to [[MeetingLogs/Server]] and use the form to create a new entry using the format YYYYMMDD. This will create a new page for you with the [[ServerTeamMeetingLogTemplate]]. a. Move the agenda from [[ServerTeam/Meeting]] to agenda section. a. Copy in the IRC logs from the "Minutes" link at the end of the meeting. This can be found on [[http://ubottu.com/meetingology/logs/ubuntu-meeting/]] a. Updated the minutes section with a summary of each section. You can template to work from using the IRC minutes you found the IRC logs from. Then fill in each section with your summary. 1. Update [[ServerTeam/Header]] to announce the next meeting date. 1. Update the Agenda for the next meeting at [[ServerTeam/Meeting]] a. In particular, remove completed ACTIONS, add new ones a. Update the list of Chair/Scribes a. move yourself to the back a. send an email to the person who will chair next week 1. Publish the minutes to the ubuntu-devel <ubuntu-devel@lists.ubuntu.com> and ubuntu-server <ubuntu-server@lists.ubuntu.com> mailing lists. Use the subject "Server team meeting minutes: YYYY-MM-DD" ---- CategoryServerTeam |
See ServerTeam |
See ServerTeam
ServerTeam/KnowledgeBase (last edited 2019-12-10 22:29:10 by powersj)