Migration to Git Hub closed some tickets that should have been open

[khwilliamson]

#1196 was wrong closed

The status of that ticket on RT went from open -> rejected -> stalled -> open

@bram-perl says the "rejected" intermediate status triggered the GH issue to be closed

There must be other tickets like this

[jkeenan]

#1196 was wrong closed

The status of that ticket on RT went from open -> rejected -> stalled -> open

@bram-perl says the "rejected" intermediate status triggered the GH issue to be closed

There must be other tickets like this

So, how do we go about determining this? Would we be able to use our "archived" version of rt.perl.org to trace the history of the status of tens of thousands of RT tickets?

(If not, then this ticket would never be closable.)

[khwilliamson]

I'm hoping that people more knowledgeable about this than I can think of some way to figure out what types of tickets could have been affected

[bram-perl]

I believe that when the ticket was migrated from RT to GitHub that in the ticket creation it showed the current status of the ticket in RT.

That is, if you look at the first post in #1196 it contains:

Migrated from rt.perl.org#2166 (status was 'open')

Based on that the following filters might give a first indication of affected tickets:

• Rejected to open: 15 issues
• Resolved to open: 30 issues
• Stalled to open: 1 issue

Total of 46 issues

Notes:

• The list may contain false positives so needs to be double checked
• As closing date I used 2019-11-01 because I could not (quickly) find the exact date on when the GitHub migration happened, if the exact date is known then the searches can be more refined.

Another interesting search: Open in RT, closed before 2019-11-01: 69 issues.
This should include the 46 issues listed above but that still leaves 23 other issues.
Possible/likely this number goes down if a more accurate date is used.
(Possible approaches: create the delta between this list and the other searches and/or first process the other 3 lists and re-open the tickets that need re-opening and then redo this search.)

[jkeenan]

On 8/5/25 04:23, Bram wrote: *bram-perl* left a comment (Perl/perl5#23517) <https://github.com/Perl/ perl5/issues/23517#issuecomment-3154072539> I believe that when the ticket was migrated from RT to GitHub that in the ticket creation it showed the current status of the ticket in RT. That is, if you look at the first post in #1196 <https://github.com/ Perl/perl5#1196> it contains: |Migrated from rt.perl.org#2166 (status was 'open') | Based on that the following filters might give a first indication of affected tickets: * Rejected to open <https://github.com/Perl/perl5/issues? q=is%3Aissue%20state%3Aclosed%20%20author%3Ap5pRT%20closed%3A%3C2019-11-01%20%22(status%20was%20%27open%27)%22%20%22Status%20changed%20from%20%27rejected%27%20to%20%27open%27%22>: 15 issues * Resolved to open <https://github.com/Perl/perl5/issues? q=is%3Aissue%20state%3Aclosed%20%20author%3Ap5pRT%20closed%3A%3C2019-11-01%20%22(status%20was%20%27open%27)%22%20%22Status%20changed%20from%20%27resolved%27%20to%20%27open%27%22>: 30 issues * Stalled to open <https://github.com/Perl/perl5/issues? q=is%3Aissue%20state%3Aclosed%20%20author%3Ap5pRT%20closed%3A%3C2019-11-01%20%22(status%20was%20%27open%27)%22%20%22Status%20changed%20from%20%27stalled%27%20to%20%27open%27%22>: 1 issue Total of 46 issues Notes: * The list may contain false positives so needs to be double checked * As closing date I used 2019-11-01 because I could not (quickly) find the exact date on when the GitHub migration happened, if the exact date is known then the searches can be more refined. Another interesting search: Open in RT, closed before 2019-11-01 <https://github.com/Perl/perl5/issues? q=is%3Aissue%20state%3Aclosed%20%20author%3Ap5pRT%20closed%3A%3C2019-11-01%20%22(status%20was%20%27open%27)%22>: 69 issues. This *should* include the 46 issues listed above but that still leaves 23 other issues. Possible/likely this number goes down if a more accurate date is used. (Possible approaches: create the delta between this list and the other searches and/or first process the other 3 lists and re-open the tickets that need re-opening and then redo this search.)

Using what I think is a more accurate date term (before 2019-10-20) -- but otherwise using your approach -- I got these URLs and their counts. https://github.com/Perl/perl5/issues?q=is%3Aissue%20state%3Aclosed%20%20author%3Ap5pRT%20closed%3A%3C2019-10-20%20%22(status%20was%20%27open%27)%22%20%22Status%20changed%20from%20%27rejected%27%20to%20%27open%27%22 15 https://github.com/Perl/perl5/issues?q=is%3Aissue%20state%3Aclosed%20%20author%3Ap5pRT%20closed%3A%3C2019-10-20%20%22(status%20was%20%27open%27)%22%20%22Status%20changed%20from%20%27resolved%27%20to%20%27open%27%22 30 https://github.com/Perl/perl5/issues?q=is%3Aissue%20state%3Aclosed%20%20author%3Ap5pRT%20closed%3A%3C2019-10-20%20%22(status%20was%20%27open%27)%22%20%22Status%20changed%20from%20%27stalled%27%20to%20%27open%27%22 1 https://github.com/Perl/perl5/issues?q=is%3Aissue%20state%3Aclosed%20%20author%3Ap5pRT%20closed%3A%3C2019-10-20%20%22(status%20was%20%27open%27)%22 51 Only the count on the last query differs from yours (69 versus 51).

[jkeenan]

https://github.com/Perl/perl5/issues?q=is%3Aissue%20state%3Aclosed%20%20author%3Ap5pRT%20closed%3A%3C2019-10-20%20%22(status%20was%20%27open%27)%22
51

Only the count on the last query differs from yours (69 versus 51).

I was personally involved with 2 of the tickets on listed in that "51-results' query. I've looked at each ticket and have confirmed that there is a status problem.

• patch File::Path with CVE-2017-6512 fix in perl 526 #16144
  On Oct 15 2017, in patch File::Path with CVE-2017-6512 fix in perl 526 #16144 (comment), its RT Status changed from 'rejected' to 'open'. It should have been reborn in GH as Open; it was reborn as Closed.

• New compilation warnings in blead (-Wdeprecated-declarations) #17144
  On Sep 06 2019, in New compilation warnings in blead (-Wdeprecated-declarations) #17144 (comment), its RT Status changed from 'pending release' to 'open'. It should have been reborn in GH as Open; it was reborn as Closed.

Here is a suggestion for managing the problem:

• Decide which of the various GH search URLs cited in earlier posts to this ticket should be treated as definitive.
• Create a new GH label, perhaps "RT2GH-migration-problem".
• Have someone who has the knowledge and permissions apply that label via GH API call to all tickets in the "definitive" list and changed their GH status to Open. (I don't how to do such an API call safely; I don't have the perms.)
• Then, encourage readers of this list to examine those issues and make recommendations for resolution. Encourage new people to join in this effort, somewhat like what we are doing with TODO tests.

I suspect that some of these tickets will once again be Closable; others will still need work.

[khwilliamson]

I reopened the two, while I had them up on my browser

[khwilliamson]

I looked at a few more, and all were wrongly closed. I reopened them all while I had them up.

I noticed that all had had labels added on Oct 18, 2019. I tried searching for that, but couldn't figure out how to.

I also noticed another anomaly in #15489. There is no label for it, yet a label was added to it and not removed.

I'm stopping now. If we decide a RT2GH label is needed, I will add it to all the ones I've messed with

[bram-perl]

Here is a suggestion for managing the problem:

• Decide which of the various GH search URLs cited in earlier posts to this ticket should be treated as definitive.

My suggestion would be: look at the tickets and see who closed the ticket. (Unfortunately I have not yet found a way to include that in the search).
If @p5pRT closed the ticket then it was incorrectly closed and should be re-opened and/or re-evaulated.

• Create a new GH label, perhaps "RT2GH-migration-problem".
• Have someone who has the knowledge and permissions apply that label via GH API call to all tickets in the "definitive" list and changed their GH status to Open. (I don't how to do such an API call safely; I don't have the perms.)

That seems more effort then it's really worth.
If anything then I would just add a comment in the issue saying something like: Ticket re-opened because it was incorrectly closed in RT->GitHub migration; see #23517.

Then all incorrectly closed tickets will show up in this ticket as a reference.

(Adding a permanent label to a temporary problem just seems like a bad idea because it will lead to an extra label that will exist for forever.)

[jkeenan]

Well, the mere fact that someone has re-opened some of the 69 (or 51) tickets means that the list of tickets picked up by @bram-perl's searches has shrunk. So my recommended approach is now inoperable. At this point, we should probably just re-open all the tickets detected by those queries.

As to the feasibility of a label, we've created labels in the past that were expected to have only a limited lifetime. IIRC, labels are deletable.

[khwilliamson]

I don't understand how @jkeenan 's approach is inoperable. It is a simple matter to do the search again, and do the procedure on the results plus me manually adding the label to the ones I messed with

And yes we have had labels that were temporary; so that's not an impediment to creating a new one.