Differences between revisions 4 and 30 (spanning 26 versions)
Revision 4 as of 2004-06-01 16:08:57
Size: 2135
Comment: Use #python-dev; fix typo
Revision 30 as of 2006-03-31 13:11:24
Size: 4289
Editor: dslb-084-057-000-180
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. It's always time for a push at closing some Python bugs and patches.
Line 3: Line 3:
= Proposed schedule = When a new bug day is planned, announcements will be sent to the python-dev and python-list mailing lists.
Line 5: Line 5:
The bug day will be on June XXX, 2004, from 9AM to 9PM EDT (1PM to 1AM GMT). = Next bug day =

Date: Friday, March 31st 2006.

Time: roughly 9AM to 4PM Eastern (1PM to 8PM GMT) (although the IRC channel won't close at any time ;-) )

People on the US West Coast may want to show up from 9AM to 3PM Pacific time (12PM to 6PM Eastern), because it'll be more convenient.

= Location =
Line 8: Line 16:
(XXX should we use a different channel?) To learn more about IRC and to find links to IRC clients for various platforms, see http://www.irchelp.org.

= Links =

The list of bugs currently being worked on is recorded in the Wiki, on the PythonBugDayStatus page.
Line 12: Line 24:
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 27:
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 29:
XXX How do people indicate which bugs they're working on? A wiki page? A channel message?
The assigned-to field?
 - Maybe by setting the #channel title. (Not suitable, since there are multiple workers but only a single channel title)
   * Grab a copy of the Python 2.5 SVN tree. See [http://www.python.org/dev/devfaq.html#subversion-svn the development FAQ] for instructions. If anonymous access isn't working, you can download a snapshot
   from [http://svn.python.org/snapshots/python/python/ the daily snapshot directory].
   
   * If you have a problem that isn't logged on SF, announce it to the IRC channel, and if it's more than five minutes' work, 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.4.2 or 2.5 SVN? 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 SVN. 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 moved to the RFE tracker.
Line 20: Line 50:
XXX do we need to set up a web transcript of the channel? Perhaps a [http://usefulinc.com/chump/ chump bot?] = Questions? =
Line 22: Line 52:
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.
   * If someone else has supplied a fix, see if this fix works for
   you, and post your results to the bug.
   * Read the text of proposed patches and assess them for correctness and code quality.
   * 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.
If you have questions about the bug day, please add them to this section.
Line 33: Line 54:
   * Does anyone have a Win32 binary of the current svn snapshot? I'd like to help with stdlib bugs, but I don't have a compiler to build the source tree myself.
     * There is one kindly contributed by Alexander Schremmer at http://moin.pocoo.org/Python25a. Thanks!
Line 34: Line 57:
= Other processes = = Previous bug days =
Line 36: Line 59:
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 specified to the Zope project. 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 Saturday, August 7th. 19 bugs and 12 patches were closed.

The fourth bug day was held Saturday, November 7th. 12 bugs and 10 patches were closed.

The fifth bug day was held Saturday, June 25th 2005. The bug day was ill-fated, as SourceForge was down at the beginning,
the weather was hot around the world and the EuroPython conference took place on the same day. Nevertheless, 10 bugs and 7 patches were closed.

The sixth bug day was held Sunday, December 4th 2005. 11 bugs and 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 39: Line 77:

It's always time for a push at closing some Python bugs and patches.

When a new bug day is planned, announcements will be sent to the python-dev and python-list mailing lists.

Next bug day

Date: Friday, March 31st 2006.

Time: roughly 9AM to 4PM Eastern (1PM to 8PM GMT) (although the IRC channel won't close at any time ;-) )

People on the US West Coast may want to show up from 9AM to 3PM Pacific time (12PM to 6PM Eastern), because it'll be more convenient.

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

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.5 SVN tree. See [http://www.python.org/dev/devfaq.html#subversion-svn the development FAQ] for instructions. If anonymous access isn't working, you can download a snapshot from [http://svn.python.org/snapshots/python/python/ the daily snapshot directory].

  • If you have a problem that isn't logged on SF, announce it to the IRC channel, and if it's more than five minutes' work, 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.4.2 or 2.5 SVN? 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 SVN. 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 moved to the RFE tracker.

Questions?

If you have questions about the bug day, please add them to this section.

  • Does anyone have a Win32 binary of the current svn snapshot? I'd like to help with stdlib bugs, but I don't have a compiler to build the source tree myself.

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 Saturday, August 7th. 19 bugs and 12 patches were closed.

The fourth bug day was held Saturday, November 7th. 12 bugs and 10 patches were closed.

The fifth bug day was held Saturday, June 25th 2005. The bug day was ill-fated, as SourceForge was down at the beginning, the weather was hot around the world and the EuroPython conference took place on the same day. Nevertheless, 10 bugs and 7 patches were closed.

The sixth bug day was held Sunday, December 4th 2005. 11 bugs and 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].

PythonBugDay (last edited 2013-09-03 17:38:06 by EtienneRobillard)

Unable to edit the page? See the FrontPage for instructions.