Forum OpenACS Q&A: How sould we setup bugtrackers for projects on the new openacs.org

1: How sould we setup bugtrackers for projects on the new openacs.org

Posted by Dave Bauer on 10/16/02 09:40 PM

Should we seperate the bugtrackers for projects hosted at the new web
site. That is currently we have an OpenACS project, a dotLRN project,
and a dotWRK project.

There are two ways to go. Set up a seperate bugtracker instance for
each project, or setup one bugracker for openacs and put the dotlrn
and dotwrk specific packages into that bugtracker.

The second option makes it easier to report a bug, there is only one
place to go. The disadvantage is that if a hypothetical new project
wanted to setup their own style and branding of the subsite, the
bugtracker would switch them back to the openacs site design.

Right now I am leaning toward making it easier to report bugs, because
the most important point of having a bugtracker is to get people to
submit bug reports.

2: Response to How sould we setup bugtrackers for projects on the new openacs.org (response to 1)

Posted by Jeff Davis on 10/16/02 09:47 PM

I think one issue is that the projects have a different release cycles
and without seperate bug trackers it will be very hard to manage that.
I think it would be easier to write some icing on top that makes
bug reporting easy than it would be to manage seperate projects in the
same bug tracker.

3: Response to How sould we setup bugtrackers for projects on the new openacs.org (response to 1)

Posted by Dave Bauer on 10/16/02 09:59 PM

Let me explain a little about bugtracker in case some of use haven't used it yet.

Bugtracker has two levels of organization. Projects and Components.
Projects are made up of several components.

So if OpenACS is a project, then all the pakcages acs-kernel, forums, news, faq, etc are components.

4: Response to How sould we setup bugtrackers for projects on the new openacs.org (response to 1)

Posted by Caroline Meeks on 10/16/02 10:02 PM

This is my personal opinion and has not been cleared with the entire Sloan team, although as far as I know no one disagrees. :)

The audience for bug tracker is developers not decision makers. The audience for .LRN/.WRK marketing should be decision makers, people with money. We want them to understand we have a tool that has been successfully used to solve problems just like theirs. They really shouldn't be all that interested in individual bugs.

It does not seem to me to be a problem if a developer working on a educational project see's the openacs brand when they goto bug tracker. In fact, I think it would be very confusing to see one header when reporting a bug in dotlrn-forums/blah and then a different header when reporting a bug in forums/blah.

Also, if we separate the bug trackers what will we do when .LRN and .WRK want to share a package but its not really general enough for OACS?

The main goal of bug tracker should be for all developers, new and old, to easily report bugs and find other people's bug reports. Thus to my mind the bug tracker should be organized more or less as a reflection of the file system as seen in a typical installation.

When you are looking an installation of dotLRN its very tough to figure out what part of the system a bug is coming from, especially for a novice. We do not want to increase that complication.

I know I do speak for Sloan when I say we want to support not divide the developer community. We want .LRN developers not only to know they are working with OACS code but be active contributors to the OACS community and code base.

5: Response to How sould we setup bugtrackers for projects on the new openacs.org (response to 1)

Posted by Caroline Meeks on 10/16/02 10:23 PM

Jeff, from what I have heard, I think we want to move away from these monolithic releases and be able to release each package separately both within OACS and .LRN. We will probably need to extend bug tracker to be able to handle that.

I also think we need to acknowledge that this is going to be a hard task..getting many developers with varying levels of experience from around the world to collaborate on bugs on a system as complex as OACS/.LRN. We need to launch with a simple system, see how it works, and make it better based on experience. Thus, I'll be happy with whatever we can launch this weekend. The new site is great, I really want to see it launch.

6: Response to How sould we setup bugtrackers for projects on the new openacs.org (response to 1)

Posted by Lars Pind on 10/24/02 11:09 AM

I think enhancing the bug-tracker so that it can do what we want all in one "project" is the way to go. How about something like this:

Each component can have its own version (that's how packages are today).

Then we introduce a concept called "release bundles" or something like that, which can also have their own independent version numbers.

So we'd create an acs-core release bundle, with version 4.7, say, which contains these components of these versions. Another bundle is the dotlrn release bundle, which could include all the acs-core components, too, if it wants to.

How does that sound?

/Lars