Re: Official bug tracker?
"Martin Aspeli" <[email protected]>
| Newsgroups | gmane.comp.web.zope.plone.archetypes.devel |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 20 Jan 2006 17:57:44 -0000, Hanno Schlichting <schlichting-sG/n1OPV8/[email protected]> wrote: > While I think POI is great for small products which have a dedicated > maintainer who approves issues, I think this model doesn't suite AT well. I would personally also consider trac to be better suited for AT, especially since we already have the infrastructure in place. Let me turn the argument around: giving each and every product on plone.org/products a trac instance would be difficult, and trac would be overkill for 95% of them anyway (in my humble opinion), but since AT is such a fundamental part of our framework stack now, this level of infrastructure is warranted. The current Poi instance was created by limi as a way to get away from the sf.net tracker (which sucks so much I reckon half the people who've ever found a bug in AT has simply given up trying to report it). I'm curious why you think Poi wouldn't be useful per-se, though (mostly just as input for how we can improve Poi). I don't consider AT to have very uncommon bug tracking needs. It has a fairly stable release cycle, a single release manager, a limited number of people interested in/able to fix bugs in it, and it gets a relatively low volume of bugs in. In my personal experience, the unconfirmed/open distinction that Poi's default workflow implies is very useful in weeding out invalid or duplicate bugs. In fact, Trac does something similar with the 'new' state, as I recall (I haven't really used trac in anger, though). I think this is simply a result of the fact that someone qualified does have to make a decision on each and every bug. No bug left in the tracker will magically fix itself. In the past, the amount of noise in the Plone tracker (esp. back in the days of CMFCollector) was a major barrier for those interested in casually fixing bugs. I'd spend two hours trying to find a valid bug, and then it'd be time for bed. :) Martin -- (muted) ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642