#74 Move from Trac to Pagure
Closed: approved 8 years ago Opened 8 years ago by bex.

It looks like most people are trying to make pagure.io work. My initial impression is it is going to be a rough around the edges.

We need to decide what we want to do and whether we want to talk to infra about possibly standing up an issue tracker more like trac.

I will ask @jflory7 to post in this ticket about his experiences using pagure.io with commops.


Replying to [ticket:74 bex]:

It looks like most people are trying to make pagure.io work. My initial impression is it is going to be a rough around the edges.

Why? What gives you that impression/what is missing?

We need to decide what we want to do and whether we want to talk to infra about possibly standing up an issue tracker more like trac.

I absolutely object to that. Trac is terrible and infra is trying to reduce the services and code bases they have to support. If there are issues with pagure that need to be fixed, then file feature requests for them.

I will ask @jflory7 to post in this ticket about his experiences using pagure.io with commops.

[The following is my personal opinion and not official word from infrastructure]

I can understand the want. Pagure is meant to handle source code and making that efficient. It isn't meant to be a ticketing system like RT or similar tools. Trac was never really meant to do so and we have had to do all kinds of hacks to make it work for groups who aren't dealing with source code but requests and tracking of requests.

That said, I don't see infrastructure standing up another resource without sufficient 'capital' and 'planning' to do so for the reasons jwboyer gives above.

We ''do'' have another existing choice we could switch to: Bugzilla.

This is perhaps mixing tickets, but one of the problems we face today is that we don't have an obvious place for opening tickets that apply to a specific Edition or Spin. I've been considering proposing for a while that we might want to add a new Bugzilla product under the Fedora umbrella around top-level issues; perhaps we could do this with the Council as well.

For example:
'''Classification''': Fedora
'''Product''': Fedora Governance
'''Component''': Fedora Council / Fedora Server Edition / Fedora KDE Spin / etc.

In terms of Editions/Spins, this would be the sort of place that requests like "Please include package 'foo' in the default install" would belong. (Today, we're kind of abusing the fedora-productimg-$EDITION packages for this).

Replying to [comment:3 sgallagh]:

We ''do'' have another existing choice we could switch to: Bugzilla.

This is perhaps mixing tickets, but one of the problems we face today is that we don't have an obvious place for opening tickets that apply to a specific Edition or Spin. I've been considering proposing for a while that we might want to add a new Bugzilla product under the Fedora umbrella around top-level issues; perhaps we could do this with the Council as well.

For example:
'''Classification''': Fedora
'''Product''': Fedora Governance
'''Component''': Fedora Council / Fedora Server Edition / Fedora KDE Spin / etc.

In terms of Editions/Spins, this would be the sort of place that requests like "Please include package 'foo' in the default install" would belong. (Today, we're kind of abusing the fedora-productimg-$EDITION packages for this).

I'm not against this, though I would strongly prefer to only have a single location for Council issues. Having multiple places where things are tracked means we run the risk of things falling through the cracks because not everyone is looking at multiple tool instances, etc.

I'm not sure I can agree with the assertion that pagure isn't "meant" to be a ticketing system. I think it's meant to be useful in various roles within Fedora, and a reasonable Trac replacement is one of those.

If it's missing something that's really needed to fulfill a role as a replacement for Trac's ticket system, then I would urge that feature requests be filed. Even a month ago it might not have been a suitable replacement, but a load of new functionality went into 2.7 to meet the needs of various Fedorahosted projects. There's a good chance that it already has the functionality that you think it's lacking.

I'd think things would have to be pretty bad before it's at the point that bugzilla would be considered a better choice.

For Council, I don't think we have any really complicated needs. The custom resolutions are nice to have, but no big deal. The only report I regularly use is "open tickets", so... that's not special.
CC'ing arbitrary people would be nice.

Taiga, which is already part of the infra, may also be a good choice. However, I agree with others in the thread that I think pagure could be a solution as well.

One big plus for the Bugzilla proposal are searching capabilities of Bugzilla comparing to the searching capabilities of Pagure. I am always frustrated when searching for a specific ticket in Trac and not remember ticket id. On the other hand, with the amount of ticket Council is processing, this is probably not a big issue.

In case it's not immediately obvious since this just changed last week, pagure lets you do free text searches on the ticket database.

Hi all! Sorry for taking so long to circle back to this ticket. Some of my thoughts are down below.

= Pagure vs. Bugzilla vs. $OTHER =

I think it is especially important for the Fedora Council to consider using Pagure as the targeted platform for migrating to. The primary reason for me emphasizing this is that most of the Fedora community using Trac / FedoraHosted is being guided towards Pagure as the new home for tickets, codebases, and discussion. Even though the Council is strictly a ticket-based team, I think it's important to use Pagure to help keep the Council accessible to project members.

Bugzilla is not an easy-to-use tool as far as someone who may be of a non-technical background (thinking of Marketing / community / translations types of contributors), so I think using something like Bugzilla would isolate a fair number of contributors who may need to file a ticket to reach the Council's attention. Pagure has a fairly easy-to-use GUI and it shouldn't be too hard for a contributor to log in, file an issue and format it with markdown, and submit.

Additionally, there are some nice Pagure fedmsg hooks that may be of use that would be harder to capture with another platform like Bugzilla, Taiga, or something outside of Fedora.

= Migration toolset =

Using Pagure also ensures easy migration of past discussions and tickets from this Trac. Members of the Infrastructure team are developing the [https://pagure.io/pagure-importer pagure-importer] tool, which cleanly exports data from a FedoraHosted Trac instance and moves it to a Pagure ticket repository. As far as I know, no other tools or platforms will preserve history like we are able to do with Pagure (if there are ways to do this for other platforms, I wonder how easy something like that is to do).

This tool is under active development, but does work well for most Trac=>Pagure migrations I've tried. This tool alone makes Pagure an attractive option to move to.

= Examples =

There's a few ticket-based teams so far that are avidly using Pagure as a Trac replacement or alternative. You can see some of them below (explanations of the types of workflows they're using are explained farther down).

I've helped set up / migrate the CommOps, Marketing, and Diversity team repos, so I'll base my explanations off of those teams.

= Components to tags =

The Council Trac usings components to "categorize" tickets into relevant subject areas for people to submit their tickets for. This feature can be replicated within Pagure with tags, and although it's shown in a different manner than it is with Trac, it's an effective way to categorize tickets based on main subject areas. There's actually a flag in the [https://pagure.io/pagure-importer pagure-importer] to export things like components and keywords into Pagure tags. It requires a little manual cleanup, but it helps preserve components in Trac Pagure tags without too much manual work.

Additionally, milestones are also super easy to set up and use, so it would be easy to further categorize tickets in the Council Pagure to Fedora releases (e.g. Fedora 25, Fedora 26, Fedora 27, "Future releases", etc.). This could be a helpful way to ensure that tickets are dealt with in a timely manner within each release cycle.


Although I may be a little biased based on personal preference, I find Pagure a great replacement for Trac and I whole-heartedly recommend it to the Council for consideration.

Members of the Infrastructure team are developing the ​pagure-importer tool,

To be fair, I am the only member of the Fedora infra team with commits in this project, and I have 3 (out of 105 commits), so this tool is in reality being developed by people from our community, which makes it so much cooler :)

Just as an extra thought, since we have this great opportunity to help make the Fedora contributing experience consistent (or incredibly different) in different sub-projects as they migrate from Trac to Pagure, it would be great to try to follow similar practices across teams. As another example, I just migrated the Fedora Ambassadors of North America to Pagure and tried using namespacing to help make it clear about the purpose of the repository. Example is here:

https://pagure.io/ambassadors-na/tasks

I imagine the Council could be a good example for other sub-projects to follow too if they are still hanging on in Trac. :)

The public tickets have been migrated. I'm going to do the private ones next, hopefully without messing that up. :)

This ticket is inaccessible via the url provided:
https://pagure.io/tickets/issue/74

I believe this repository should be renamed fedora-council, or something
similar.

regards,

bex

On Mon, Nov 14, 2016, at 05:19 PM, Matthew Miller wrote:

mattdm added a new comment to an issue you are following:
The public tickets have been migrated. I'm going to do the private ones next, hopefully without messing that up. :)

To reply, visit the link below or just reply to this email
https://pagure.io/tickets/issue/74

This ticket is inaccessible via the url provided:
https://pagure.io/tickets/issue/74
I believe this repository should be renamed fedora-council, or something

This seems to be a bug in Pagure. I used the existing "Fedora-Council" namespace and created a project within that called tickets. The URL should be https://pagure.io/Fedora-Council/tickets/issue/74

I'm going to go ahead and call this done. We can deal with new issues as they arise.

@mattdm changed the status to Closed

8 years ago

Log in to comment on this ticket.

Metadata