diff --git a/doc/upstream-training/source/slides/howitsmade-events.rst b/doc/upstream-training/source/slides/howitsmade-events.rst index 1664aec5..4bb050ec 100644 --- a/doc/upstream-training/source/slides/howitsmade-events.rst +++ b/doc/upstream-training/source/slides/howitsmade-events.rst @@ -9,84 +9,19 @@ OpenStack Events .. note:: Tags: [management] [operator] [user] [new_dev] [dev] -Regional Events -=============== - -- OpenStack Days -- OpenStack Birthday Celebration -- User Group Meetups - -OpenStack Days -============== - -- Regional 'Mini-Summit' -- Hosted annually by local OpenStack User Groups and companies -- Endorsed by the Foundation -- Growing in number (26 in 2016) - Exercise 1 ========== - Look up an OpenStack Days event close to where you live that you would be interested in attending -OpenStack Birthday Celebration -============================== - -- Held by local groups to celebrate another year of OpenStack -- 2017 was 7th birthday of OpenStack - -User Group Meetups -================== - -- Smaller scale than OpenStack Days Events -- Some are more development focused while others are more user and - ops focused -- https://groups.openstack.org/ - -Global Events and Releases -========================== - -- Each Release has two main events: PTG and the Summit -- The PTG is scheduled around the start of a release to plan release goals -- Summits take place around the middle of a release to exhibit accomplishments - and get feedback from users on the most recent release - -Project Team Gathering (PTG) -============================ - -- A gathering of projects teams and contributors -- Dedicated and detailed technical discussions -- Useful for participants if they are already working with a - project team -- Not good as an entry point - -.. note - https://www.openstack.org/ptg - https://www.openstack.org/ptg/ptgfaq/ Exercise 2 ========== - Look up the location and dates of the next PTG -Summit & Forum -============== +Exercise 3 +========== -- The summit is a biannual conference with keynotes, presentations, - and panel discussions -- Forum: - - - User focused discussions at the Forum to collect feedback - for developers - - Better entry point for new contributors finding their place in the - community - -Types of sessions at the Forum -============================== - -- Fishbowls: Open moderated discussions -- Project Onboarding Sessions: A place for new contributors to ask - questions and get to know other contributors to the project -- Hacking Rooms: Reservable rooms for projects to gather for technical - discussions +- Look up the location and dates of the next Summit/Forum. diff --git a/doc/upstream-training/source/slides/howitsmade-governance.rst b/doc/upstream-training/source/slides/howitsmade-governance.rst index 3916988f..ac7b439d 100644 --- a/doc/upstream-training/source/slides/howitsmade-governance.rst +++ b/doc/upstream-training/source/slides/howitsmade-governance.rst @@ -9,232 +9,21 @@ OpenStack Governance .. note:: Tags: [management] [new_dev] [dev] -OpenStack Foundation -==================== -- Nonprofit foundation created to "develop, support, protect, and promote" - OpenStack - - - Individual members: all of us - - Institutional members: Platinum and Gold sponsors - - Further supporting companies and organizations - -- Multi-layer group of leadership - - - Board of directors - - Technical Committee - - User Committee - -Board of Directors -================== - -- Strategic and financial oversight -- Representatives are elected from - - - Platinum member companies - - Gold member companies - - Individual Foundation members - -.. note:: - - - Each Platinum member can delegate one member - - Gold members can delegate the same amount of members as Platinum members - - - by majority vote of all Gold Members - - - Individual members elect the same amount - - For more info see Article IV of `Bylaws of the OpenStack Foundation - `_ - -Technical Committee ("TC") -========================== - -- Provides - - - Oversight over the OpenStack projects - - Technical leadership - -- Enforces OpenStack ideals like: Openness, Transparency, Commonality, - Integration and Quality -- Handles cross-project related topics and issues -- Composed of 13 OpenStack Foundation Individual members - - - directly elected by ATC's - - The TC Chair is proposed by the TC members - -.. note:: - - - `OpenStack Technical Comittee page `_ - - `OpenStack Technical Comittee Charter `_ - - `List of TC members `_ - -User Committee ("UC") -===================== - -- Represents OpenStack users -- Gathers feedback and consolidates requirements -- Further details are in a later session - -.. note:: - - - `OpenStack User Committee page `_ - - `Members of OpenStack User Comittee `_ - -Exercise -======== - -- Find the current members of the Board of Directors, TC and UC -- Find the latest election results for Board of Directors, TC and UC. - Also find where the OpenStack election procedures are documented. -- Post the information and web sites in the Upstream Collaboration Training - Etherpad. - -.. note:: - - - The election of Board of Directors is announced via - `Board election page `_, - and the election result can be seen in - `Foundation mailing list `_. - - TC (+PTL) candidates and election results are available on - `Governance - Election page `_, - and shared through `openstack-dev mailing list `_. - - UC election information is available though - `User-committee mailing list `_. - -OpenStack Project Teams -======================= - -- Teams of people who - - - Produce *deliverables* to achieve a clearly stated *objective* - - Using the common tools (code repository, bug tracker, CI system, etc.) - - Work towards OpenStack's mission - -- Teams in OpenStack can be freely created as they are needed -- Official project teams fall under the TC's authority and are led by a - Project Team Lead and Core Team Members -- The official list of projects: - - - https://governance.openstack.org/reference/projects/ - -.. note:: - - - Source file is hosted in the `governance repository `_ - -Active Technical Contributor (ATC) -================================== - -- Subset of the Foundation Individual Members -- Committed a change over the last two 6-month release cycles - - - Code or documentation contribution to any of the official project - repositories - - Individual members, can be granted ATC status by the PTL of an official - project and TC approval. This is called extra-ATC status. - -- An OpenStack wide status -- TC members are elected by the ATC's - -.. note:: - - - ATC's should be proposed into `projects.yaml - `_ - under ``extra-atcs`` of the actual project, but not after the - `Extra-ATC's deadline `_ - of the cycle expired. - -Active Project Contributor (APC) -================================ - -- Subset of ATCs who have contributed to a specific project -- Same criteria as ATC except for contributions to a project -- OpenStack project specific status - -Project Team Leads (PTLs) -========================= - -- Elected from and by the group of APC's -- Each PTL candidate needs to submit PTL candidacy -- PTL responsibilities - - - Manage day-to-day operations - - Drive the program goals - - Resolve technical disputes - - `Other responsibilities `_ - -.. note:: - - - The responsibilities of a PTL also depend on the project - (Each project handles things a little differently). - -Core Team Members -================= - -- Have authority to merge code into a project -- Assist the PTL in driving program goals -- New Core Team members are nominated and elected by other Core Team Members -- Unlike ATC, APC and PTLs, role is not defined in the TC charter - -.. note:: - - - Election process is more informal than PTLs. - - PTL or Core Team Member nominates a person. - - Core team membership is about merging on master, stable core membership is independent - - PTL e-mails nomination to mailing list. - - Though not defined in the TC charter like other roles above, cores - serve an important role in Project Teams. - - Person is elected if no team members object to the nomination. - -Active User Contributors (AUC) -============================== - -- Users with the following activities are recognized with AUC status: - - - Organizers of Official OpenStack User Groups - - Active members and contributors to functional teams and/or working groups - - Moderators of any of the operators' official meet-up sessions - - Contributors to the repository under the UC governance - - Track chairs for OpenStack Summits - - Contributors to Superuser - - Active moderators on ask.openstack.org - -.. note:: - - - `OpenStack User Committee Charter `_ - -Exercise -======== - -- Determine who the current PTL is of your favorite project. -- Post their name, the project and a project goal for the next release in - the Upstream Collaboration Training Etherpad. -- Find two other cores in the project and post their names in - the Upstream Collaboration Training Etherpad. - - -References +Exercise 1 ========== - - `Board election `_ - - `Bylaws of the OpenStack Foundation `_ - - `Foundation mailing list `_ - - `Governance - Election page `_ - - `List of TC members `_ - - `Members of OpenStack User Comittee `_ - - `openstack-dev mailing list `_ - - `OpenStack Technical Comittee Charter `_ - - `OpenStack Technical Comittee page `_ - - `OpenStack User Committee `_ +- Find the current members of the Board of Directors, TC and UC -.. note:: +Exercise 2 +=========== - - This slide is for reference links in case people want to get more information later. Presenters - do not need to spend time on this. +- Find the latest election results for Board of Directors, TC and UC. +- Which members of these groups will be up for reelection during the + next round? -References Cont. -================ +Exercise 2 +========== - - `OpenStack User Committee Charter `_ - - `User-committee mailing list `_ +- What is the difference between ATC, AUC, and APC? diff --git a/doc/upstream-training/source/slides/howitsmade-official-projects.rst b/doc/upstream-training/source/slides/howitsmade-official-projects.rst index df31737a..ba9faf0e 100644 --- a/doc/upstream-training/source/slides/howitsmade-official-projects.rst +++ b/doc/upstream-training/source/slides/howitsmade-official-projects.rst @@ -1,5 +1,5 @@ =========================== -Official OpenStack projects +Official OpenStack Projects =========================== .. image:: ./_assets/os_background.png @@ -10,101 +10,14 @@ Official OpenStack projects Tags: [management] [operator] [user] [new_dev] [dev] -Official OpenStack projects -=========================== -- `Requirements `_ - for official OpenStack projects -- Projects improve and grow independently but also strive to improve one - collaborative framework: OpenStack - - - Projects APIs are documented within the project - - Testable on its own - - Dashboard (horizon) and DevStack provide plugin interface for easy - integration - - Official OpenStack projects are tracked in the - `Project Navigator `_ - -- Big Tent was a code name for the official OpenStack projects - - .. note:: - - - Not all projects are currently tracked in Project Navigator. The goal, - however, is for it to be an ever growing list. - -Benefits of being an Official OpenStack project -=============================================== -- Contributors get to vote in the Technical Committee election -- Can publish to docs.openstack.org and developer.openstack.org -- The teams get space at OpenStack Summits and Project Team Gatherings (PTG) -- Get marketing from the OpenStack Foundation -- Can participate in common programs, like mentoring and internship to help - with on boarding -- Get guidance from community members and leaders -- Its activities are under the oversight of the TC - - .. note:: - - - PTG: https://www.openstack.org/ptg/ - - `Mentoring `_ is run by the Women - of OpenStack group, where mentees are guided through the OpenStack processes. - - The OpenStack Foundation participates in internship programs as - `Outreachy `_. - - Official OpenStack projects can participate by offering topics and mentors - for the interns who sign up for this program. - -Core and Optional Services -========================== -- Core services are OpenStack projects and essential in every OpenStack-powered - IaaS cloud or product -- Optional services are also OpenStack projects but not necessarily needed to - operate OpenStack depending on use cases - -.. note:: - - - Full list of Official OpenStack Project Teams: - https://governance.openstack.org/tc/reference/projects/index.html - -Core and Optional Services -========================== - -.. image:: ./_assets/official-openstack-projects.png - :scale: 90 % - - -Exercise -======== +Exercise 1 +========== - Find the requirements that must be met to be an official OpenStack project -- Tags can be associated with projects. Find out what tags are and find the - current list of available tags. - -.. note:: - - https://governance.openstack.org/tc/reference/new-projects-requirements.html - - An official project is aligned with the OpenStack Mission if it - - - has a clear and defined scope - - provides a cloud infrastructure service or directly builds on an - existing OpenStack cloud infrastructure service - - Follows/observes the four opens: Source, Community, Development, Design - - - https://governance.openstack.org/reference/tags/index.html - - - Describe the artifacts created by an OpenStack community team - - Processes followed, release management, etc. - - -References +Exercise 2 ========== - - `PTG `_ - - `Mentoring `_ - - `Internship Programs `_ - - `OpenStack Project Teams `_ - - `New Project Requirements `_ - - `Tags `_ +- Tags can be associated with projects. Find out what tags are used for and + find the current list of available tags. -.. note:: - - - This slide is for reference links in case people want to get more information later. Presenters - do not need to spend time on this. diff --git a/doc/upstream-training/source/slides/howitsmade-release-cycle.rst b/doc/upstream-training/source/slides/howitsmade-release-cycle.rst index f949954e..9a2cdd18 100644 --- a/doc/upstream-training/source/slides/howitsmade-release-cycle.rst +++ b/doc/upstream-training/source/slides/howitsmade-release-cycle.rst @@ -9,45 +9,9 @@ OpenStack Release Cycle .. note:: Tags: [management] [operator] [user] [new_dev] [dev] -What makes a release -==================== -- Coordinated development of multiple projects -- Release process is managed by the Release Management team -- Release models - - - *Common cycle with development milestones* - - Common cycle with intermediary release - - Trailing the common cycle - - Independent release model - -- A given project cannot follow more than one model - -.. note:: - - - Release management description: - https://docs.openstack.org/project-team-guide/release-management.html - - The training concentrates on the common cycle with the development - milestones as that is what most students will work with. The other types - should be described. - - Common cycle with intermediary release: - - - Used for components needing more frequent releases. e.g. Oslo Libraries - - Intermediary releases can also be used to time releases near the - beginning and end of the release cycle. Horizon plug-ins do this. - - - Trailing the common cycle: - - - Projects dependent upon the output of a release, like packaging or - deploying OpenStack follow this model; e.g. Fuel and Kolla - - - Independent release model: - - - These projects may hold tools used for OpenStack but are not part of a - production release. - -Exercise -======== +Exercise 1 +========== - Look up the release schedule for the current and past two OpenStack release cycles @@ -64,237 +28,24 @@ Exercise - Post the information on the IRC channel -Common cycle with development milestones -======================================== -- Project teams create their deliverables, including testing and - documentation, on a coordinated schedule -- Every cycle includes - - - Planning and design activities - - Implementation work - - - New features - - Bug fixes - - Testing - - Documentation - - - Release preparation - - Release - -Planning - Design -================= - -- Design activity is a continuous effort -- Planning for a release cycle starts at the end of the previous cycle - - - Face to face planning discussions happen at the Project Teams Gathering - (PTG) which is coordinated with the start of a development new cycle - -- Each project team sets priorities/dates for the release - - - Spec/blueprint freeze - - Prioritization of items (e.g. testing, documentation, etc.) - -- Generic intention behind planning - - - Take a step back - - Focus on what we want to do for the next one - -Planning - Discuss -================== - -- Prepare your idea for proposal to the community. - - - Discuss with your project team - - - PTG is a good time to propose and discuss features/fixes - - - Work on feedback and comments - -- Capture your idea in a spec/blueprint - -.. note:: - - - Whether a change requires just a blueprint or spec and blueprint - depends on the complexity of the change. - - Start with a blueprint and look to the project team's core members - for guidance on whether a spec is needed. - -Planning - Target -================= - -- Submit the blueprints and/or specs -- Identify a target milestone - - - When in the cycle you intend to complete it - - Project team helps you to identify the target milestone and register it - in the tracking tool - -- The priority of the work item is set by the project team members or lead -- Feature proposal freeze - - - The deadline for proposing new ideas for a release cycle - - The exact date is determined by each project team - -Exercise -======== +Exercise 2 +========== - Find feature proposal deadlines in the current release schedule - Compare the deadlines between two different project teams and discuss the differences with your group -Implementation -============== - -- When your blueprint/spec is accepted - - - Push code to Gerrit for review - - Upload your code as early as possible in the release cycle - - Code can be uploaded before a blueprint/spec is accepted - -- Deadlines for the code to get merged - - - Depends on the priority of your work item - - Set by each project team - -Implementation - Milestone -========================== - -- Three development milestones during a release cycle -- Make useful reference points in time to organize the development cycle -- Milestones are tagged in the repository using b1, b2 and b3 -- Overall feature freeze is the third milestone - -Exercise -======== +Exercise 3 +========== - In addition to milestones, there are freeze dates for different activities in the release - Work with your group to find and discuss the different freeze activities -.. note:: - - - Spec freeze - - - Point at which specs must be proposed and reviewed for the release. - - - Feature freeze - - - Code for new features is no longer accepted. - - - String freeze - - - Externally visible strings can no longer be changed. Helps translation - activities complete on time. - - - Requirements freeze - - - Requirements cannot be changed to allow downstream packagers time to - pull-in and build dependencies. - -Release Candidates -================== - -- After the last milestone -- Code stabilization period -- Main activities - - - Test the code and file bugs - - Prioritize bugs / bug triage - - - Get critical and high priority bugs fixed first - - Fix as many bugs as possible - - - Finalize documentation - -.. note:: - - - Code change during the RC phase is a balancing act - - - Need to balance integrating fixes and code churn - - Critical fixes have the highest priority while more minor bug fixes may - be safer to hold for the subsequent release. - - - Who is able to approve patches during the RC phase is limited. - -Release candidate process -========================= - -- Release Candidate 1 (RC1) is cut when all the release-critical bugs are fixed -- stable/release branch -- master branch is open for development -- Used as-is as the final release -- Additional Release Candidates created for critical bugs found during - RC testing - - - (RC2, RC3, ...) with bugs targeted to it - - Repeated as many times as necessary - -Release day -=========== - -- Last published release candidate from all Project Teams -- Published collectively as the OpenStack release - -Exercise -======== +Exercise 4 +========== - Find the release day for the current release - Find where the currently released code is posted - -Stable Branch -============= - -- Name for a cycle that has been released -- Projects that follow some form of the 'Common' release - cycle have branches like 'stable/' in their repo -- Support phases - -+------------+-----------------------------+---------------------------------+ -| Phase | Time Frame | Changes Supported | -+============+=============================+=================================+ -| I | First 6 months | All appropriate bug fixes | -+------------+-----------------------------+---------------------------------+ -| II | 6 - 12 months after release | Only critical or security fixes | -+------------+-----------------------------+---------------------------------+ -| III | More than 12 months | Only security fixes accepted | -+------------+-----------------------------+---------------------------------+ - - -Proposing fixes to Stable Branches -================================== -- Fixes to stable must first merge to master and all intermediate branches -- Appropriate backports - - - Low regression risk in stable branch - - Fixes a user visible problem - - Backport is self contained - -- Inappropriate backports - - - Backports of new functionality - - Changes to external HTTP APIs - - Notification, DB Schema or incompatible config file changes - -Stable Branch Reviews -===================== - -- Stable maintenance teams - - - Each project has a subset of cores able to merge stable branch changes - -- Ensure that the stable branch policies are enforced -- Ensure that backports are associated with the patch submitted to master - - -References -========== - - - `Release management description `_ - -.. note:: - - - This slide is for reference links in case people want to get more information later. Presenters - do not need to spend time on this. diff --git a/doc/upstream-training/source/slides/workflow-commit-message.rst b/doc/upstream-training/source/slides/workflow-commit-message.rst index 8d66c5cf..a78d5c44 100644 --- a/doc/upstream-training/source/slides/workflow-commit-message.rst +++ b/doc/upstream-training/source/slides/workflow-commit-message.rst @@ -9,31 +9,8 @@ Commit Messages .. note:: Tags: [new_dev] [dev] -Commit Messages -=============== - -- The first thing a reviewer sees and it is as important as the code -- Brief explanation with context about the patch -- Provide a description of the history of changes in a - repository -- Cannot be modified once merged -- Format: - - - Summary Line - - Body - - External References - -- Guidelines: https://wiki.openstack.org/wiki/GitCommitMessages - -Summary Line -============= - -- Succinctly describes patch content -- Limited to 50 characters -- Should not end with a period - -Exercise -======== +Exercise 1 +========== Write a summary line for each of the following scenarios: @@ -46,20 +23,8 @@ Write a summary line for each of the following scenarios: Share your favorite to our IRC channel. -Body -==== - -- Lines limited to 72 characters -- Explanation of issue being solved and why it should be fixed -- Explain how the problem is solved -- Other possible content - - - Does it improve code structure? - - Does it fix limitations of the current code? - - References to other relevant patches? - -Exercise -======== +Exercise 2 +========== Write a commit message body to expand on each of the following summary lines. Feel free to make up details to make the context more realistic. @@ -69,41 +34,9 @@ Share your favorite in IRC. - Minimize database queries - Added unit tests to cover untested methods -Do not assume ... -================= -- The reviewer understands what the original problem was -- The reviewer has access to external web services/site -- The code is self-evident/self-documenting - -External References -=================== - -- Required: - - - Change-Id - - Task Tracking Info: - - - Bug (Partial-Bug, Related-Bug, Closes-Bug) - - Blueprint (Partial-Implements, Implements) - -- Additional External References: - - - DocImpact - - APIImpact - - SecurityImpact - - UpgradeImpact - - Depends-On - -.. note:: - Explain the tags and when you use them. Documentation, API, - Security or Upgrade Impacts are for patches with changes that - alter the existing state. Depends-On is for cross repository - dependencies. Change-Id's are filled in automatically with git - review -s. - -Exercise -======== +Exercise 3 +========== Write a commit message for the bug you created during our earlier exercise. Include a summary line, body, and the required exernal references diff --git a/doc/upstream-training/source/slides/workflow-project-status-and-zuul.rst b/doc/upstream-training/source/slides/workflow-project-status-and-zuul.rst index 339fd9b7..7c801efa 100644 --- a/doc/upstream-training/source/slides/workflow-project-status-and-zuul.rst +++ b/doc/upstream-training/source/slides/workflow-project-status-and-zuul.rst @@ -9,63 +9,8 @@ OpenStack Project Status and Zuul .. note:: Tags: [new_dev] [dev] -OpenStack Infrastructure and Project Status -=========================================== -- `http://status.openstack.org `_ - - - Zuul - - Rechecks - - Reviews - - Bugday - - OpenStack-Health - -.. note:: - - - Zuul is the project gating and automation system that tests and merges - changes as well as publishing releases and documentation. - - Rechecks has a list of bugs and associated information for - nondeterministic check/gate failures. - - Reviews has a list of important reviews based on blueprint and bug priority - organized by project. - - Bugday shows real-time stats during bug smash days. - - OpenStack-Health has a dashboard of overal OpenStack test results. - -Zuul -==== - -.. image:: ./_assets/workflow-project-status-and-zuul-zuul-page.png - -Zuul Pipelines -============== -- Check - - - Run against all newly updated patch sets - - Runs unit testing, Pep8, docs/releasenote build and - functional tempest testing - - Zuul votes +1/-1 depending on test results - -- Gate - - - Only run after a patch is approved by a core reviewer - - More extensive testing than check pipeline - - Runs another unit test run along with additional tempest testing - - 'Gates' code entering the stable or master branches - -Zuul Pipelines - cont. -====================== - -- Post - - - Jobs run against a patch after it merges - - Documentation build/publishing, tarball generation, image build - -.. note:: - - - The above jobs are examples of what is run in each pipeline. - What is actually run varies based upon the project being tested. - -Exercise -======== +Exercise 1 +========== - Look at the `Zuul `_ status page - Find the information that can be retrieved for each patch in a pipeline @@ -78,108 +23,9 @@ Exercise - Discuss your findings with your group -Patch Number -============ -.. image:: ./_assets/workflow-project-status-and-zuul-patch-id.png - :class: image-pad-top - -.. note:: - - - The number next to 'Change' is the patch number. - - Can use the patch number to track status in Zuul status page. - -Filtering on Patch Number in Zuul -================================= - -.. image:: ./_assets/workflow-project-status-and-zuul-zuul-job-status.png - :class: image-pad-top - -.. note:: - - - Shows the Zuul status page filtered down to just the patch of interest. - - -Zuul Failures -============= - -.. image:: ./_assets/workflow-project-status-and-zuul-zuul-fail.png - :class: image-pad-top - - - -Analysing Zuul Failures -======================= -- Logs may be accessed by clicking on the test's name - - - Directs the user to saved log output - - Uses the browser to view the logs - -- Voting and non-voting jobs - - - Voting job failures cause a -1 vote from Zuul on the patch - - Non-voting jobs do not cause a -1 vote from Zuul upon failure - -- Non-voting jobs are new jobs that are being tested and may not yet be ready - to vote - -Logs -==== - -.. image:: ./_assets/workflow-project-status-and-zuul-zuul-failure-log-list.png - :class: image-pad-top - -.. note:: - - - Example of what the logs for a run look like - - Actual log files will vary depending on the test you are examining - -Logs - Testr HTML Report -======================== - -.. image:: ./_assets/workflow-project-status-and-zuul-failure-testr-html.png - :class: image-pad-top - - -Logs - Job Run Output -===================== - -.. image:: ./_assets/workflow-project-status-and-zuul-failure-log.png - :class: image-pad-top - -Intermittent Failures -===================== -- Caused by timing/connectivity issues in check/gate -- May receive elastic recheck message -- List of `Rechecks `_ -- To trigger a re-run of check or gate add a comment to the patch - in the form of 'recheck bug XXXXX' - -Recheck Example -=============== - -.. image:: ./_assets/workflow-project-status-and-zuul-recheck-example.png - :class: image-pad-top - -.. note:: - - - Note ability to see logstash and link to launchpad - -What Are Rechecks -================= - -- Issues causing intermittent failures -- Elastic search is used to look for logs indicating similar failures - - - Users add new bugs to - `elastic-recheck `_ - -- Goal is to capture all instances of a failure in the hopes of identifying - patterns causing the bug -- Comments on patches that hit a known bug - -Exercise -======== +Exercise 2 +========== - Find how rechecks are categorized - Discuss with your table how you would determine you encountered one of these bugs