Discuss migrating off of Trac onto 'something' else

Django Internals
1

I believe the facts around Trac to be true, but if it’s not, please correct me in the replies.

I wanted to start a conversation about Trac and work to determine if it’s still meeting our needs as a community.

Why talk about this now?

When looking at the Trac Project it looks like there is active development, however, it was only within the last 12 months (Oct 2023) that a version was released that supported Python 3.

When looking at the Roadmap for Trac Milestone 1.6.1 is 10 months late as of this initial posting (it was set to be released in January of 2024).

Trac very much looks like a project that is in maintenance mode and could present a risk to Django.

Current Understanding of Trac’s Appeal

During the DSF Office Hours today (November 6, 2024) I asked a question about why ‘we’ (i.e. the Django Community) use Trac for tickets. The answers that came back were very reasonable:

  1. Known current workflow for the fellows when trying to triage tickets
  2. Support for ‘reports’
  3. Support for extra metadata fields
  4. History
  5. Ability for community triage

I believe that we as a community can, and should, ask if Trac is still the best place for our tickets, and if it isn’t, we should look to explore alternatives.

Potential Alternatives

The (first/only?) alternative that comes to most people’s minds is GitHub issues. There are some potential limitations to GitHub Issues like lack of community triage capabilities, and it lacks extra metadata fields that are useful in Trac. I believe that these limitations may be non-starters for the Community.

There are others. JetBrains has been a big supporter of Django for several years and they have a product called YouTrack that, in my experience, is very Trac like in its feature set:

  1. Support for ‘reports’
  2. Extra metadata fields that are (easily) configurable
  3. Ability to set up permissions to allow authenticated user issue triage

Potential Next Steps

I’d like to hear the community’s thoughts:

  1. How do you feel about continuing with Trac?
  2. Should we begin exploring alternatives? If yes, what other options should we consider beyond GitHub Issues and YouTrack?
  3. If now isn’t the right time for a change, what criteria should we establish to determine when it is time to evaluate alternatives?

This would be a big change which means that a DEP is likely in order, but I was hoping to get community feedback before starting to work on such a DEP.

I’m looking forward to the various perspectives on this topic!

5 Likes
2

Just anfew notes, since I don’t have the time to elaborate on them in full, but yet want to share some insight from the ops and former core contributor perspective.

  • Trac is a pain to work with when you get started. But it’s highly customizable and we’ve done that on many places
  • I’d like to stick with either something self-hosted to not rely on another third party for such a vital part. GitHub would be fine, because I doubt that we’ll ever migrate away from it.
  • if we go for a hosted service, I’d like to have a way to interact with it using scripts, auch that we can export data in the future and important existing data
  • the Python team made GitHub work for them, let’s get some insights from them, how they did that. Especially, how they got old issues into GitHub.
  • with GitHub, well have a pain when it comes to referencing old issues and pull requests, as both start numbering at 1 and have a long list of overlapping numbers.
3

I want to add a longer post with my thoughts, but while I write that, I can say that this conversation should probably happen now or after initial feedback in Django Internals - Django Forum

The DSF individual members are not the only part of the community, and in this case, it would be a subset of our Trac users.

4

@alexgmin I’ve moved the post over to Django Internal as you suggested (I had a hard time figuring out where best to post, so thanks for the input)

5

Just want to point out though: there’ll be a bunch of folks with highly valued input but who get tired of having the same discussion raised every month or so and may not contribute to this particular thread :slight_smile: .

Instead of tiring these folks out further we should either make one big place referencing all the past discussions or just keep the discussion going on a previous thread.

PS: I think there are valid points for either way but if I had to vote I’d say leave everything on trac but see if there are some improvements that can be made for it eg the esoteric markup means that bug reports always have the formatting wrong and is something that triagers need to constantly correct :sweat_smile: I don’t know how it’s managed but is there a modern version that allows markdown?

1 Like
6

When CPython migrated the issue tracker to GitHub, GitHub provided some us with access and resources that allows the old issues to be migrated (like creating ‘mannequin’ users for situation when the bug reporter user on the old issues tracker isn’t already on GitHub), and also allowed us to keep the numbering from the old issues tracker to GitHub.

I imagine GitHub would want to support large open source projects like Django too the same way they helped Python with the issue tracker migration.

3 Likes
7

This sounds to me that we need an Informational DEP.

1 Like
8

Just want to point out though: there’ll be a bunch of folks with highly valued input but who get tired of having the same discussion raised every month or so and may not contribute to this particular thread :slight_smile: .

Are there previous threads you can add here? I looked through Trac, and Thr Django Discord and wasn’t able to find anything that seemed like this has been brought up before. Maybe I’m looking in the wrong place?

9

This sounds to me that we need an Informational DEP.

I really like this Idea if it’s a possibility!

10

Before we discuss on whether we should move to Github Issues, YouTrack or anything else I want to point of some of the issues with the Trac project.

Trac is not an abandoned project, but every year is getting closer to that. The first release to support Python 3 was 1.6, released in Sep 2023.
This means that the DSF had to run Trac in Python 2.7 up until that date. Python 2.7 was EOL in Jan of 2020. This means more than 3 years of having to run an unsupported Python version.
Trac right now supports Python 3.5-3.11, and the current version won’t run in 3.13 due to modules like crypt being removed.
There have been 6 releases in the last 4 years. 1 of those was the major one in 2023 that supported Python 3.
If you look at the commit history, the last 100 commits have been done in the last 7 months, and in reality it’s around 50 commits in 7 months done since they are pushing to 1.6.1 and the 1.7.1 branches at the same time. And 95% of those commits were by the same person.
If we don’t migrate from Trac at some point, there will be a moment in which the DSF will have to fork it and maintain it, if Trac has a big security issue, chances we will have to fix it ourselves. And the more time it passes the more likely this is.
If you look at Trac’s own list of users, you will find many big projects like Tor, VLC, wxWidgets, RPM, jQuery, which all have migrated to either Github or Gitlab issues. Based on a quick check, the main players I see still using Trac are Django, Wordpress, FFmpeg and FileZilla. And Wordpress is running quite a few modifications and I think not using the latest version.

Maybe now is not the right time to do a migration to some other choice, maybe there are no other choices as good as Trac for the current usage. But we should start planning for what to do if Trac becomes unmaintained.

1 Like
11

Well, there’s this thread from 2018 about widening participation, coming out of DjangoCon that year.

https://groups.google.com/g/django-developers/c/aiyE__qSHBY/m/0DErKI0gCQAJ

And it comes up every couple of turns, I’d say.

The issues I see are:

  1. The history. It’s absolutely impossible to work on Django without it. A hard criterion on any option is that we can’t loose that. And it can’t become impossible to filter/search. (This last is a problem with GitHub issues. DRF, for example, a large project that I’ve worked on at length, is much harder to find related issues on, despite probably having only a tenth or less of the history.)
  2. The freedom. It’s likely we already passed peak GitHub. I’m very sceptical of tying ourselves to a corporate solution. I know many others in our community are too.
  3. What alternative is actually better? They’re all horrific to use (or not powerful enough) as far as I can see.

Likely there are more, but those are the ones that stand out to me quickly.

@bmispelon is busy pushing the Django Trac forward. I think his opinion is likely the most valuable in terms of the risk we face.

2 Likes
12

I’ll throw out one other idea that I haven’t seen mentioned… what if you built one! Don’t know if there are any instances of “django using django”, but I think that would have some interesting side effects. No need to respond, just wanted to lob it in there as a wild idea to consider.

2 Likes
13

Thank you for this. It’s the exact thing I was hoping would be available to review :grin:

14

I think building something custom is worth exploring, and I would be willing to help!

Also, https://www.djangoproject.com/ is built with Django: GitHub - django/djangoproject.com: Source code to djangoproject.com

15

I’d like to add something to this.

In my mind, as long as the Trac project is still managed on svn, instead of Git/GitHub, they’re making it harder on themselves to continue to maintain the project and to accept contributions to it. This might be a different situation 10 years ago, but now is 2024. There are reasons many open source projects, including Python and Django, have moved their codebase to GitHub or GitLab. These products have built out tools and resources, like adding APIs, CI/CD to help make contributing experience better and easier and more beginner-friendly. Maybe the Trac product itself is good, but contributing to improve Trac is a different story. (And this could be a reason why the development of Trac seemed slower).

Many of the tools that facilitates open source contribution and collaboration are already available on other platforms like GitHub/GitLab. In the year 2024, open source contributors are more likely to be familiar with GitHub issues than with Trac.

Regarding building new issue tracker from scratch, we should consider whether it would take less effort to do it than to migrate to something ready to use like GitHub. It’s not just the software that we need, but also long-term maintenance and hosting.

2 Likes
16

This is most likely not going to fly. We had the same discussion when moving to this forum – writing a good forum software or bug tracker from scratch is everything but a side project. We should strive to use good tools instead of writing our own just because it would be in Django then. And as Mariatta correctly points out, there is the question of maintenance and hosting.

While there is truth in it I do not think that this is the main barrier to contribution. I think what also might have been contributing to it is that trac is not a “fancy” project to work on. Not many are using it anymore and it is kinda exotic in the sense that it is already an old project where many things are done differently, so the know-how gained by contributing there isn’t as easily transferable to other projects like when you contribute to a Django project. That said, we can mostly guess… What’s sure though is that trac feels kinda dead and when moving somewhere else we should really prefer existing systems over writing our own subpar solution (and I really mean it, it would be subpar for a long time, because those things are not as easy as they look on the surface).

4 Likes
17

A couple of thoughts :+1:

If we want to plan for what to do if Trac is unmaintained, I feel we should try to reach out to the Trac team and have a conversation about if we can support/sponsor their work.

If GitHub issues doesn’t suit the community, something like Bugzilla might be worth looking into.

Concluding this discussion with a (informational) DEP to point people to would be a win :trophy:

2 Likes
18

I believe Trac meets our needs. I can’t think of some functionality another issue tracker has that I would like to have.

If Trac is in maintenance mode or continues to evolve slowly, frankly, I think that’s kind of a good thing. We can spend our time building Django rather than keeping up with changes to our bug tracker.

We’ve built a lot of infrastructure and tooling around Trac, and it would be expensive to rework our processes.

When we moved the django-developers mailing list to this forum, I was discouraged that we lost the ability to easily search the long history of the Django project. Moving the bug tracker would likely present the same issue. I find tremendous value in searching the huge archive of issues using Google’s “site:code.djangoproject.com” filter.

We could try to migrate old issues to a new tracker and add redirects on code.djangoproject.com to prevent broken links, but I suspect any migration to another tracker is going to be imperfect and result in things like broken links, improper formatting, etc.

I believe we would need a very, very compelling reason to migrate to another issue tracker. I don’t know what level of risk there is of Trac going unmaintained, but I would be inclined to chjp in with maintenance help if needed rather than face the prospect of migrating to another tracker.

4 Likes
19

In the universe where Trac is more maintained (I’m thinking in particular regarding Python versions and the like), would we be more happy?

There’s obviously more of a barrier to entry to Trac than Github Issues, and I do think that it’s hard to declare it in “maintenance” mode if we were looking at it running on 2.7 3 years after EOL. But if we’re talking mostly about treadmill issues, those are much more resolvable. Especially if Issues feels like a “we don’t have any other choice” choice

Personally the lack of real metadata on Github (and having it all flattened to labels) is very unsatisfying when looking through things. Though here I think ultimately the voice of the current heaviest Trac users matters the most.

I am comfortable volunteering my time to contribute to a one-time “get Trac working on Python 3.13” patch effort, which would grant us… 4 years of security patch coverage?

2 Likes
20

Just on this point, there was a suggestion to export the Django-developers history and import it here via the API. I think that got stymied by the pandemic, but it would still be feasible.

Only the other day here I was searching for an older thread and was able to locate it in a single shot, which was never the experience on the Google Group. (toot)

1 Like