OpenUru.org

I just notice a couple of posts in GoMa (most recently by Dot) mentioning their use of Bugzilla. I also assume but don't know that GoW is running something similar.

Has anyone thought of guidelines for designating where bugs should be filed in the new open source world?

There are obvious partitions for guild-specific activities that would go to the respective guild's bugtracking system. Not so obvious (to me anyway) is general "Uru" bugs.

The email from Chogon mentioned hosting on sites with a tracker such as Launchpad or Google Code. Should/will that be open for bugs for non-golden (i.e. Cyan vetted) code?

One reason this is interesting to me is that if the CI build engine I'm assembling finds build errors (or automated test errors) it has the ability to hook into some trackers like bugzilla and automatically file a bug sumission related to the failure.

Both Code and Launchpad have bug trackers, dunno whether they can be interop'ed with in the way you are used to however.

rarified wrote:Has anyone thought of guidelines for designating where bugs should be filed in the new open source world?

Diffrent source branches can/will maintain their own facilities as they see fit, since they will be downstream it will/should be up to them to submit to the master repo when made available.

So it will all depend on the branch you are using, and I can guess there is going to be a lot of them

You should file the bug against the current branch your using and if found its a general plasma bug that effects everything, a patch can be pushed up from that branch to patch it in the main repo's

This is all part of the VCS discussion here
http://www.mystonline.com/forums/viewtopic.php?t=16735

I'm glad this has been brought up. I am waiting for someone to ask for bug tracking here on OpenURU.org. It won't really be a hot issue until the Uru code is releaseed, and only then if anyone wants to actually do code projects here. I don't want to spend time on it prematurely, but I'd also like to be prepared.

I did a couple of preliminary looks around. Bugzilla looks like a tough install, and it's interface - at least what I saw - looks like a horrible mish-mash of disorganized information. Maybe I was looking in the wrong place, so if anyone can correct me on such ease-of-use issues about Bugzilla, please do. One issue tracker which looks like a reasonable install and has a reasonable interface is Mantis. But even that isn't done as well as some I've seen.

In any case, I'm looking for something that runs on php/MySQL, has a reasonable install, is easily maintained/upgraded, and has a well-designed UI. Any suggestions?

JWPlatt wrote:In any case, I'm looking for something that runs on php/MySQL, has a reasonable install, is easily maintained/upgraded, and has a well-designed UI. Any suggestions?

I suspect GoMa might be looking for the same...

The original intention at GoMa was to use Bugzilla for tracking bugs in fan-created ages, supporting both the GoW and GoMa's work. Unfortunately, the person championing the system needed to withdraw because of pressures of RL work, and it has since languished, unloved and unvisited by writers and maintainers alike.

We can get it going again if people will find it useful. I guess the focus for the GoMa Bugzilla would be for fan-created ages/add-ons rather than infrastructure/server code. (Forgive me if I don't use the correct terms.)

I only have experience with a few issue/bug tracking systems. But I'm no fan of Bugzilla. Also, avoid GNATS.

Perhaps someone here has familiarity with TRAC? It seems to be growing in popularity despite a release version that screams "not even beta yet!" (0.11)

This may be of help: http://en.wikipedia.org/wiki/Comparison ... ng_systems

Age writers are not developers. Age testers are not QA pros.

Go for ease of use over ANY other consideration.

Chacal wrote:Age writers are not developers. Age testers are not QA pros.

Go for ease of use over ANY other consideration.

Agreed, but are you able to suggest possible systems that might fit the bill?

Speaking as a potential Age tester, the only ticketing system I've ever used is Cyan's own for MOUL -- and that seemed straightforward to fill in for bugs or feature requests. I don't know what it was like for the poor QA people on the receiving end.

Chacal wrote:Age writers are not developers. Age testers are not QA pros.

That's a very good point. I was just contemplating that the diversity of skills and "roles" in which people might be reporting "bugs" could mean that in many cases it won't be clear to the person reporting whether the problem lies in the age, the client code, the server code, whatever, so all reports may need to be treated as if they were "System Problem Reports" until someone gets a look at the issue.

Here are some criteria for what I think will make a "user-friendly" defect tracking experience.

Ease of use will, in some part, come from how willing the person who administrates the database is willing to customize it for our needs.

Defects may need to be categorized by as wide a variety of factors as Age, Age release version, Client branch/project, Client branch/project release version, Server branch/project, and Server branch/project release version. Even if the community can manage to keep Uru mostly in "one branch," large projects are likely to fork off and then merge back in at completion because (if we're smart) we'll want to keep the "trunk" build-able and relatively defect free at all times. Before a project that has forked can be merged back into the trunk, integration testing will need to be done that could reveal defects that must be fixed before the merge can be completed. A good system should probably have multiple projects set up, with one for the "main trunk" where casual players will report bugs found in what _should_ be the stable release, and additional projects where defects can be tracked that are "must fix" before integration.

Criteria will need simple menus from which a person can select the correct answer(s). A good design is to present a few, most-likely answers first, followed with the remaining possibilities presented in alphabetical order.

So... yeah. My suggestion is to select a tool that makes setting up custom projects and fields easy to administrate. The admin should also be able to disable any default entry fields that are not applicable to our needs. If it isn't easy for the administrator, it is not going to be easy for users because nobody is going to want to admin the thing.