[Tracker-discuss] Creating a Jython tracker
Stephen J. Turnbull
turnbull at sk.tsukuba.ac.jp
Tue Feb 5 01:59:31 CET 2008
Frank Wierzbicki writes:
> But it is thin on reasons for not going with Trac. Does anyone
> remember the particular problems with Trac? I don't want to stir
> anything up, just looking for some data to use in our decision.
I wasn't party to the decision at Python, but I do use Trac on a
weekly or so basis for MacPorts. The MacPorts tracker was horrible,
and it's still not good. I append a bug report I submitted against
their Trac tracker and the reply. Or you can find the original and
some additional discussion at
Ticket URL: <http://trac.macosforge.org/projects/macports/ticket/11376>
A few comments: "jmpp" pretty clearly didn't understand what I was
getting at with #6. The problem is that if you submit just a port
name, you get every ticket that mentions the port, including several
dozen where a user dumped their entire list of packages into the bug
report, and all svn commits that touch a file in that port! I've
never seen one return less than 100 tickets.
This was partly alleviated when they added a standard query for "all
tickets submitted by me", but that encourages submitting a new query
and then waiting for a MacPorts staffer to cross-reference to another
ticket where the problem is discussed in depth. (A technique that has
served me well twice, I'm ashamed to admit.)
I get the feeling that a lot of this is problems in Trac itself, or at
least in the default configuration, as only the easy ones were really
solved.
>From the MacPorts staffer's reply, it appears that a lot of the
customization of Trac has to be done offline, and may require a reload
of the database or something icky like that.
With Roundup, almost everything I asked for can be done online if you
have admin permissions. New keywords, retiring keywords, adding
priorities, changing the sort order of priorities, etc. And users can
store their own queries. And the database schema can be changed on
the fly, since it's object oriented. Old objects won't forget their
properties (although the UI may not display them any more), and
nothing crashes if an old object doesn't have newly defined properties
accessed by the UI: they just show up as undefined. This makes it
really easy to make small frequent improvements in the user
experience.
The Roundup UI is easy to adapt, too (you do need access to the
tracker's HTML templates and a server restart). You'll note complaint
#3 about 1200px wide windows, which still have not been fixed as of
last Friday. I had a problem in my Roundup tracker where a popup
window was a tiny bit too narrow (on Firefox/Mac, when the scrollbar
appears, the usable area gets smaller), and a nice row of 3 buttons
became two rows. Ugly. All I needed to do was find the appropriate
template, and change the window's width attribute from 600 to 625, and
restart the server. While I've not administered a Trac myself, the
exchange attached below suggests that it's not very adaptable.
You'll also see three subissues about help, again, still not
addressed. In Roundup, it was simply a matter of changing the "Doc"
anchor to "Vendor docs" (so people would know these were not suppose
to apply specifically to our tracker, and than links to a revised
version of the user guide specific to our config, our bug reporting
guidelines, and our debugging advice. It's still not as good as I
would like, but I no longer feel like I'm just begging for a user and
developer revolt. Trac seems to make this kind of gradual improvement
hard, though.
Oh, and here's my in progress tracker (which includes several
improvements I learned about from Python's tracker, all remaining
infelicities the responsibility of yours truly, of course):
http://tracker.xemacs.org/XEmacs/its/
----------------------------------------------------------------
Sender: trac at macosforge.org
Message-ID: <057.908c181aa25b03008c0587a78dbb4a16 at macosforge.org>
From: "MacPorts" <trac at macosforge.org>
To: stephen at xemacs.org, jmpp at macports.org
Cc: macports-tickets at lists.macosforge.org
Subject: Re: [MacPorts] #11376: Tracker discourages use
Date: Tue, 18 Dec 2007 18:36:00 -0000
#11376: Tracker discourages use
---------------------------------+------------------------------------------
Reporter: stephen at xemacs.org | Owner: jmpp at macports.org
Type: defect | Status: new
Priority: Normal | Milestone:
Component: infrastructure | Version:
Resolution: | Keywords:
---------------------------------+------------------------------------------
Old description:
> Trac may be wonderful, but what I wonder is how regular users can stand
> it!
>
> 1. Trac forgets my login when following most links. I'm not really sure
> what's going on here, because it doesn't always do this. For example, if
> I enter "http://www.macports.org/", then go there, it remembers earlier
> logins in the current browser sessin, and if there is no login session,
> the password memory makes logging in easy. Both facilities fail when I
> follow links into the tracker. Maybe it's that trac doesn't live at
> www.macports.org, but at trac.macports.org, and my browser doesn't send
> the cookie.
>
> 2. ''All'' trac pages should have a New Bug button.
>
> 3. Many displays assume I have space for a 1200 pixel width window. (a)
> I don't on several of my workstations (subnotebooks), and (b) I am not a
> fan of letting any application take over my entire screen, especially not
> one subject to network delays.
>
> 4. This wouldn't be so bad (the wide display does contain a lot of
> information, and it's quite useful to keep it on one line), except that a
> lot of useful controls are right-justified and end up off-screen (login,
> search).
>
> 5. There's no easy way to search for bugs against a single port.
>
> 6. The custom query as initialized looks for bugs assigned to me. Make
> that a standard query, for heaven's sake. The custom query is the only
> available workaround for #5, so you're encouraging users to enter
> duplicate bugs by making it annoying to search for existing bugs. The
> custom query should be initialized to search the summary.
>
> 7. Ticket properties are insane. Yes, I've come to "expect" MacPorts to
> throw at least one reportable bug a week, not to mention frequent minor
> annoyances, but what does "Priority: expected" mean in terms of getting
> things ''fixed''?
>
> Version: Most bugs have nothing to do with the version of "port", and
> everything to do with the portfile. Furthermore, there doesn't seem to
> be a way to express the fact that you're tracking base by subversion,
> which is where you'd expect the most "port" bugs to show up.
>
> Component: is trac "www" or "infrastructure"? Does "Uninstaller" really
> need its own component?
>
> Severity: hardly seems the right way to describe an enum of "Crash/data
> loss", "Serious", "Security", "Performance", "Other".
>
> Keywords: What keywords are acceptable?
>
> 8. Help isn't very visible.
>
> 9. Help doesn't describe this tracker in any detail.
>
> 10. Help doesn't describe this tracker accurately (it implies that
> Priority/Severity should not be separate properties).
New description:
Trac may be wonderful, but what I wonder is how regular users can stand
it!
1. Trac forgets my login when following most links. I'm not really sure
what's going on here, because it doesn't always do this. For example, if
I enter "http://www.macports.org/", then go there, it remembers earlier
logins in the current browser sessin, and if there is no login session,
the password memory makes logging in easy. Both facilities fail when I
follow links into the tracker. Maybe it's that trac doesn't live at
www.macports.org, but at trac.macports.org, and my browser doesn't send
the cookie.
2. ~~''All'' trac pages should have a New Bug button.~~
3. Many displays assume I have space for a 1200 pixel width window. (a) I
don't on several of my workstations (subnotebooks), and (b) I am not a fan
of letting any application take over my entire screen, especially not one
subject to network delays.
4. This wouldn't be so bad (the wide display does contain a lot of
information, and it's quite useful to keep it on one line), except that a
lot of useful controls are right-justified and end up off-screen (login,
search).
5. There's no easy way to search for bugs against a single port.
6. ~~The custom query as initialized looks for bugs assigned to me. Make
that a standard query, for heaven's sake. The custom query is the only
available workaround for #5, so you're encouraging users to enter
duplicate bugs by making it annoying to search for existing bugs. The
custom query should be initialized to search the summary.~~
7. ~~Ticket properties are insane. Yes, I've come to "expect" MacPorts to
throw at least one reportable bug a week, not to mention frequent minor
annoyances, but what does "Priority: expected" mean in terms of getting
things ''fixed''?~~
~~Version: Most bugs have nothing to do with the version of "port", and
everything to do with the portfile. Furthermore, there doesn't seem to be
a way to express the fact that you're tracking base by subversion, which
is where you'd expect the most "port" bugs to show up.~~
~~Component: is trac "www" or "infrastructure"? Does "Uninstaller" really
need its own component?~~
~~Severity: hardly seems the right way to describe an enum of "Crash/data
loss", "Serious", "Security", "Performance", "Other".~~
~~Keywords: What keywords are acceptable?~~
8. Help isn't very visible.
9. ~~Help doesn't describe this tracker in any detail.~~
10. ~~Help doesn't describe this tracker accurately (it implies that
Priority/Severity should not be separate properties).~~
Comment (by jmpp at macports.org):
It should be noted that this ticket spans multiple issues and the
preferred way to report them is one issue per ticket. Nevertheless, since
discussion already happened on this ticket, I'm going to comment on each
of the points raised and will cross them out of the original description
if already fixed:
1. This is a Mac OS Forge issue related to virtual hostnames, if I'm not
mistaken, and there's nothing the MacPorts team can do about it. I don't
think it's fixed, as I've personally seen jumps from http based URLs to
https ones, from trac.macports.org based URLs to trac.macosforge.org ones,
and even from and to svn.macports.org URLs (with the /projects/macports
path). Tickets #10665 and #13428 are presumably related to this issue.
2. This is fixed, crossed out from the original description.
3. See 4 below.
4. I'd love it if our Trac portal could be unified into the look of our
new website, but I'm not too sure this is possible. Mac OS Forge personnel
has to get back to us on this one, but I'd think they still have more
pressing matters to attend to so this might be a low priority issue.
5. If you could provide the SQL glue to build up per port queries I'd
happily set them up at the
[http://trac.macports.org/projects/macports/query query] page. Maybe the
TracReports page might come in handy for this.
6. You mean to make the query that searches for tickets assigned to the
logged in user a standard
[http://trac.macports.org/projects/macports/report report]? If so, then
{7} and {8} serve that purpose, but you have to be logged in for them to
work. In any case, I don't see how this helps with item 5 above. Lastly,
what do you mean by initializing the custom query to search the summary?
Its initialization doesn't take any user input parameters, so it's hard to
search the summary for anything in particular. Custom query initializes to
tickets assigned to the logged in user, displaying the summary among other
ticket fields, so I'd say this is also covered for. Crossing out from
original description.
7. Ticket properties have been standardized to the most common values:
"Priorities" range from High to Low, including "Not set"; "Version" should
always match the version of MacPorts you're using, with the svn trunk
version always being $current_release + 1 (which is always accounted for
in the "Version" property of tickets), or simply not set ("blank") for
issues unrelated to MacPorts releases (like the guide or website); Trac
belongs to the infrastructure component, Installer is no longer a valid
component; the "Severity" property has been removed; for a particular
report, any keyword which you might think is related to the issue itself
and/or might help find it through Trac searches is an appropriate value
for the corresponding field. Reading our
[http://guide.macports.org/#project.tickets ticketing guidelines] will
help in understanding our workflow. Crossing out from original
description.
8. If you mean the Help link on the sidebar, then this is more than
anything related to the visual design of our Trac portal, see item 4 above
in my reply.
9. That help link is about Trac itself. When you say "describe this
tracker" I can only assume you are referring to a description of MacPorts
itself and our particular Trac workflow. Our new [http://www.macports.org
web page] and [http://guide.macports.org/#project.tickets ticketing
guidelines] fill that void. Crossing out from original description.
10. We don't maintain that help document and, above all, "Severity" is no
longer a valid ticket property for us. Crossing out from original
description.
11. (from the first ticket comment) Assigning to a port maintainer is as
simple as selecting his/her e-mail address from the "Assign to" pop-up
menu for the corresponding ticket property. even though currently not all
maintainers are listed in that menu, as per the discussion in ticket
#13352. Nevertheless, the facility to assign tickets is there and readily
available, so this issue is also covered for.
-jmpp
--
MacPorts </projects/macports>
Ports system for Mac OS
More information about the Tracker-discuss
mailing list