#737 [RFE] Allow to reassign bug to different project
Closed: Won't Fix a year ago by wombelix. Opened 8 years ago by vondruch.

I was recently thinking what would it take to replace Fedora's cgit and bugzilla by Pagure and I am pretty comfortable with that idea, but I think that one feature is missing, which is essential for Fedora/Bugzilla integration and this is the possibility to reassign bug from one component to other component. In case of Pagure, the equivalent feature would be to reassign issue from one project to another project. Is this feasible?


While I kinda like the idea of replacing cgit w/ pagure I doubt pagure will get enough motion to ever replace bugzilla.

Too many tools and worflows are relying on it and having issues in both locations is a no-go, people won't know where to look anymore.
I've been working on making pagure in such a way that issues can be disabled globally so that we can just turn them off if we replace cgit w/ pagure.

Now if more people want to see the possibility for issues to be re-assigned, that can still be considered :)

Challenges I see:

  • The ticket Id will need to be updated otherwise you would end up with two ticket 737 (for example)
  • The link will be broken ( https://pagure.io/pagure/issue/737 re-assigned to libpagure means the link returns a 404, or we need to keep track of the change w/ a redirect but then it may end up with a bunch of redirect)
  • Handle ACLs so that there can be a group of triagers that can re-assign tickets but do not have commit rights

There are probably more but these are the ones I can think off right now.

While I kinda like the idea of replacing cgit w/ pagure I doubt pagure will get enough motion to ever replace bugzilla.

Who knows ... but if you enable PR for .spec files, this would be major win IMO.

Too many tools and worflows are relying on it and having issues in both locations is a no-go, people won't know where to look anymore.

There would be no bugzilla anymore, just Pagure, but of course, there is plenty of tools/forkflows bound to BZ.

Challenges I see:

The ticket Id will need to be updated otherwise you would end up with two ticket 737 (for example)
The link will be broken ( https://pagure.io/pagure/issue/737 re-assigned to libpagure means the link returns a 404, or we need to keep track of the change w/ a redirect but then it may end up with a bunch of redirect)

Well, the original ticket could be kept open and just linked to the new clone. Or it could be closed, just pointing to the new ticket which would contain full history. Something like if you are cloning bug in BZ.

BTW, where is my "quote" formatting? Is there some ticket that it doesn't work?

I think the easiest way here is to think of this as more of a clone bug feature:

For example, I open a bug against pagure, for example bug number 1234.

But it is then realised that it is actually a bug in pagure-cli, so we:

  • close bug 1234 is closed with some new state and everything hidden it in except for say a link to the new bug against pagure-cli, lets call it bug 42 against lpagure-cli.
  • add to the newly created bug 42 all the discussion etc from bug 1234

The last update was 6 years ago, no further requests, updates or actionable tasks since then, I'm going to close this issue for now to reduce our backlog.

Metadata Update from @wombelix:
- Issue close_status updated to: Won't Fix
- Issue status updated to: Closed (was: Open)

a year ago

Login to comment on this ticket.

Metadata