Search · Index


Filtered by popular tag bugtracker, 1 of 1 Postings (all, summary)

Bugtracker Cleanup Project

Created by Dave Bauer, last modified by Gustaf Neumann 10 May 2007, at 09:13 AM

Bugtracker Cleanup Project


Currently (Wednesday, May 9, 2007) there are 228 open bugs in OpenACS and .LRN . (Note I had to multiple 25 time the number of full pages  of bugs and tack on the last 3 on the last page the numbers next to the filters don't reflect the actual current state.) The list of bugs in the bugtracker does not reflect the reality of the release status of the toolkit. That is, the core developers and the automated tests show that OpenACS core and .LRN are pretty stable and work as expected.

There are some quite old bugs, along with suggestions, todos and more reported in the bugtracker. Its quite possible a bug was fixed without a developer noticing a reported bug in the bugtracker that should have been closed. Some bugs have become irrelevant due to changes in OpenACS since the bug was first reported.

Around OpenACS 5.1 there were even goals for number of open priority 1 bugs (0) before a release was declared final. I think it is a good goal to have the bugtracker reflect the real status of a release.

To do this we need volunteers to go through existing bugs, and check if they are still relevant, check for patches, and close the bug, fix it, or as for help in resolving a bug.

Here is a proposal for a procedure to meet this goal


  1. Test is a bug can be duplicated on the newest release of OpenACS 5.3.1 or .LRN 2.3.0. If not it should be marked not reproducable and closed. If more information is necessary that should be marked and the bug reassigned to the orginal submitter.
  2. If the bug is reproducable, and the tester does not feel they have the knowledge to fix the bug themselves, a request for assisstance should be made. At this point a more experienced volunteer will need to help out. It would be wonderful, although it is not required, if volunteers ask for help, then take this advice to learn more about the toolkit, and try to fix it themselves. This is definitely NOT required to contribute to this effort. Anyone who can try to reproduce a bug on a test server can contribute.
  3. If a decision needs to be made, whether a bug should be fixed, for core packages, the OCT should decide. For .LRN packages that are released with .LRN, the .LRN Leadship Team should decide. For other packages, it would be great if somone who uses or develops with the package will step up as maintainer and make that decision.
This is meant as a quick simple proposal to get a discussion going, and hopefully a volunteer effort organized to make the bugtracker reflect the real status of the code. Any suggestions are welcome.


Previous Month March 2017
Sun Mon Tue Wed Thu Fri Sat
26 27 28 1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 (1) 20 21 22 23 24 25
(1) 26 27 28 29 30 31 1

Popular tags

17 , 5.9.0 , 5.9.1 , ad_form , ADP , ajax , aolserver , asynchronous , bgdelivery , bootstrap , bugtracker , CentOS , COMET , CSP , CSRF , cvs , debian , emacs , fedora , FreeBSD , hstore , includelets , install , installation , installers , install-ns , javascript , libthread , linux , monitoring
No registered users in community xowiki
in last 30 minutes