Ticket #3746 (closed defect: wontfix)

Opened 5 years ago

Last modified 13 months ago

migrate from trac to github

Reported by: sorin Owned by:
Priority: major Milestone:
Component: adm Version:
Keywords: Cc:
Blocked By: Blocking:
Branch state: no branch Votes for changeset:

Description

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.

Change History

comment:1 Changed 5 years ago by andrew_b

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

No. Github tracker sucks.

Last edited 5 years ago by andrew_b (previous) (diff)

comment:2 Changed 5 years ago by zaytsev

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.

comment:3 Changed 14 months ago by ossi

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.

comment:4 Changed 13 months ago by zaytsev

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 :-/

comment:5 Changed 13 months ago by sorin

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.

comment:6 Changed 13 months ago by ossi

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.

comment:7 Changed 13 months ago by zaytsev

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.

comment:8 Changed 13 months ago by zaytsev

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.

comment:9 Changed 13 months ago by ossi

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.

comment:10 Changed 13 months ago by ossi

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.

Note: See TracTickets for help on using tickets.