Migrate from Trac to GitHub

[mc-butler]

Important

This issue was migrated from Trac:

Origin	https://midnight-commander.org/ticket/3746
Reporter	sorin (@ssbarnea)

I think that it would in MC interest as a project to have the issue tracker hosted on GitHub and I am willing to help with the migration if that's ok.

[mc-butler]

Changed by andrew_b (@aborodin) on Dec 22, 2016 at 5:24 UTC (comment 1)

• Status changed from new to closed
• Milestone Future Releases deleted
• Resolution set to wontfix
• Version master deleted
• Component changed from mc-core to adm

No. Github tracker sucks.

[mc-butler]

Changed by zaytsev (@zyv) on Dec 22, 2016 at 7:51 UTC (comment 2)

Longer version:

GitHub tracker is slowly becoming less shit than it used to be, i.e. they have added "milestones" not so long ago, but everything else you are supposed to emulate via labels (report type, priority, affected version, component), and to make it worse, they don't allow to group the labels (also sometimes called custom fields), so for anything more than 1-2 dimensions this is simply not practicable. Now, to make things worse, cross-referencing of issues is supported, but you can't see all references in a sidebar or something like that and have to read the entire thread (!!!11) to see which other tickets were referenced and at which point. All of that makes it unusable for larger projects.

I think that a possibility to move to a more decent supported & hosted system like YouTrack or JIRA (if JetBrains and/or Atlassian would want to sponsor the project) can be discussed, but GitHub is just too much of a pain, and I don't see the deal-breaking downsides of Trac, although, very clearly that's not the best possible system to use.

There have been some occasional whining on the lists that one needs to register on the Trac, but everybody has already got a GitHub account, and that a different issue tracking system cuts off valuable contributors, but so far the average quality of reports & patches from GitHub have been so low, that I'm unconvinced that it makes any sense to consider this argument in our situation.

[mc-butler]

Changed by ossi (@ossilator) on Oct 14, 2020 at 18:20 UTC (comment 3)

fwiw, one way to cut down the whining would be enabling github authentication on trac. i presume (a new version of) trac has a plugin for that.

[mc-butler]

Changed by zaytsev (@zyv) on Nov 1, 2020 at 23:53 UTC (comment 4)

Well, there haven't been much whining in the last couple of years, actually. Maybe we've driven all GitHub fanbois away... which might habe not been necessarily a bad thing, considering #shitober.

Migrating to the latest version of Trac would be great - and finally solve the long posting problem. Actually, even more awesome would be to set up the machine anew with Ansible. Unfortunately, both Patrick and Slava were no friends of scm, so the current machine is quite a mess. And I have barely time to keep it alive, no even speaking of setting up a new one :-/

[mc-butler]

Changed by sorin (@ssbarnea) on Nov 2, 2020 at 7:45 UTC (comment 5)

Just let mc project rot here while number of users and contributors will only go down. It is very easy to underestimate the infrastructure maintenance cost (time being the main currency).

While setting any DIY solution seams easy on paper, nobody can assure they are 24/7 available to upgrade, tune, service it — especially long term. Some projects realised that and focused on what helped them survive. Purists on the other hand risk isolating themselves even more, and we all know how well these isolated communities endup (pick your own netflix documentary here).

mc is not alone in the DIY area, I seen really big projects with lots of developers and backing organisations behind going the same route and ending up spending most of their time with infrastructure work instead of doing other changes that could have helped them evolve much faster.

I will stop commenting on this ticket while also sending a big thank you to all those that helped maintaining mc.

[mc-butler]

Changed by ossi (@ossilator) on Nov 2, 2020 at 11:47 UTC (comment 6)

big projects [...] ending up spending most of their time with infrastructure work

that seems just a little bit like hyperbole. ;)

i'm volunteering for setting up a new server, and can semi-commit to helping with maintenance for about a year. you know how to reach me.

[mc-butler]

Changed by zaytsev (@zyv) on Nov 2, 2020 at 12:06 UTC (comment 7)

Note how the previous post just as usual rehashes abstract arguments (probably?) trying to convince someone who doesn't need convincing, instead of contributing any new analysis to the situation, or offering specific help. Unfortunately, this is exactly the reason why nothing has happened on this front in the last 4 years - nobody is willing or has the capacity to do the work properly, but everybody likes to argue for one thing or another.

To make it clear once again, although this has been discussed already on numerous occasions on the list: nobody here is against migration to GitHub issue tracker on principle. All we want is that maintainer experience doesn't degrade as the result - or that someone else takes the maintainership over. So far nobody presented a sound migration plan and the commitment to implement it, and no candidates possessing a minimal amount of sanity have presented themselves as new maintainers either.

For the maintainer experience to not to degrade, two things are necessary:

1. GitHub tracker should possess a minimal amount of required functionality
2. Issue migration should be implemented cleanly
   • Issue contents should be ported over as good as possible
     • Trac markup should be cleanly converted to Markdown
     • Milestones should be ported over and linked to correct issues
     • Current filters should be meaningfully converted into labels
     • Creation / addition / modification dates of issues and comments should be kept
     • Attachments should be ported over
   • Preferably, the issue numbers should be kept
   • Preferably, the identities of the posters should be kept

Now, instead of writing yet another meaningless appeal to proceed with the migration, I've actually took the time to have a look at the current state of art. It seems that the situation has somewhat improved over the last 5 years:

1. The labels still suck, but one can work with them, since our use of ticket fields is limited
2. Issue references still suck as well, but at least they are available in search, so one can find all related tickets, even if they are not shown in the ticket view sidebar
3. Issue templates has been introduced, which can help with the deficiencies of a bare bones tracker
4. There is a new (still unofficial) ticket import API - https://gist.github.com/jonmagic/5282384165e0f86ef105 - which allows to batch-create issues, preserve some dates & poster identities

Some ideas can be taken from the following Ruby script, which seems to be the most advanced migrator available to date:

https://github.com/mavam/trac-hub

So in as far as I'm concerned, the migration is becoming feasible, only it's going to be a hell lot of work - it's certainly much easier and faster to spin up a new Trac server with Ansible... if there were any time available at all.

[mc-butler]

Changed by zaytsev (@zyv) on Nov 2, 2020 at 12:12 UTC (comment 8)

i'm volunteering for setting up a new server

Hi ossi, are you experienced with CentOS and Ansible? If yes, I'll keep it in mind. The reason why I'm asking, is that yet another manual dirty reinstall makes no sense.

P.S. It looks like I've solved the long posting problem o_O by switching the mailer to sendmail from SMTP again... hmmm, I wonder why did't it work the last time.

[mc-butler]

Changed by ossi (@ossilator) on Nov 2, 2020 at 14:00 UTC (comment 9)

i did (sorta) maintain a few servers in the qt project which were running centos. anyway, i don't see distro differences as a significant hurdle.

i haven't played specifically with ansible yet, but automatic provisioning is no stranger to me. i'm not sure the overhead of that would pay off for a single instance, though, especially when incremental changes are required - a dump of package selections and a git bundle of (sensibly version-controlled) config files is sufficient for re-provisioning and is probably less effort overall. anyway, i welcome suggestions for optimized workflows.

[mc-butler]

Changed by ossi (@ossilator) on Nov 2, 2020 at 14:11 UTC (comment 10)

P.S. It looks like I've solved the long posting problem o_O

can't confirm. maybe something starts hanging after the first submission?
anyway, this is tracked more specifically in #3771.

[mc-butler]

Changed by sorin (@ssbarnea) on Feb 28, 2022 at 10:59 UTC (comment 11)

Apparently midnight commander project kinda killed itself by refusing to adapt. I am not trying to point fingers here, just to open some eyes, maybe it is possible to revive the project.

Fully moving to github, so people can use the issue tracker and the discussion forum (instead of ancient mailing list which many avoid) would be good start. Ensuring that the project has an IM channel is another good way to grow a community around.

Regarding IM, likely Matrix based one would be optimum as most open-source projects went for this and is also bridged with irc.

Just few few minutes ago I spotted some errors in documentation wiki, but there is no edit button. Clearly making easier to contribute was not a top priority.

[mc-butler]

Changed by zaytsev (@zyv) on Mar 1, 2022 at 10:21 UTC (comment 5.12)

Replying to sorin:

I will stop commenting on this ticket [...]

... didn't take too long... ;-)

I am not trying to point fingers here, just to open some eyes

Maybe you can start by opening your own eyes to the earlier comments in this ticket? Once again, and hopefully for the last time, nobody is against the migration from Trac do GitHub on principle, but it's a lot of hard work - we are not motivated to do it badly, but don't have resources to do it properly, and it seems that nobody outside is interested in doing it properly as well.

P.S. My colleagues are told me today that there is talk about cutting Russia off GitHub. Maybe we won't be even able to commit in the near future, so the problem with "evil Russian maintainers still using Trac" will resolve itself sooner than later.

[mc-butler]

Changed by zaytsev (@zyv) on Feb 22, 2025 at 13:02 UTC (comment 13)

• Status changed from closed to reopened
• Resolution wontfix deleted

[mc-butler]

Changed by zaytsev (@zyv) on Feb 22, 2025 at 13:03 UTC (comment 14)

• Owner set to zaytsev
• Status changed from reopened to accepted
• Type changed from defect to task
• Milestone set to 4.8.34

[mc-butler]

Changed by zaytsev (@zyv) on Feb 22, 2025 at 13:04 UTC (comment 15)

• Blocking set to #2972