|
Size: 1970
Comment:
|
Size: 3364
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| The release of Python 2.4alpha1 is currently scheduled for around July 1st. An organized effort to go through the bug database and close irrelevant bugs or apply fixes would be very useful. | The release of Python 2.4 is scheduled for autumn 2004. An organized effort to go through the bug database and close irrelevant bugs or apply fixes would be very useful. |
| Line 3: | Line 3: |
| = Proposed schedule = | = Location = |
| Line 5: | Line 5: |
| The bug day will be on June XXX, 2004, from 9AM to 9PM EDT. (XXX need to convert to GMT.) | Participants will convene in the #python-dev IRC channel on irc.freenode.net. To learn more about IRC and to find links to IRC clients for various platforms, see http://www.irchelp.org. |
| Line 7: | Line 8: |
| Participants will convene in the #python IRC channel on irc.freenode.net. (XXX should we use a different channel?) |
= Links = Transcripts of the #python-dev channel are being recorded at http://www.amk.ca/python/bugday/. The list of bugs currently being worked on is recorded in the Wiki, on the PythonBugDayStatus page. |
| Line 12: | Line 16: |
| The goal of the bug day is to process bug reports in [http://sourceforge.net/tracker/?group_id=5470&atid=105470 the Python bug tracker] on SourceForge, providing additional information so that the bug can be fixed and closed. | |
| Line 14: | Line 19: |
| Someone with write access to the bug database needs to be around at all times. Having people around with CVS write access would be nice so that fixes can get checked in,but is not necessary; the primary purpose is to improve bug reports, and if the fixes are applied later, that's fine. | What to do: |
| Line 16: | Line 21: |
| XXX How do people indicate which bugs they're working on? A wiki page? A channel message? The assigned-to field? XXX do we need to set up a web transcript of the channel? What to do: * If a problem isn't logged on SF, log it. * If it's logged, consider providing a patch that fixes the problem, or at least a simple test case that demonstrates the bug. |
* Grab a copy of the Python 2.4 CVS tree. See [http://sourceforge.net/cvs/?group_id=5470 SourceForge] for instructions. If anonymous CVS isn't working, you can download [http://cvs.perl.org/snapshots/python/python/python-latest.tar.gz a tarball of CVS HEAD] from [http://cvs.perl.org/snapshots/python/python/ the daily snapshot directory]. * If a problem isn't logged on SF, create a bug report for it. See the [http://docs.python.org/lib/reporting-bugs.html bug reporting instructions] to learn how to write bug reports. * When you choose a bug to work on, announce it to the IRC channel. (e.g. "I'm working on #123456.") * Consider providing a patch that fixes the problem, or at least a simple test case that demonstrates the bug. Does the bug appear to be gone in Python 2.3.4 or 2.4 CVS? Report that, too. |
| Line 26: | Line 34: |
| you, and post your results to the bug. | you, and add your results to the bug. |
| Line 28: | Line 36: |
| This is usually the most time-consuming step in the bug fixing process, so reading patches is very useful. |
|
| Line 29: | Line 39: |
| the fix to go into CVS. The SF bug tracker for Python has a _lot_ of bugs in it, and it's easy for bugs to be overlooked. |
the fix to go into CVS. The SF bug tracker for Python has a lot of bugs in it, and it's easy for bugs to be overlooked. * Feature requests can be added to the text of [http://www.python.org/peps/pep-0042.html PEP 42] or recorded in the RFE tracker. The bug can then be closed. |
| Line 33: | Line 44: |
| = Other processes = | = Questions? = |
| Line 35: | Line 46: |
| The [http://dev.zope.org/CVS/BugDays Zope bug day] has a goood description of what to do, though the details of the bug tracker are specified to the Zope project. | If you have questions about the bug day, please add them to this section. = Previous bug days = The first bug day was held Saturday, June 5, 2004, from 9AM to 6PM EDT, ending early because SourceForge CVS stopped working. 30 bugs were closed, and 14 more bugs had enough work done to make them closable. The second bug day was held July 10 2004. 18 bugs and 21 patches were closed. The third bug day was on Saturday, August 7th. 19 bugs and 12 patches were closed. = Bug days for other projects = The [http://dev.zope.org/CVS/BugDays Zope bug day] has a good description of what to do, though the details of the bug tracker are specific to the Zope project. |
| Line 38: | Line 63: |
The release of Python 2.4 is scheduled for autumn 2004. An organized effort to go through the bug database and close irrelevant bugs or apply fixes would be very useful.
Location
Participants will convene in the #python-dev IRC channel on irc.freenode.net. To learn more about IRC and to find links to IRC clients for various platforms, see http://www.irchelp.org.
Links
Transcripts of the #python-dev channel are being recorded at http://www.amk.ca/python/bugday/.
The list of bugs currently being worked on is recorded in the Wiki, on the PythonBugDayStatus page.
Procedures
The goal of the bug day is to process bug reports in [http://sourceforge.net/tracker/?group_id=5470&atid=105470 the Python bug tracker] on SourceForge, providing additional information so that the bug can be fixed and closed. Bugs should be processed in the fashion described by [http://www.python.org/peps/pep-0003.html PEP 3].
What to do:
Grab a copy of the Python 2.4 CVS tree. See [http://sourceforge.net/cvs/?group_id=5470 SourceForge] for instructions. If anonymous CVS isn't working, you can download [http://cvs.perl.org/snapshots/python/python/python-latest.tar.gz a tarball of CVS HEAD] from [http://cvs.perl.org/snapshots/python/python/ the daily snapshot directory].
- If a problem isn't logged on SF, create a bug report for it. See the
[http://docs.python.org/lib/reporting-bugs.html bug reporting instructions] to learn how to write bug reports.
- When you choose a bug to work on, announce it to the IRC channel. (e.g. "I'm working on #123456.")
- Consider providing a patch that fixes the problem, or at least a simple test case that demonstrates the bug. Does the bug appear to be gone in Python 2.3.4 or 2.4 CVS? Report that, too.
- If someone else has supplied a fix, see if this fix works for you, and add your results to the bug.
- Read the text of proposed patches and assess them for correctness and code quality. This is usually the most time-consuming step in the bug fixing process, so reading patches is very useful.
- If there's a working fix, feel free to add a note asking for the fix to go into CVS. The SF bug tracker for Python has a lot of bugs in it, and it's easy for bugs to be overlooked.
Feature requests can be added to the text of [http://www.python.org/peps/pep-0042.html PEP 42] or recorded in the RFE tracker. The bug can then be closed.
Questions?
If you have questions about the bug day, please add them to this section.
Previous bug days
The first bug day was held Saturday, June 5, 2004, from 9AM to 6PM EDT, ending early because SourceForge CVS stopped working. 30 bugs were closed, and 14 more bugs had enough work done to make them closable.
The second bug day was held July 10 2004. 18 bugs and 21 patches were closed.
The third bug day was on Saturday, August 7th. 19 bugs and 12 patches were closed.
Bug days for other projects
The [http://dev.zope.org/CVS/BugDays Zope bug day] has a good description of what to do, though the details of the bug tracker are specific to the Zope project.
The GNOME community holds regular Bug Days; the procedures are described in [http://developer.gnome.org/projects/bugsquad/triage/faq.html their FAQ].