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?
A quick description can be found at:
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?
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