Log in
Forgot your password?
History for BugDays
??changed:- Bug Days What is a bug day? Bug days are days when many Zope developers get together on IRC and spend a few dedicated hours fixing and resolving issues reported to the <a href="http://collector.zope.org/Zope/"> Zope issue collector</a>. The developers congregate on the #zope-dev channel on irc.zope.org. Because "free time" is scarce for developers, issues in the collector can tend to languish without some coordinated effort to keep up with them. Bug days help keep bug-fixing on the radar and provide a great lightweight opportunity for contributors to help. Because many of the Zope developers are available on IRC at the same time, issues can be resolved quickly and with less overhead than would otherwise be necessary. How can I help? If you are a <a href="http://dev.zope.org/CVS/ContributorIntroduction"> Zope contributor</a>, you can help by adopting and resolving bugs directly. But you don't have to be a committer to help. You can still adopt and fix bugs by posting patches and getting someone on IRC to commit the fix for you, or you can just help out someone else working on a bug by doing things like writing unit tests. Bug day how-to In order to make sure that bug days work smoothly, we all need to play by a common set of guidelines. These guidelines apply for day to day bug fixing as well, but are especially important when many things are happening at once: - To adopt a collector issue, you need to be a Zope.org member and have someone add you as a "supporter" to the bug collector. You can send a note to the zope-coders list if you need to be added as a collector supporter. - To keep multiple people from inadvertantly working on the same thing, you should accept a collector issue by clicking the "Followup" action and clicking the "accept" radio button. This will assign the issue to you. - Issues whose fixes are controversial in any way should not be committed without plenty of discussion. Issues whose fixes would cause any backward incompatibility should *not* be dealt with during a bug day (these require a wider discussion and the answer will usually be no, as we won't cause a backward incompatibility unless it is absolutely essential). - Whenever possible, there should be one or more unit tests to go along with any bug fix. This ensures that we'll know if the bug should reappear in the future. It is generally frowned upon to check in a bug fix without a unit test. - If you are not a committer, you should post patches to the zope-coders mailing list and get a committer on the IRC channel to help you get it checked in. - If you are a committer checking in code and tests, you are responsible for making sure the fix goes to the appropriate branches. Usually this includes the mainline and the current release branch. When in doubt, bring it up on the IRC channel. - Committers should update the doc/CHANGES.txt document to note a fix on each branch where a fix is applied. FAQ - *How do I become a contributor?* See the <a href="http://dev.zope.org/CVS/ContributorIntroduction"> Zope contributor introduction</a> on zope.org. You will also need to complete the <a href="http://dev.zope.org/CVS/Contributor.pdf"> contributor form</a>. You generally will need to have a history of contributing good patches first.