Discuss migrating off of Trac onto 'something' else

[ulgens]

I’m a bit lost about what should be discussed here or on Trac migration informational DEP - Feedback required, so forgive me if I bleed context from one to another.

@MarkusH

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

+1, but we may need to define “scripting.” My understanding is that Trac needs this sort of custom tooling because it lacks automation/integration solutions. Github, for example, already has almost unlimited capability for integrations, and issues can be edited or comments can be added using integrations. We wouldn’t need a custom “scripting” solution if we use what GitHub provides.

@MarkusH

• 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.

+1. I’m curious how they handled their filtering/sorting/search needs. Also, what other projects can we check for similar use cases?

@alexgmin

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.

https://trac.edgewall.org/ticket/13774

Trac project is still discussing dropping the Python 3.5 support and it looks like 3.6 support will stay there for years to come. The roadmap doesn’t look bright. Trac’s Python support policy is already pulling the updates on https://code.djangoproject.com/ and I don’t think it worths it.

It would be wise to move away from Trac before it needs to be maintained by DSF. I found myself in a similar place with a couple of different projects, the most notable being graphene-django, and I should say it’s a black hole for all types of resources.

@tom

The benefit, I believe, is that many newcomers are confused about even where the tracker is. Then, how to use it.

• Issues and pull requests live on two different systems, confusing the newcomers.
• It’s not clear what Trac actually provides with the current setup. Is the wiki alive? Do we want to keep it alive? If so, how is it different from the docs, and when should one prefer one over the other? Is the dashboard it’s in the ideal state, or does it require a significant amount of volunteer power to get in shape? (An example of the best version of the dashboard in my mind is https://clickpy.clickhouse.com/ but for Django issues)
• Trac is old and ugly. I know this is not an objective comment, but I believe it’s the common take. I don’t remember the last time I worked with Trac in any other project, it may be more than 10 years ago. For a new contributor who is trying to understand the SDLC of Django, an old system that nobody even remembers is not the most friendly welcome. Having SVN instead of git would give the parallel feelings. It doesn’t look “modern”, and if anything, it makes you feel like something will go wrong and you won’t be able to get help.

---

1. How do you feel about continuing with Trac?

I think it’s a no-go. Even if Trac was the perfect tool and everyone liked it, with its current state of maintenance, it’s a ticking bomb.

2. Should we begin exploring alternatives? If yes, what other options should we consider beyond GitHub Issues and YouTrack?

• I guess GitHub is the obvious first choice. I’m concerned about the label/filtering capabilities, but do we need to limit ourselves to what GitHub provides? Can we extend the dashboard and add filtering and management screens? By syncing Github issues and a Django installation, even Django admin could handle this, and it might be much cheaper to develop.
  • Using Django admin for Django development could significantly increase the development speed of admin Eating your own dog food - Wikipedia
• +1 for YouTrack, but I’m not sure about its licensing approach, and it doesn’t have the “everything is in same place” factor.
• Jira? It provides everything mentioned in this post and even more, but I’m not sure about a couple of points:
  • Is it fast enough? Can it handle the data size Django have?
  • Is it cheap enough?
  • Is its maintenance easy & cheap enough?
• I guess we are not looking for commercial and cloud-hosted solutions unless there is a very special reason not to ignore them. This rules out tools like linear.app .
• Redmine? Not sure how it compares to Trac in terms of being modern and well-maintained, but I’m surprised to see it wasn’t mentioned yet.

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?

If we postpone this any further, it won’t get any easier, so I think the earliest time with enough resources is the right time.

---

I saw many people sharing concerns about preserving history, and I think everyone understands how vital it is, so I believe keeping history intact won’t be an overlooked task. I’m more concerned about keeping the old (Trac) links working and how to redirect them to the new system.