Reports
*IMPORTANT*
Puppet has moved from Trac to Redmine for ticketing. You can find the new Redmine instance here. You will not be able to lodge tickets on the old Trac site. For the moment the Trac wiki will continue to be used as the project's documentation store.
*IMPORTANT*
This page provides a description of the various ticket stages, severities, and priorities. It also contains a variety of useful ticket queries into the ticket database.
To learn about the Puppet development lifecycle and ticket triage please see the Development Lifecycle wiki page.
If you're looking for simple tickets to start working on, start here.
Common Reports
Tickets Needing Work
- Accepted tickets that need patches
- Accepted tickets that need unit tests
- Accepted tickets whose patches need to be improved
- Tickets assigned to me
All Tickets
All Other Reports
Triage stage
Puppet's development process is entirely keyed off of the ticket database. All tickets have a Triage stage attached, which is the pivot point that determines what happens next with tickets. (This process is heavily based off of the Django development process. Here are the various triage states that tickets can be in:
- Unreviewed: No developers have had the opportunity to assess whether these are valid problems or are enhancement requests with sufficient information.
- Needs design decision: Tickets that cannot be acted upon without some design decision by the development community.
- Accepted: Tickets that have been accepted, meaning that if patches are submitted that provide the desired functionality, those patches will be accepted. This state is in no way a promise to fix the ticket, merely the statement that fixes will be accepted.
- Ready for checkin: Tickets that are ready for checking into trunk, meaning all code and tests are available either in a branch or as a patch.
Milestones
Puppet development uses milestones to choose the next batch of tickets to be worked on. There is always a major milestone, indicating the tickets that are planned but not necessarily being actively worked on. There is often also a minor milestone, indicating tickets that will be in the next release.
- TBD
Attached patches
Whether the ticket has a patch attached. Tickets with patches are accepted far more quickly, especially if the patches include tests.
- None: No patch attached.
- Code: A patch is attached with code, but no tests. These tickets are fixed more quickly than those with no patches, but they still require time to implement and thus are not fixed as quickly as those with tests.
- Tests: A patch with code and tests. Assuming the ticket is approved, these patches can essentially be applied immediately.
- Insufficient: This ticket has a patch, but the patch needs improvement. Tickets tagged this way should have an explanation attached.
Complexity
How complex the ticket is expected to be. Note that these are usually estimates and might be quite far off the mark. The purpose of this category is to give community members an idea of whether a ticket is approachable.
- Unknown: Tickets whose difficulty has not been assessed.
- Trivial: Tickets expected to be trivial and thus won't require test code, such as simple documentation fixes.
- Easy: Tickets expected to be easy to fix -- the test code is probably going to more difficult than the functional code.
- Medium: Tickets that should be approachable by a single developer in a single session.
- Hard: Tickets that should be developed in a branch, as they will likely require multiple programming sessions and multiple design decisions.
