[OPEN-ILS-DEV] ***SPAM*** Re: 1.6RC1 - Acquistions - possible bugs

[Joe Atzberger]

On Fri, Sep 18, 2009 at 10:16 AM, Mike Rylander <mrylander at gmail.com> wrote:

> On Fri, Sep 18, 2009 at 10:12 AM, Wills,Steve <wills at nelinet.net> wrote:
> > Having a roadmap, version controlled source repository, and bug
> > tracking/testing that are available to a volunteer community are all key
> > components in successful OS, imho.
> >
> > This list has mentioned Bugzilla and Trac many time.  Is there a general
> > preference?  My suggestion, when picking a tracking system is to suspend
> > disbelief that it will be used and pick it on merit.  How to manage
> > managing the managers is a separate issue from who to manage the bugs.
> > Again, in my opinion.
>
>
> On that score, I think trac has the lead over bugzilla for a couple
> reasons:
>
> * it's already set up
> * it's simpler
> * it sits right on top of the authoritative source repo
> * it's much MUCH easier to hack on if we need it to do more than the
> stock version
>


I boil that down to mostly inertia.  Inertia is real, so I'm not discounting
that, but I still would want to discuss the two ticket systems head to head,
as ticket systems.

TICKETS:  Since you asked, Steve, for a fresh project, I'd take Bugzilla
over Trac.  Installation is not a major hurdle, performance and featureset
are better (for ticket tracking).  Bugzilla remembers your last search
results, allows you to save arbitrarily complex searches (independent of
results), and allows you to step through any set of hits linearly, among
other things.  Say you view the third bug in a list of 38, then you might
get a little navbar like:
*
**Bug List:* (3 of 38) * First*  *Last*  *Prev*  *Next*  *Show last search
results*

The workflow is very clean and you can touch related bugs more quickly.
Example search on Mozilla's
Bugzilla<https://bugzilla.mozilla.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&content=winamp>
.

Another desirable feature is the explicit depends/blocks notation.  When you
need another bug fixed before yours can proceed, you just add the ID.  Then
you can visualize a nest of dependencies with built-in graphs.

As far as configuration goes, we need to be doing some more even if we stay
w/ Trac (see discussion of version numbers, head/trunk version, milestones,
etc.).  Also, whatever configuration problem our Trac currently has that
causes it to stall for a full minute on ticket creation or update would be
nice to resolve or escape.  Now that I'm filing a bunch of tickets, it's
particularly noticeable.  You can attach a large file nearly
instantaneously, so it's not bandwidth, but adding a new 2 line ticket
(succeeds, but) nearly times out.

More broadly, I don't think we have to marry the ticket system to the repo
viewer (or viewers!), or to any wiki system.  Trac's source viewer is OK,
but not unique functionality.  There are dozens of SVN/repo web-viewers.
For example, one major shortcoming, I can search our Contrib repo for "DBI"
and get no hits:
http://svn.open-ils.org/trac/ILS-Contrib/search?q=DBI&wiki=on&changeset=on&ticket=on

Because I'm not actually searching the codebase.  I don't even get the
option to search the codebase.  That kind of thing is pretty useful for a
viewing layer, because meanwhile grep -r DBI gives me 30 hits, including
files like:
http://svn.open-ils.org/trac/ILS-Contrib/browser/grpl/trunk/patron_notifications/make_holdshelf_callfiles.plx

Trac's wiki is standard, even a little weak (no pun!).  We use a separate
docuwiki for most EG wiki content, and it allows us to do things like
subscribe to changes (or page changes).  The TracWiki featureset seems
dated, and I feel like other wikis are evolving more quickly than trac's
version will be able to match.  So overall I don't see that we benefit from
coupling a source viewer and a secondary wiki directly to the ticket
system.

As for simplicity/hacking, Bugzilla is far less likely to *require* us to
hack it.  That is more desirable, since it allows us to stay inline with
updates, rather than worrying about custom hacks breaking.  And in any case,
Bugzilla supports both code hooks and template hooks, so I doubt any
customizability is missing.

Anyway, that's my preference...  and I agree that how we use the system is
always more important than what system it is.
--joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20090918/5b05ec56/attachment.htm