pear:qa:bug_triage

Bug Triage Day

Welcome to Bug Triage Day.

When is it?

You can check the Google Calendar for the latest time

The next will be 2009-03-21

The last one was 2009-02-07

Who's running it?

What is it?

Patches for unmaintained packages

What's the policy for this bug-triage? I've provided some patches for some packages earlier (one month or so) and still no answer from developers, may I commit 'em now and close thoses bugs?

The answer to this is TBA. It's probably worthwhile to get a second developer to review & test them, then get someone else (like Helgi) to say if its OK or not.

QA can work on unmaintained packages without delay:

 <@radagast> cweiske: your opinion for http://wiki.pear.php.net/index.php/Bug_Triage_Day#Patches_for_unmaintained_packages would be appreciated ;-)
 <@cweiske> radagast, normal qa stuff
 <@cweiske> http://pear.php.net/pepr/pepr-proposal-show.php?id=60
 <@cweiske> QA rights/responsibilities:
 <@cweiske> Fixing bugs/making releases
 <@cweiske> If any QA related issues are found in a package that QA has not been granted permission to change without consulting the maintainer,the QA team will file a bug report. If the issue remains
                 unresolved for 1 month (2+1+1 weeks; see below), QA may fix it themselves.
 <@radagast> I thought that was assuming the package was maintained and that the process might be quicker for unmaintained packages as that expressly implies that there is no maintainer to consult
                  with.
 <@cweiske> oh, unmaintained
 <@cweiske> for unmaintained, qa can go full steam immediately
 <@radagast> heh. that's good to know.
 <@radagast> I'll update that section on the wiki

If you are helping out on a Triage day and aren't QA, then please simply email the qa list mailto:pear-qa@lists.php.net asking that somebody look at the patch you submitted and take action.

Process

Pick your package, and look for existing open bugs.

The basic steps are below but remember, creating patches and fixes or tests are not a requirement:

  • Choose a Bug
  • Reproduce / Verify it
  • See if there are existing unit tests for it
  • Write a unit test to demonstrate the bug
  • Make changes to the code to fix the bug
  • Create a patch
  • Repeat

Getting access to CVS

Don't know how to get CVS code?

Read http://www.php.net/anoncvs.php

Windows users

For windows users, grab a a copy of the binary, unzip it into your path, and we're off.

Bring up a command line (Start -> Run -> cmd), and check you've done it right by typing

cvs

.

Next, you want to make somewhere to checkout to:

G:\work>md pear
G:\work>cd pear

G:\work\pear>cvs -d :pserver:cvsread:@cvs.php.net:/repository login
Logging in to :pserver:cvsread@cvs.php.net:2401/repository

G:\work\pear>cvs -d :pserver:cvsread:@cvs.php.net:/repository checkout pear
cvs checkout: Updating pear
U pear/AllTests.php

Making patches

Patches are easy!

To see all modifications; use:

cvs diff -u

To see just a certain file, use:

cvs diff -u Foo.php

and to make a patch

cvs diff -u Foo.php > bug-12345.diff.txt

Previous Triage Days

pear/qa/bug_triage.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1