Tracker discussion

[wrtlprnft]

Forums and wiki pages are bigger, but they offer more real content, plus they seem to load faster

I don't see flyspray doing any AJAX, actually, at least none that's visible on a glance. I just see that the advanced search markup is contained in every page that shows the search box, even though it'll only be used very rarely compared to page loads.
As soon as you change the sort key or something similar it's completely reloaded.

Anyways, I was mostly comparing it to track, which is notably smaller in file size

[Z-Man]

Add to my trac rant: spam. No way to delete tickets when they are spam. What a pain.

Just for demonstration purposes, I got rid of your toilet paper bug report in my installation
http://master1.armagetronad.net/aatrac/ ... &ticket=on

Code: Select all

trac-admin <path> ticket remove <number>

helps.

Yeah, the apache log is the only place critical errors can be logged sometimes. Sometimes, they make it into the web page.

I installed the Gannt Chart plugin on my trac. Turns out it's of very little practical use. It doesn't help you manage dependencies, it only helps you check your plan; it makes sure that if A depends on B, then A's due date needs to come before B's due date. Then it displays the stuff in a disproportional calendar. A problem with Trac here is that it does not have enough datatypes for custom fields, so the dependencies and due dates are just text fields with no error checking at input time; that's only done when a chart is rendered (a problem with the plugin; on-commit-checks are possible, at least that's what the time tracking plugin does). Check it out yourself:
http://master1.armagetronad.net/aatrac/gantt/3

Also, by now my Trac installation has way too many plugins The navigation bar is crowded, and two of them, the Gannt thing and the time tracking plugin, require additional custom fields, so gone is the simplicity. For pure issue tracking, flyspray is clearly better than Trac, and also better than the other things we've been looking at.

[Lucifer]

Heh. Add to my trac rant "A lot of things require running a shell command."

So, I guess it's boiling down to the question of how much junk we want our tracker to do. Do we want it to just track issues, and only track issues? If yes, looks like flyspray's the winner. If no, flyspray is clearly the loser, and it looks like trac wins, or we keep looking.

My personal opinion is that the tracker should just track issues and related stuff, i.e. todo's, release planning, maybe some minor things I haven't thought of that don't deviate from the issue concept terribly. The reason is because we're already going to specialized apps to do things, and for the most part that means we're wanting each app to do one thing and do it really well.

For hosting, I'm going to look at flyspray's auth mechanisms. If I can get it to use the wiki user table, then it looks like I should host it (assuming it's a decision made, obviously there's room for more discussion, but it looks like we're getting close) for now. Someone whack me with a bat if I go to bed without giving tank the user account he asked for, because he was going to try to get the wiki and the forums using the same user table. Anyway, the obvious concern here is having yet another login for the tracker.

[Z-Man]

I think I already said that a while back: Integration of forum, tracker and wiki into one thing definitely is not required. For cross-references, regular links work fine. From my view, Trac's wiki is sufficient; but the forum clearly is not, so we're only getting half of the total possible integration.

That is, as long as we get all three to use the same user database. Then again, Tracs user management still is horrible and I'd rather have three different logins than one trac login.

A danger with using the tracker to track too much stuff is the custom field explosion. Without a possibility to have fields that only appear on certain types of issues/tickets, the user is flooded with them. We shouldn't go overboard with what we track.

If I was to decide now, I'd pick flyspray and migrate completely once the user database stuff is sorted out. The extra goodies with xml-rpc and the buildbot can wait, I see little reason why they should be easier with any other tracker (except the anonymous submissions which we get for free with Trac, but with the spam problem), and we don't have them now with the SF tracker, so their absence shouldn't stop us.

[Lucifer]

Right, right, right. I was musing. I don't think user database integration should be a blocker either, even though we technically pick up another login when we move from sourceforge with the tracker. That was more musing. For tracking issue-related stuff, I was thinking stuff that uses all the same fields is what's useful. I.e. if a field isn't generally useful but is specific to a task, then we do without if we want to track that task with the tracker. For the reasons you give, I'd call it field creep. So I was thinking it's to be used for things you want to track with or without a date due, percentage completion, and the user auditing stuff, which is what an issue boils down to. Once someone wants to track something that falls out of that scope, they need something else (like an inventory tracker.... ).

Why don't we sit on it a week, let you do your seminar and whatever else you've got to do, and then decide? I'm wanting to spend more time with my trac installation now that it's working again and apparently running faster. So I might find I like trac better now that it's been upgraded to something.

[Lucifer]

Ok, throw performance back onto my track rant. Ever since I fixed my trac installation, performance on the machine has been seriously degraded. My alarm clock pages always got a fairly predictable amount of traffic... I don't know for a *fact* that it's trac, though. I originally suspected a spam attack and checked, no wiki spam, no spam on my personal site. That doesn't leave much. And now the trac site is loading very slowly again.

(That's a complaint of the twisted guy, that if apache's not restarted regularly, trac really degrades performance. So I guess I can substantiate that, at least)

Edit: FIrst thing on my list tomorrow is going to have to be getting rid of the trac installation. I shouldn't have fixed it. (Again, I still don't have what you'd call proof on this, but I have a very strong gut feeling, and I'm only going to be able to infer it was trac after I've removed the trac installation and if doing so relieves the performance problem, but really, waiting 5 minutes for my wife to login was about 4.5 minutes beyond reasonable)

[Lucifer]

Haha, have we even talked about roundup?

http://roundup.sourceforge.net/

Guido Van Rossum recommends it.

http://www.artima.com/weblogs/viewpost. ... ead=143947

[Z-Man]

There is such a thing as too much evaluation. Seems to me we're doing little else these days. So if you set one of those things up, sure, I'll test it, but Flyspray already is very close to the optimal tracker and I'm happy with it.

[Lucifer]

Have we sat on it long enough? (If you couldn't tell, I agreed with your last post, hence no roundup installation appeared)

[Z-Man]

Yes, I'd say so.

[Z-Man]

Hey, since when can you add bug reports without registering? The only thing I found missing there is that the user can't add a comment to his own report later, all follow up communication needs to go over email. Neat, though: the address of the submitter is only shown to registered users. Well, at least, it's shown to me.

[Lucifer]

How do you want it to behave? I figured taking the bug report without contact information was better than not getting it at all. Anyway, I made you a project manager, so see what you can do to admin it. (Also, deleting spurious projects from testing)

Can we get someone to make a nice theme for this?

Edit: Oh yeah. Who wants to migrate the old tracker? What we should really get is a script that takes the xml export from the tracker and turns it into new records in flyspray....