Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider migrating from RT #5413

Closed
p6rt opened this issue Jul 2, 2016 · 19 comments
Closed

Consider migrating from RT #5413

p6rt opened this issue Jul 2, 2016 · 19 comments
Labels
meta Repo organization, code style, etc. RFC Request For Comments rt

Comments

@p6rt
Copy link

p6rt commented Jul 2, 2016

Migrated from rt.perl.org#128520 (status was 'resolved')

Searchable as RT128520$

@p6rt
Copy link
Author

p6rt commented Jul 2, 2016

From @AlexDaniel

It was discussed before, but unfortunately we did not get anywhere.

I think that we have to try again because the need is stronger than ever.

For example, see this​: http://irclog.perlgeek.de/perl6-dev/2016-07-02#i_12773781

Such things should not be tolerated. Issue tracker where people cannot login is useless. I had this issue too, but fortunately in my case one of the admins replied after several days.

There are several options. One is to use github (as that's where rakudo source is already), but there are also other options as well (self-hosted and not).

@p6rt
Copy link
Author

p6rt commented Jul 2, 2016

From @zoffixznet

A definite -1 from me.

The one important thing this proposal fails to mention is all the references to RT from commits, roast, source code, and third party websites or people's notes that reference RT as the place to report Perl 6 bugs.

Unless someone is willing to offer an enormous amount of effort to migrate all the tickets, update all references, and set-up correct mail and web redirects for all RT tickets, we'd have to run two ticket systems and suffer the confusion that'd would cause.

As alternatives go, GitHub is out because you can't submit issues by simply emailing. So that leaves a self-hosted system as the only alternative. So who'll be setting that up and managing it and what system would that be? And most importantly, why?

The only 'stronger than ever' reason to move I see you mention is a single user who has trouble logging in. Is that really a justifiable cause to expend a huge amount of effort for a project that doesn't have enough volunteers as it is?

We already had this discussion around this point​: http://irclog.perlgeek.de/perl6/2016-02-04#i_11989733

@p6rt
Copy link
Author

p6rt commented Jul 2, 2016

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Jul 2, 2016

From @AlexDaniel

I have compiled a list of problems with RT.

I wrote this while annoyed, so it's a bit snippy, and I apologize for the tone, but I figure that a list of actionable issues is more constructive than just me going “aaaa I want to use something else” and mst encouraged me to post it for that purpose.

* If you are not logged in and you press “Comment” or “Reply” buttons, you will see this​: “For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org ”. Well, that's not user-friendly at all. It should probably say that you should either create an account or write an email.

* Some people are experiencing account problems. I have tried to reproduce it but failed, but people still get it from time to time. The solution is to write to an admin, but the answer does not come as fast. There should be no such problem in the first place.

* Frequent CSRF errors without any good reason. Sure, that's not critical, but it is very annoying.

* No way to edit your ticket or comment. While this may be beneficial from one point of view, I'd much rather have the ability to edit stuff (I often do mistakes, I want to be able to fix those. Github is not that great because there's no edit history, but even without edit history it is probably better). For example, this comment could have been an editable list of issues with RT, but instead I will be writing new comments in order to add some items (or mark something as solved).

* Tickets are created by default in perl5 queue, and it seems like there's no way to change the default. People have already created issues in the wrong queue, and I think that one day I will do that too (I've already been 1 click away from that several times). While this is not a big issue, there should not be such problem in the first place.

* No git integration of any sort. I think that I'd love to see at least clickable links to git commits.

* No markup. Well, there is something if you write an email, I guess, but if you're submitting a ticket/comment from the web interface then there's no easy way to do that. Are HTML tags supported? No idea. After 100+ tickets reported I don't know. There's no preview. And I can't test things because there's no way to edit your tickets… Ideally I'd love to see markdown or creole support (or anything else, as long as it is clearly stated that it is supported)

* What's the difference between “Reply” and “Comment”? Is it explained anywhere? Is it possible to explain it somewhere so it will be obvious for people who write a comment for the first time?

* Is there any way to have clickable tags? I know that I can create a search query of any complexity that can solve this issue, but let's agree that it is less than awesome. The tag should be clickable (e.g. click on “testneeded” and see other tickets that are tagged this way, also only in the same queue). That's kinda one of the basics that I am expecting from a issue tracking system.

* Constant spam. Maybe there is a way to get less spam on RT? I don't mind deleting it from time to time, but before I was able to do that it was pretty annoying (what if some 6 year old clicks on it, right?).

* No progress. These issues were there for years, but I see nothing that will give me hope that it will be better in the future. If there's any progress, can we make it more transparent?

@p6rt
Copy link
Author

p6rt commented Jul 2, 2016

From 1parrota@gmail.com

A chance to eat our own dogfood?

On 7/2/16, Alex Jakimenko <perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Alex Jakimenko
# Please include the string​: [perl #​128520]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=128520 >

It was discussed before, but unfortunately we did not get anywhere.

I think that we have to try again because the need is stronger than ever.

For example, see this​:
http://irclog.perlgeek.de/perl6-dev/2016-07-02#i_12773781

Such things should not be tolerated. Issue tracker where people cannot login
is useless. I had this issue too, but fortunately in my case one of the
admins replied after several days.

There are several options. One is to use github (as that's where rakudo
source is already), but there are also other options as well (self-hosted
and not).

@p6rt
Copy link
Author

p6rt commented Jul 8, 2016

From @coke

On Sat Jul 02 09​:00​:35 2016, alex.jakimenko@​gmail.com wrote​:

I have compiled a list of problems with RT.

I wrote this while annoyed, so it's a bit snippy, and I apologize for
the tone, but I figure that a list of actionable issues is more
constructive than just me going “aaaa I want to use something else”
and mst encouraged me to post it for that purpose.

* If you are not logged in and you press “Comment” or “Reply” buttons,
you will see this​: “For issues related to this RT instance (aka
"perlbug"), please contact perlbug-admin at perl.org ”. Well, that's
not user-friendly at all. It should probably say that you should
either create an account or write an email.

Definitely a usability nit that we should document, and perhaps we can ask the perl.org RT admins if there's a a workaround.

Note​: I hear some harsh talk about dealing with the RT admins on the IRC channel. I would recommend that we have a standard practice for this sort of thing, which is probably​: open an RT in our own queue describing the issue. Pick someone to be the single POC for the issue with the volunteer admins, they can open the ticket and report progress. I do this unofficially now for some case.

* Some people are experiencing account problems. I have tried to
reproduce it but failed, but people still get it from time to time.
The solution is to write to an admin, but the answer does not come as
fast. There should be no such problem in the first place.

Any solution we use is going to be volunteer run. The volunteers at rt.perl.org have always been very helpful and as prompt as possible when I ask questions, or try to followup on behalf of someone who has been having trouble. The most recent problem has been fixed, as far as I know, there is no one experiencing issues.

* Frequent CSRF errors without any good reason. Sure, that's not
critical, but it is very annoying.

Specifics, please, and open tickets about this if it's not already open. (one's already open. I haven't yet followed through with the rt.perl.org admins to see if it's easily fixable)

* No way to edit your ticket or comment. While this may be beneficial
from one point of view, I'd much rather have the ability to edit stuff
(I often do mistakes, I want to be able to fix those. Github is not
that great because there's no edit history, but even without edit
history it is probably better). For example, this comment could have
been an editable list of issues with RT, but instead I will be writing
new comments in order to add some items (or mark something as solved).

In my opinion, edits sans history is so much worse. If anyone can edit things to say whatever they want whenever they want, that's bad. Better, IMO, to have to reply with a comment. This is an issue with any number of free & paid ticketing solutions. (In JIRA, for example, some people are given the permission to edit any comment, even ones not their own, which makes figuring out what's going on a PITA)

And if you need to continually be reworking your ticket, I suggest what we've adopted at $dayjob; use a wiki or other document to gather your thoughts, and once you've locked down the problem/request/description, *then* open a ticket. ticket systems are meant to track work, not have design discussions. This obviously is only helpful on the big edits.

* Tickets are created by default in perl5 queue, and it seems like
there's no way to change the default. People have already created
issues in the wrong queue, and I think that one day I will do that too
(I've already been 1 click away from that several times). While this
is not a big issue, there should not be such problem in the first
place.

The recommended way to open tickets is using the rakudobug at perl.org
email address; this defaults to the P6 queue.

If you're opening them some other way, you can change your default
queue in the menu. I don't know what you're referring to here, though.

* No git integration of any sort. I think that I'd love to see at
least clickable links to git commits.

Agreed.

* No markup. Well, there is something if you write an email, I guess,
but if you're submitting a ticket/comment from the web interface then
there's no easy way to do that. Are HTML tags supported? No idea.
After 100+ tickets reported I don't know. There's no preview. And I
can't test things because there's no way to edit your tickets… Ideally
I'd love to see markdown or creole support (or anything else, as long
as it is clearly stated that it is supported)

I'm not an RT expert, but perhaps this is available in a newer version and/or is a configurable option.
I believe as is, no, it's plain text.

* What's the difference between “Reply” and “Comment”? Is it explained
anywhere? Is it possible to explain it somewhere so it will be obvious
for people who write a comment for the first time?

Reply is sent to the original requestor. Comment is only put on the ticket.
As for documenting it, absolutely, let's start a "How to manage tickets for Perl 6" doc
somewhere. I'll put a page in https://github.com/rakudo/rakudo/wiki/ to start.

* Is there any way to have clickable tags? I know that I can create a
search query of any complexity that can solve this issue, but let's
agree that it is less than awesome. The tag should be clickable (e.g.
click on “testneeded” and see other tickets that are tagged this way,
also only in the same queue). That's kinda one of the basics that I am
expecting from a issue tracking system.

I'm not an RT expert. Perhaps this is available in a newer version and/or is a configurable option.

* Constant spam. Maybe there is a way to get less spam on RT? I don't
mind deleting it from time to time, but before I was able to do that
it was pretty annoying (what if some 6 year old clicks on it, right?).

As someone who is in the queues fairly often, I don't think this claim holds up. There is -some- spam, sure, but nothing like what we saw on parrot's trac instance, for example. And any bugadmin can kill it by hitting the big red "S" in the menu bar. If you've been doing this before I get to any of it, thank you!

* No progress. These issues were there for years, but I see nothing
that will give me hope that it will be better in the future. If
there's any progress, can we make it more transparent?

The lack of progress on old tickets has little to do with the ticketing system they are in. What sort of information are you looking for? I regularly ping the IRC chat with summary information on tickets; Tell me what you're looking for, I'm happy to provide it.

--
Will "Coke" Coleda

@p6rt
Copy link
Author

p6rt commented Jul 8, 2016

From @coke

* What's the difference between “Reply” and “Comment”? Is it
explained
anywhere? Is it possible to explain it somewhere so it will be
obvious
for people who write a comment for the first time?

Reply is sent to the original requestor. Comment is only put on the
ticket.
As for documenting it, absolutely, let's start a "How to manage
tickets for Perl 6" doc
somewhere. I'll put a page in https://github.com/rakudo/rakudo/wiki/
to start.

https://github.com/rakudo/rakudo/wiki/rt-basics  #subject to change
--
Will "Coke" Coleda

@p6rt
Copy link
Author

p6rt commented Jul 8, 2016

From @AlexDaniel

If you're opening them some other way, you can change your default queue in the menu.

Oh wow! Indeed!

I'm not an RT expert, but perhaps this is available in a newer version and/or is a configurable option.

It says in the footer that the currently used version is 4.0.18, which was released on 2013-10-15. This, however, was at the time when 4.2 was already available.
In other words, the thing that we are using right now is quite old. Can we update it? Perhaps all these issues do not exist in the newest version?

The lack of progress on old tickets has little to do with the ticketing system they are in.

I was talking about RT itself. This, however, is not entirely true. RT itself progressed quite a bit during these years, it's just that the currently used version here is a bit old.

@p6rt
Copy link
Author

p6rt commented Jul 28, 2016

From @geekosaur

On Fri, Jul 8, 2016 at 2​:21 PM, Will Coleda via RT <
perl6-bugs-followup@​perl.org> wrote​:

The lack of progress on old tickets has little to do with the ticketing
system they are in. What sort of information are you looking for? I
regularly ping the IRC chat with summary information on tickets; Tell me
what you're looking for, I'm happy to provide it.

I think that meant lack of progress on issues with the RT config?

I am reasonably sure that between a newer RT and additional scrips, things
like git integration and markdown support can be solved. But we're using
someone else's RT instance, and most of the issues are ultimately more
administrative than technical.

With respect to spam​: welcome to public-facing ticketing systems. Spam is
not a solvable problem, only one that can be managed to a limited extent.
Spammers specifically target these systems once they find them, mostly (but
not completely) to support fake "SEO" schemes or to provide
legitimate-looking links to foil email spam detectors; switching to a
different ticketing system will only cause spammers to switch to tools that
work against the new ticketing system. If you regularly use a ticketing
system that doesn't appear to have a spam problem, talk to that system's
admins and you will find they have more bodies looking for and whacking
spam as it arrives.

--
brandon s allbery kf8nh sine nomine associates
allbery.b@​gmail.com ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

@p6rt
Copy link
Author

p6rt commented Jul 28, 2016

From @AlexDaniel

On 2016-07-27 17​:43​:46, allbery.b@​gmail.com wrote​:

With respect to spam​: welcome to public-facing ticketing systems.

Yeah, sure, I do understand all that. However, if we switched to, for example, GitHub, then there will be no spam issue on our shoulders.

I am not saying that we should move to GitHub, I hope that there are better alternatives (arguably, even RT is better in some respects), but I do want to say that there are ways to not have any spam issues.

That being said, spam problem is definitely one of the least important points in my list.

@p6rt
Copy link
Author

p6rt commented Aug 25, 2016

From @zoffixznet

* No git integration of any sort. I think that I'd love to see at least clickable links to git commits.

Can you explain what that means? In detail, what the feature would entail; what would those clickable links to git commits be derived from, for example?

I'm currently working on an app that interfaces with RT via its API. Its current primary scope is to assist release managers with tracking ticket status, but I'm not seeing any major roadblocks for it to become an alternate UI to RT. For example clickable tags are already implemented and adding markdown support is trivial.

Was wondering what the git integration was about...

@p6rt
Copy link
Author

p6rt commented Aug 30, 2016

From @AlexDaniel

I'm currently working on an app that interfaces with RT via its API.

Yay! (… for those wondering where it is, here​: http://perl6.fail/ )

And indeed, you can actually do all of these things, but it requires a bit of trickery :)

* No git integration of any sort. I think that I'd love to see at
least clickable links to git commits.

Can you explain what that means? In detail, what the feature would
entail; what would those clickable links to git commits be derived
from, for example?

Well, here are some thoughts.

Let's say the comment says​:
“Fixed with 157b46e
Tests added in 4317d5826aea42ca22ce6a64691a52313411275d ”

Then you can match this comment against m​:g{ « <.xdigit>* » } and query all matched strings in git repos. Turn everything you find into a link to github. I doubt that you'll find many false-positives this way.

Another thing you can do is go through all rakudo, nqp and moarvm commit messages and search for strings like “#​128520”. Then append it to tickets like​: “Ticket mentioned in commit …”.

Tiny but useful things.

implemented and adding markdown support is trivial.

Not sure about this one. Unless we switch to it completely, I don't think that it is right to treat RT messages as if they were formatted markdown formatted when they're not. After all, I learned that you can change your settings in RT and it will start displaying a fancy formatter that will produce HTML (which is supported).

@p6rt
Copy link
Author

p6rt commented Oct 3, 2017

From @AlexDaniel

This is just a test.

Writing a comment by email.

@p6rt
Copy link
Author

p6rt commented Oct 11, 2017

From @AlexDaniel

There was some fresh discussion on this topic recently. See https://irclog.perlgeek.de/perl6-dev/2017-10-11#i_15289848 and the start of the discussion on https://irclog.perlgeek.de/perl6-dev/2017-10-11#i_15289680

The idea is that instead of doing a full migration we can just start using another tracker in parallel, and then we'll see how it goes.

@p6rt
Copy link
Author

p6rt commented Oct 11, 2017

From @AlexDaniel

Oh, and if rakudo/issues is opened, then for me all issues raised in this ticket will be resolved.

On 2017-10-11 13​:21​:41, alex.jakimenko@​gmail.com wrote​:

There was some fresh discussion on this topic recently. See
https://irclog.perlgeek.de/perl6-dev/2017-10-11#i_15289848 and the
start of the
discussion on https://irclog.perlgeek.de/perl6-dev/2017-10-
11#i_15289680

The idea is that instead of doing a full migration we can just start
using
another tracker in parallel, and then we'll see how it goes.

@p6rt
Copy link
Author

p6rt commented Mar 5, 2018

From @zoffixznet

On Wed, 11 Oct 2017 13​:22​:50 -0700, alex.jakimenko@​gmail.com wrote​:

Oh, and if rakudo/issues is opened, then for me all issues raised in this
ticket will be resolved.

It was opened awhile ago.

…and based on the recent usage, seems GitHub's ticket tracker is preferred by users, so as far as this ticket goes, I think it can be closed.

@p6rt
Copy link
Author

p6rt commented Mar 5, 2018

@zoffixznet - Status changed from 'open' to 'resolved'

@p6rt p6rt closed this as completed Mar 5, 2018
@p6rt
Copy link
Author

p6rt commented Mar 8, 2018

From @stmuk

Maybe the ticket should be closed if/when the RT bug tracker is closed
to new tickets itself and references to RT removed from all docs?

S

On 5 March 2018 at 17​:50, Zoffix Znet via RT
<perl6-bugs-followup@​perl.org> wrote​:

On Wed, 11 Oct 2017 13​:22​:50 -0700, alex.jakimenko@​gmail.com wrote​:

Oh, and if rakudo/issues is opened, then for me all issues raised in this
ticket will be resolved.

It was opened awhile ago.

…and based on the recent usage, seems GitHub's ticket tracker is preferred by users, so as far as this ticket goes, I think it can be closed.

--
Steve Mynott <steve.mynott@​gmail.com>
cv25519/ECF8B611205B447E091246AF959E3D6197190DD5

@p6rt
Copy link
Author

p6rt commented Mar 8, 2018

From @AlexDaniel

OK, there's now a follow-up ticket here​: rakudo/rakudo#1598

On 2018-03-08 00​:39​:56, steve.mynott@​gmail.com wrote​:

Maybe the ticket should be closed if/when the RT bug tracker is closed
to new tickets itself and references to RT removed from all docs?

S

On 5 March 2018 at 17​:50, Zoffix Znet via RT
<perl6-bugs-followup@​perl.org> wrote​:

On Wed, 11 Oct 2017 13​:22​:50 -0700, alex.jakimenko@​gmail.com wrote​:

Oh, and if rakudo/issues is opened, then for me all issues raised in
this
ticket will be resolved.

It was opened awhile ago.

…and based on the recent usage, seems GitHub's ticket tracker is
preferred by users, so as far as this ticket goes, I think it can be
closed.

@p6rt p6rt added meta Repo organization, code style, etc. RFC Request For Comments rt labels Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta Repo organization, code style, etc. RFC Request For Comments rt
Projects
None yet
Development

No branches or pull requests

1 participant