clearly indicate to users where they should file bugs for operational issues
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Twisted Website |
New
|
Undecided
|
Unassigned |
Bug Description
Right now the only thing on the web site suggesting a way to report a problem - with Twisted, with the web site, with the software itself - is the "new ticket" link in the navbar. The fact that one should use the Twisted website for reporting issues with the Twisted website is further reinforced by the presence of the open "website" component. As per this discussion: <http://
Also, the website component should be closed so that folks don't file new bugs in it.
What's wrong with reporting operational and website issues in Trac?
I guess there good reasons. I'd be interested to hear them if you have
time to summarise.
I think it would be much more intuitive if twistedmatrix. com/trac was
the single database of all Twisted related issues.
1. Easy for bug reporters to find
2. Single sign on (doesn't require *another* registration)
3. Admins can monitor all new Twisted issues in one place.
4. I find Trac ticket reporting much simpler and more intuitive than
Launchpad - maybe just because I'm familiar with Trac.
5. Simple Trac markup for formatting the ticket description and
comments.
On the other hand...
1. Trac is a single point of failure.
* If Trac (website) dies you can still get the configuration and file
tickets about the problem on Launchpad.
2. Trac is slow
* Maybe you are trying to minimise the use of Trac to reduce the
slow down.
= Ticket #6329 =
My original trac ticket was badly constructed, /twistedmatrix. com/trac/ ticket/ 6329 names.common. ResolverBase. getHostByName api documentation
* https:/
"pydoctor does not generate
twisted.
because it is in an interface base class"
I'd reported the problem in Pydoctor. I wanted to make sure that Tom
(or someone) was aware that the problem. I created a duplicate Trac
ticket and filled in the Launchpad ticket field; thinking this would
be a way of notifying Trac devs when the pydoctor problem was fixed,
at which point they could upgrade pydoctor on the buildslave.
Alternative Options:
1. Associate the ticket with multiple projects: I just discovered /bugs.launchpad .net/twisted- buildbot- configuration/ +bug/1027879
that I can associate a Launchpad ticket with multiple projects -
as exarkun has done in
*
https:/
I've now done this for another of my tickets: /bugs.launchpad .net/twisted- buildbot- configuration/ +bug/1132527 /bugs.launchpad .net/pydoctor/ +bug/1132527
* https:/
* https:/
2. Or I could have created a separate ticket eg
"upgrade pydoctor on bot-glyph-1 to support API documentation from
interface base classes"
...in https:/ /bugs.launchpad .net/twisted- buildbot- configuration
Anyway, I must admit I felt cheesed off when all my tickets were buildbot- configuration on Launchpad and I could have gone
closed "invalid" last week, but...on reflection, I was aware of
twisted-
looking for it. I guess I was just being lazy.
I also remember feeling curious about the Launchpad ID field in the
Trac tickets and wanted to try it out. I know it's related to
Launchpad integration with external trackers, but is that still used
by Twisted? If not, can it be removed to avoid future confusion /
temptation.
= A Custom New Ticket Page =
How about customising the Trac "New ticket" page. trac.edgewall. org/wiki/ NewTicket trac.edgewall. org/wiki/ TracInterfaceCu stomization# CustomNavigatio nEntries
The Trac project does it:
* http://
* http://
If I can have "Wiki Edit" permissions on twistedmatrix. com/Trac I'll draft an Edgewall
style NewTicket page.
-RichardW.