[OPEN-ILS-DEV] Bug tracking (was: 1.6RC1 - Acquistions - possible bugs)

[Dan Scott]

On Fri, 2009-09-18 at 09:12 -0500, Wills,Steve 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.

The list of current SVN repositories and bug tracking systems are
visible at http://svn.open-ils.org/trac/ (aside: Woodchip can probably
be pulled from the list as a project that is no longer active).

The ability to manage tickets in the core Evergreen (ILS) and OpenSRF
(OpenSRF) Trac instances is currently limited to the core developers
which includes myself (a volunteer), and read access is available to
everyone. 

I was proposing opening up the ability to manage tickets to a broader
group of volunteers, ideally people working closely with the core
developers and already comfortable installing & testing Evergreen. The
trick is in balancing the task of opening things up without increasing
the overhaed on a relatively small set of developers.

We have been somewhat negligent about entering bugs/enhancements as
ticks in the Trac repository, probably because we've been a bit more
focused on the code rather than the broader benefits of tying commits to
specific tickets. 

> 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.

The old Bugzilla instance was a mess, and out of the box Bugzilla has an
interface from hell. Trac makes it easy to tie commits to specific
issues. With some of the distributed development going on (for example,
Scott modifying database schema & Bill modifying Perl modules and Jason
modifying XUL interface for enhancements to circulation of non-cat
items), it would be nice to have as part of the commit message "Working
towards #77" (assuming 77 is the number of the pertinent ticket) because
that automatically generates a link from the timeline of commits to the
corresponding ticket; when the feature is finished, the ticket can be
closed and we'll know that in the next release that feature has been
added. 

Rather than trying to piece together the story from individual commit
messages, it would be a bit easier for other developers to figure out
what's going on and (as Karen suggested) probably easier for the DIGgers
to pull together release notes or early drafts of documentation if
there's an outline of what a given ticket is addressing.

Roadmaps are tricky because they change. Natural disasters occur, roads
need to be widened or paved, detours get put in place, patches fall from
the skies that teleport you way ahead of where you expected to be...
(one can dream!) That said, Trac does include roadmaps (a list of
tickets tied to specific releases). Again, though, we've been less than
diligent about keeping those up to date - see
http://svn.open-ils.org/trac/OpenSRF/roadmap for a bit of a laugh (given
that OpenSRF 1.0.6 was released in March). This is the sort of thing
that I think a QA/testing team with the ability to manage the Trac
instances to could help with.

A lot of this is about enhancing communication: developer-to-developer;
developer/QA/tester/writers (development team? project contributors? ah
naming); users/development team, and probably other audiences. 

Again, though, the trick is finding the right balance of meeting the
needs of the project without bogging the process down in the production
of artifacts that don't add value. If every commit message was tied to a
ticket with three pages of description, which fell into a roadmap with
precisely adjusted dates, with perfectly synchronized code styles and
unit tests for every method, but the resulting process encumbered the
developers so much that we were only able to make half as much progress
towards the development of new features, would that be a desirable
outcome?