the Alpha-Bugzilla has been closed in January 2010. The information contained in this page is now obsolete and is kept only historical reasons. See the Bugzilla archive page for information about the online archive and the AlphaTrac page for information about the new issue tracking system.
AlphaBugzilla is the bug tracking database for
It is located at http://www.maths.mq.edu.au/~steffen/Alpha/bugzilla/ and maintained by Profiles.DanielSteffen.
Alpha-Bugzilla bug reports are automatically forwarded to the AlphaTclMailingLists
From Alpha's 'README': "Alpha has a sophisticated bug reporting and tracking system. Please use it since it will help us (and you) to keep track of bugs, potential workarounds, and when they are finally fixed."
Every bug report submitted on http://www.maths.mq.edu.au/~steffen/Alpha/bugzilla/enter_bug.cgi as well as comments about the report by other users/developers and change notices about its status will be automagically forwarded to the AlphaTclMailingLists.
If you don't want to see these messages, have your e-mail system filter out mail from the AlphaTclMailingLists with From: header <email@example.com> or with Subject: starting with the string "[Alpha-Bugzilla".
Remember to reply/comment on a bug report inside Alpha-Bugzilla and not by replying to the Alpha-D message on the list, to ensure that your insights/fixes will be preserved in Alpha-Bugzilla's database for posterity.
To participate in Alpha-Bugzilla you will first need to create an account on http://www.maths.mq.edu.au/~steffen/Alpha/bugzilla/createaccount.cgi
Alpha-Bugzilla can and should also be used to file RFEs (Requests for Enhancement), there is a 'Severity: Enhancement' setting in the system for that purpose.
You can also vote on the bugs that you find most annoying in Alpha, you have 15 votes for each product (e.g. Alpha core, Alpha Tcl, AlphaTk etc). Bugs that attract a lot of votes will be sure to get the developers attention...
AlphaBugzilla is the AlphaCabal's version of Mozilla[http://www.mozilla.org/]'s Bugzilla [http://www.mozilla.org/bugs/], for more information about what Bugzilla is and what it can do, see their bug pages at http://www.mozilla.org/bugs/
This is where you'll find explanations about the meaning of all the fields of a bug report and how to set them properly when filing a new report. You should also read http://www.mozilla.org/quality/bug-writing-guidelines.html although a number of remarks on this page will obviously only apply to Mozilla and not Alpha... Of course Alpha's 'Bug Reports and Debugging' file still applies!
Tcl developers with a mode/menu/feature in Alpha should contact Profiles.DanielSteffen or another member of the AlphaCabal on the system to have their 'Editcomponents' privileges set in AlphaBugzilla.
They will then be able to add their mode/menu/feature to the 'AlphaTcl' product and set themselves as the default bug owner, so that any bug reports on their mode/menu/feature will be associated with their account and e-mailed to them directly.
There is a voting feature in Alpha-Bugzilla, but it's not really intended for voting on RFE's, but rather to add your "metoo" to an already submitted bug report. However, if people are interested, we can certainly try using this for voting on user proposals such as Donavan's keybindings.
As Jon points out, the main problem is that you can't vote 'Nay' on a proposal at the moment, so if you disagree with a request, you'll have to submit a counter proposal, (make it dependant on the bug/RFE you're disagreeing with)
I would suggest the following format for such bug reports / proposals to be voted upon: severity: "enhancement" summary: starts with "RFV:" (Request For Votes...) keyword: "votesrequested" (this will make searching for such reports easier and flag them in the database) comment: clearly detail old and new behaviour & evtl. differences to earlier proposals you are opposing.
if you have a simple Yes/No proposal, you might want to immediately add a dependent bug report for the opposite vote (i.e. things should stay as they are, don't like it ...) and use summaries like "RFVY:" & "RFVN:"
I guess we'll have to decide on a minimal number of total votes to make up a valid "referendum" (a la newsgroup creation), and as always with alpha, and esp. its core, there still won't be any guarantees that things will happen the exact way people voted...
see http://www.maths.mq.edu.au/~steffen/Alpha/bugzilla/showvotes.cgi for your votes, and http://www.maths.mq.edu.au/~steffen/Alpha/bugzilla/votehelp.html for bugzilla's help on voting.
Can Bugzillia generate a bug status report that could be appended to this file? That would be easier than checking all via bugzillia itself.
yes, Alpha-Bugzilla can do what you ask for: say you want a report on all open bugs filed on Alpha & AlphaTcl: to get nice printable html, first execute a query, in our case:
this finds 89 results at the moment, the "Long Format" button at the bottom then gives a printable HTML bug status report with full details. to get an ASCII report suitable for inclusion in a help file, either hit the "Plaintext Long Format" link on the page above or go directly to
this produces a 300k plaintext version of the full bug status report. a more restrictive query will give more reasonable sizes...
note that the plaintext URL is bookmarkable, but not the page resulting from hitting the Long Format button. Also, bookmarking/linking directly to the plaintext is faster & more efficient than querying and hitting the button or Plaintext link.
I've added a new severity "faq" (next importance level down from enhancement) and keyword "FAQ" to Alpha-Bugzilla, so that we can add & mark bug reports that are really FAQ's & preserve the answers in the DB.
BTW, reports with severity enhancement & now faq don't count as bugs in the statistics scripts and don't appear when following the 'My bugs' link in the footer.