#74: Moving off of Trac to someting
------------------------+---------------------
Reporter: bex | Owner:
Status: new | Priority: normal
Component: Board Meta | Resolution:
Keywords: |
------------------------+---------------------
Comment (by jflory7):
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).
* [
https://pagure.io/fedora-commops/ fedora-commops]
* [
https://pagure.io/fedora-marketing fedora-marketing]
* [
https://pagure.io/fedora-diversity fedora-diversity]
* [
https://pagure.io/i18n i18n]
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.
--
Ticket URL: <
https://fedorahosted.org/council/ticket/74#comment:10>
council <
https://fedorahosted.org/council>
Fedora Council Public Tickets