#4968 Project upgrade silently changes issue numbers [ss623] [ss637] NEEDS INI

forge-oct-05
closed
nobody
General
1
2014-08-24
2012-09-18
Chris Tsai
No

Implementation: We should index ticket's import_id in solr (put it in the index() method) so it is searchable. Also make URLs like /myproject/tickets/N when a regular ticket isn't found then fall back to check import_id. If a ticket is found by import_id, do a permanent redirect to the real url for that ticket.


[forge:site-support:#623]

Issue numbers from the sourceforge bug tracking system prior to migration did not migrate in project upgrade, and description of upgrade consequences did not warn of this.

As a test of the project upgrade path, I upgraded the sarmanager project. The consequences of upgrade appear to be poorly documented in the requests for projects to upgrade. One severe side consequence is the renumbering of issues in the sourceforge issue tracking system.

For example, what was issue: 3484452 has become issue 21, breaking crossreferences between the issue tracker and svn commit messages. Thus the commit message in https://sourceforge.net/p/sarmanager/code/35/ can no longer be related to the relevant issue: https://sourceforge.net/p/sarmanager/bugs/21/

A requirement of the migration of an issue tracking system which exposes issue numbers is the retention of issue numbers. Issue numbers may be referenced in many arbitrary places outside of the issue tracking system itself.

I'm not going to be able to upgrade other projects until this issue has been resolved.


[forge:site-support:#637]

I'm wondering if it is possible to keep the old tracker ID of issues in the bug/feature request/... tracker in a classic project, when migrating to the new (beta) project?

One of my projects uses the tracker ID's to link to bugs or feature requests from the release notes/changelog. When migrating to the new project, all tracker items would get a new ID. So it would be useful to have either/both :
- a redirect in place that redirects to the ticket in the new project when requesting the tracker item in the classic project.
- get a list of tracker items with the old ID and the new ID. This way, our current references to tracker items could be converted to reference the new tracker ID's.

I think it's fine that we don't use the same IDs exactly, but we should definitely provide a reference to them.

In the meantime though, since we have redirects in place, using the following link format will let users use discover the corresponding ticket using just the ticket ID: https://sourceforge.net/support/tracker.php?aid=1234567

eg. for sarmanager above: https://sourceforge.net/support/tracker.php?aid=3484452 will redirect to https://sourceforge.net/p/sarmanager/bugs/21/ (technically, there's actually an intermediate redirect as well)

Related

Forge: Site Support: #623
Forge: Site Support: #637

Discussion

1 2 > >> (Page 1 of 2)

  • Anonymous
    2012-09-19

    Why not just initialize the new numbering with N+1, N being the last of the old system ?
    You would have had perfect continuity, without any redirects nor concern about their lifetime, zero hassle.

     
    • Dave Brondsema
      Dave Brondsema
      2012-09-20

      In the new system, we decided it would be best to have individual unique numbers per tracker instance, not sitewide. Then most projects have small numbers since they start at 1, rather than very big numbers like 3484452

       
      • Yes, that's what you decided. But you may have overlooked the fact that old projects with a long history will suffer from this. As a mitigation, what about allowing each project to choose among the two scheme (reset or continuity) ? Note that in case of continuity, it means less work for you (no mapping/redirect to keep track of).

         
  • Dave Brondsema
    Dave Brondsema
    2012-09-20

    • labels: support, p3 --> support, p3, 42cc
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -1,3 +1,7 @@
    +**Implementation:** We should index ticket's `import_id` in solr (put it in the `index()` method) so it is searchable.  Also make URLs like /myproject/tickets/N when a regular ticket isn't found then fall back to check import_id.  If a ticket is found by import_id, do a permanent redirect to the real url for that ticket.
    +
    +----
    +
     [forge:site-support:#623]
    
     >Issue numbers from the sourceforge bug tracking system prior to migration did not migrate in project upgrade, and description of upgrade consequences did not warn of this.
    
    • milestone: limbo --> forge-backlog
     
  • Created #172: [#4968] Fall back to check ticket import_id when a ticket isn't found by it's regular id (1cp)

    • status: open --> in-progress
     
    Last edit: Igor Bondarenko 2012-09-21
  • Dave Brondsema
    Dave Brondsema
    2012-09-25

    Hrm, we currently store an import_id of "tracker/1/420" for example, when migrating from our classic system. This doesn't work out quite as well and will take some additional thinking

     
  • James Bassett
    James Bassett
    2012-09-30

    I'm stumped as to what to use for the bugtraq:url property in subversion now.

    Before the upgrade I used http://sourceforge.net/support/tracker.php?aid=%BUGID%. This will still work for old commits (with the redirects in place) but not for any new commits.

    If I update it to https://sourceforge.net/p/supercsv/bugs/%BUGID% that restricts me to only using it for bugs (not feature requests) as each tracker has it's own unique ids now.

    And as soon as I change it to a new format, it will no longer work for old commits.

     
    Last edit: Dave Brondsema 2012-10-02
    • Dave Brondsema
      Dave Brondsema
      2012-10-02

      James, I will have to think about what to suggest for the issue of bugs being separate from feature-requests.

      However, our current work on this ticket will mean that https://sourceforge.net/p/supercsv/bugs/%BUGID% will work for old ids. Hopefully that will be of some help when its live.

       
1 2 > >> (Page 1 of 2)


Anonymous


Cancel   Add attachments