OpenUru.org

We have Trac in use on our SVN servers, mostly for major doc stuff. They work great there, it allows you to browse the 'tree' in a very nice way. It's also Python-based rather than PHP, which may be a plus here. We don't do much with its bug system as that is pointing to our BMC Remedy servers.

Gnats??!? I thought/hoped that was dead... [We had TKGnats at work when I started, horrible thing. But back then, anything with a Motif interface was a winner.]

I would also vote against Bugzilla - it may be overkill (my main experience here was for FireFox actually - I was trying to get it to login correctly with M$ SharePoint Services servers, no dice [NTLM auth was not an issue, access to activeX was]). Search is not very good with BZ so that alone could disqualify it.

Jira may also be overkill/overwhelming, depending on implementation (Linden Labs' version comes to mind - that one's gotten better, but it still looks more like a forum and feature voting tool than a ticket system).

What was MOUL's system using? I removed my bookmark ages ago.

--TSK

T_S_Kimball wrote:What was MOUL's system using? I removed my bookmark ages ago.

DeskPRO v3.0.1 - more of a helpdesk ticketing system than a bug tracker, but I'm inclined to think that something like might be better as a "front end". I think some of the other posts here are tending towards the view that each development branch/repository might well need it's own "Problem Administrator" to flow reports up/down between the branch and the trunk anyway, so routing from a ticket to the bug tracker isn't such a huge step, although it does mean more work.

T_S_Kimball wrote:I would also vote against Bugzilla - it may be overkill (my main experience here was for FireFox actually - I was trying to get it to login correctly with M$ SharePoint Services servers, no dice [NTLM auth was not an issue, access to activeX was]).

Swamping into OT Territory ...

Why NTLM and not Kerberos? unless the servers where legacy NT4?

We use AD Kerberos to authenticate on other platforms (Linux/Mac) in our network for many systems such as Samba, AFP, Webservices such as Moodle and alike.

Kerberos = Open & Cool

DarK wrote:Why NTLM and not Kerberos? unless the servers where legacy NT4?

We use AD Kerberos to authenticate on other platforms (Linux/Mac) in our network for many systems such as Samba, AFP, Webservices such as Moodle and alike.

Kerberos = Open & Cool

I would venture that not many folks running simple servers have an AD service runniing. And in my case it would be "backwards" since my authentication authority is in the Unix/Solaris domain and Windows servers inherit it. AD would lock me into windows' paradigm, even though it is using a M$ extension of Kerberos (which != real MIT Kerberos).

Enough flaming about platforms.

The original responder was just concerned about how to run the tracker in their environment. We'll have to either solicit information about the environments that want to run branch-specific trackers to come up with a common denominator tracker recommendation, or just put together a list with pros and cons.

[edited to elaborate on original concern]

Yes, please, rarified! A list of suggestions with pros and cons would be very helpful.

From Marten's Wiki link, Redmine looks potentially interesting. Has anyone any experience with it?

Like the way people only read what they want to ...

I mentioned that I was wandering off topic
Mentioned that I use AD Kerberos, as I am locked into a windows' paradigm by our service providers
Whether a MIT or AD implimentation it is still Kerberos and has to conform to certain standards (FYI AD Kerberos conforms and interops with MIT Krb)

I was only intrested to learn why ... and if there was a reason for it as so to understand more.

Perhaps next time I will PM, so the whole world can't learn from my question

Mod note: So OK, here endeth the OT discussion
Any further debate on cross-platform authentication, etc. should be taken elsewhere.

Now, back to bugtracking/ticketing systems...

Yes, please, the goal here at OpenURU.org is to find and provide as a resource "something that runs on php/MySQL, has a reasonable install, is easily maintained/upgraded, and has a well-designed UI." Let's stick to that.

There is, however, some defensive posturing which has been learned from intolerant reactions on other forums. I'd like to leave some room for people to understand they can relax here and unlearn the conditioned responses. It is therefore incumbent on them as well to not respond to challenges in anger, but to give people a chance to do what they came to do.

My apologies, DarK. Old scars are sometimes hard not to scratch.

Dot wrote:Yes, please, rarified! A list of suggestions with pros and cons would be very helpful.

Unfortunately, my experience has always been with in-house (custom) trackers, not OSS ones. I can go through ones that Hudson (the CI engine I'm using) has plugins for and give a first hand impression, but that's all it would be. Not real life experience. I also need to look at Marten's link.

Akin to rarified's position, my experience has been with either in-house or heavyweight "enterprise" solutions for bug tracking and VCS. Our environment is quite "tight" in that projects are very much self contained and don't really spawn multiple development branches. You may have something that's a derivative of a previous product but they almost never merge back, so problem reports rarely have to flow up/down, and if they do it will be across the boundaries of project responsibilities, so lots of manual intervention (and paperwork ) And just don't get me started on SAP .

Bottom line is I've used a few tools but they're not worth offering up here either because of cost, complexity, inappropriateness, or complete lack of knowledge about whether they'd be usable within the OS "model". On the other hand, I'm sure I could find my way round just about anything that was made available.

In any case, ease of use, especialy an intuitive UI, has to be a major decision factor: If it's clumsy to use, people won't use it unless they feel they really need to, which means that a lot of useful feedback gets lost.