Milestone Schedule

Handling Tickets (bugs/enhancements)



Ticket Workflow

  • The latest ticket workflow should be listed at CldrWorkflow on the trac server, and is pictured at right.
  • http://unicode.org/cldr/trac/wiki/CldrWorkflow

Filing tickets

  1. You can add set other fields, but don't change the Owner. That way the committee sees the incoming tickets (those marked as Owner: somebody).
If you really have to fix a bug right away, file it and send a notice to cldr-dev explaining what you are doing and why. Otherwise, file the bug, wait for the next Wednesday meeting for discussion and approval.

Assigners

  1. The committee assesses the tickets weekly.
    1. Straightforward ones are just assigned and prioritized and given a milestone.
    2. Questionable ones are assigned, but left with priority=assess. The assignee will report back before doing anything.
    3. More complicated ones are moved into the design folder for later discussion at the meeting.
    4. Don't fix a bug until it's been approved.
  2. If a ticket has multiple owners, the Notes must describe who is doing what. Otherwise it needs to be split into multiple tickets.

Assignees

  1. Assignees periodically review and take care of their tickets.
    1. Go to http://unicode.org/cldr/trac/report/14 for My Tickets
  2. assess: Tickets marked "assess" need to be evaluated. Send your suggested disposition to the cldr group by email.
  3. duplicate: If the ticket is a duplicate, any extra information is copied to the other ticket, an xref is set in both, and the ticket is returned.
  4. splitting:
    1. If the ticket requires separate phases, such as a change to the spec, then a separate ticket is filed, with xrefs set in both.
    2. If part of a ticket cannot be completed in the release:
      1. Set the milestone to the release number
      2. Add a comment indicating what part of the ticket was done, and what part wasn't.
      3. Set a reviewer.
      4. Create a new ticket for the remaining work, with an xref to the old bug.
  5. problems:
    1. If the ticket can't be done due to lack of time, or is being downgraded in priority from major or above to below major, send an email to the cldr group.
    2. If during the course of doing the ticket, the person runs up against a problem, then send a message to the cldr group. Examples:
      • The description doesn't work
      • Another mechanism looks better

Testing!

Survey Tool in Production Phase!

  1. Before you make a commit, add a line to the Issues spreadsheet below (Spreadsheet View), with status OPEN, bug number, short desc.
    • Don't do this if there is a status=PUSHING
  2. When you're ready for checking, add the commit number to your line, send a message to a designee (cc cldr-dev) and change the status to CHECK, add testing description (what to check, links if possible).
  3. Designee changes status to READY, or communicates problems back to you.
Once the statuses are all READY, anyone can push to production:
  1. Make sure the statuses are all PUSHED or READY and that the "Last Built Rev" isn't later than any items on the list
    1. If there are any untested commits, double check the timeline and make sure something isn't slipping in!
  2. Check http://unicode.org/cldr/trac/timeline?changeset=on&build=on&daysback=8 to verify that no changes "slipped in"
  3. Add a line PUSHING
  4. Push to production
  5. If there were noticeable changes, put them in http://cldr.unicode.org/index/survey-tool#TOC-Latest-Updates (move the old items up to Tool Updates).
  6. If it was a Known Bug, remove from https://sites.google.com/site/cldr/index/survey-tool/known-bugs.
  7. Change status of all READY and PUSHING items to PUSHED.
  8. You can delete some older items that are no longer relevant.
  9. If the spreadsheet data seems stale, switch to the BuildsCheckins tab, and increment the 'to update' cell. [ If anyone knows a better way to structure the spreadsheet, please feel free.. -srl]

Checkin

  1. All changes checked into SVN for the ticket use the format "cldrbug XXX: <description>", where XXX is the ticket number.
  2. Don't mark the bug as fixed! Instead,
  3. Once the ticket is done, assign a reviewer. 
    • Send a message to the reviewer if the review should be done soon.

Misticketted

If you accidentally check something in with the wrong ticket number...

  1. Add a comment to the ticket you checked in against describing the misticketted commits.
  2. Navigate to the wiki page http://unicode.org/cldr/trac/wiki/MisTicketted
  3. Click "Edit This Page" (logging in first if needed)
  4. Add your new line immediately after the first line in the page. (other example lines shown for context)

    (In the example below, revision 6658 was checked in under ticket 6636, but should have been under 4453.)
                        
    ||'''r'''||'''wrong#'''||'''right#'''||''comments''||

                         ||r6658||ticket:6636||ticket:4453||This is a comment||

                        
    ||r6657||ticket:6636||ticket:4453||
                        
    ||r6973||||ticket:4594||already fixed, just needs cache update||
  5. Click "Submit Changes"
  6. Send an email to the cldr-dev list with notification that you have changed the Misticketted page.

Reviewers

  1. On "Available Reports", click on My ReviewsOpen each of your tickets.
  2. In the top right, under View Tickets, you'll see "Review <x> commits."
  3. Click on "Review" to see the changed files. Follow the instructions at the bottom.
  4. The reviewer needs to look at the Notes and Replies in the original ticket, since they may contain changes or additions, and also sometimes alert the reviewer to changes not captured by the diff tool.
  5. The reviewer looks through the diff to make sure that the implementation matches the description. If any problems are found, the reviewer contacts the assignee, and they work together until the problems are resolved.
    1. For data tickets, the goal is to verify that the data in the ticket matches what is entered in.
  6. If any issues come up or the topic needs review, send a message to the cldr@unicode.org list.
  7. If the implementation looks good, resolve as "fixed".
  8. Change PUSHING to PUSHED

Releasers

  1. All reviewers should be done well before the end of the release, so that any problems can be taken care of.
  2. At release time, all the tickets with status "fixed" are changed to "closed".

Start of Release

  1. The future folder tickets are moved to the discuss folder
  2. Unscheduled tickets (with no release number) are re-evaluated.
Subpages (1): Design Proposals
Comments