Moving from Redmine to GitHub?

(Alessio Fattorini) #1

Continuing the discussion from On feature workflow:

@davidep have already weighed the pros and cons of this moving:


  • redmine is on a dedicated machine and requires mantainance
  • wiki, and web pages data: they are just git repositories, and the backup is a trivial git fetch
  • working with PR is really easy
  • widely adopted
  • widely known
  • markdown support
  • supported by discourse linking an issue or a commit


  • github is on cloud (code and issues on their server)

@dz00te @vcc @Nas what about this moving? Since you have already worked hard on Redmine

@davidep can we write down a moving strategy step by step?

How to get involved?
(Davide Principi) #2

There could be different ways. I’d like to hear other people’s opinion before talking about strategies!

(Alessio Fattorini) #3

Sounds reasonable! Also @jgjimenezs worked hard on documentation side


honestly, i like redmine :slight_smile:
and i have the same doubts of stephdl about putting all on cloud.
but at the same time i like the idea to have all in one place, and a lot of interesting project are there (like elk and docker) with issues and wiki…

some doubts:

  1. quoting stephdl: “Indeed I follow now one channel, Redmine, but if each rpm tracks its own issues in github, how you can follow all issues of the project. I must admit that I don’t know if you can register to all bugs coming from the nethserver Git.”
  2. sometimes the issues section on github is used like a forum getting as results that after some time you’ll have a lot of open issues…
  3. From what i’ve seen (but i’m not a github expert) the wiki is per repository… maybe it’s too much fragmented to be a useful wiki?

but after all i think it could be a good move, specially if it make devs life easier (so they will have more time to add features to nethserver :wink: )

(Alessio Fattorini) #5

We should keep them clean, discussing features and bug here for first. Using them as we are doing on redmine, just for technical or testing notes.

(Artem Fedai) #6

Maybe it is good enought :slight_smile:

(Alessandro Lepore) #7

I’m not very much into nethserver and its redmine but i can add my 2c as a developer:

  • moving to github is probably the best move to maximize contributions and visibility
  • the main concern i heard in similar cases is the portability of github issues: we need to import old issues? can we export all the data in the future? it’s easy?

(Alessio Fattorini) #8

Ehi @Alessandro_Lepore thanks for your 2c, really happy to have you here, could I ask you to reply to this topic? I’m really curious about your developer opinion.

Please, enlighten me: how it can maximize contributions? which kind of github features make the difference?

(Alessio Fattorini) #9

We can keep the wiki just on

You will automatically watch any repositories you create or that are created by your team in an organization. If you are part of the NethServer team don’t need to subscribe repository one by one

(Alessandro Lepore) #10

the fact that Github is very well know and allow easy and fast contributions via pull requests is the key for me.

sometimes you want to contribute to something but you can’t do it a few minutes so you pospone it and… probably forget.

(Alessio Fattorini) #11

Thanks, this is a good point as @davidep has explained above


yes, it seems fair, also if i am still a little bit skeptical, but probably becouse i’ve never used it and it seems a little different from “normal” wiki like moinmon/doku/mediawiki

ok, but there aren’t many levels of permission… are they enough?
a nice link for qa on github:

(Alessio Fattorini) #13

Yeah, labels on github are really powerful

“Available for QA,” “QA Pass,” and “QA Fail.” As soon as code is moved to the dev environment, the “Available for QA” label is applied and that process kicks off.

The team documents the steps taken to QA the update and then applies the appropriate tag. When reviewing a Milestone for a push to production, it’s now very easy to see the QA status of each issue, for the whole team to review (and potentially improve upon) the steps taken in QA, as well as review any issues. All of our code, status, and feedback is even more consolidated than before.


some news from github about permissions:

I continue to be skeptical about the wiki on github
but leave the discussion to the How-To team :slight_smile:

(Davide Principi) #15

:wink: I’m experimenting a migration path from Redmine to GitHub. This is a brief list:

The following link gives an idea of the final result of the migration of currently open issues:

Search filters are very powerful. We could save some searches on the wiki, or on the main web site. For instance: all open bugs. I’d like to migrate also other pages from the Redmine wiki, such as Releases.

The GitHub API does not allow to set the issue/comment author. So I specified the author as a mention. For instance, compare to Of course, if we like it, we can discuss any possible enhancements and limitations of the migration process.

In the end, the migrated issues are also visible (and modifiable) from a nice dashboard provided by This is the link:

I invited some people (@stephdl, @Ctek, @dz00te, @Nas, @SystemEd-Jacob ) to join the and make some experiments.

:smile: Please share your thoughts!

(Alessio Fattorini) #16


as always , thank you for your work , but … can i create the QA label ? :slight_smile:
does this means that from now a new issue has to be created directly on github or always on redmine ?

(Davide Principi) #18

To change the issue state you should be member of IssuesTeam. I sent you an invitation…

This is a test only; let’s play with it to gather feedback.

Redmine is still the official issue tracker. Anyway I hope we agree to adopt GitHub :innocent:


yes and ofcourse i’ve joined…what I meant was that it lacked the label QA , so i’ve added it , also on waffle …
i hope to have some time to play with issues/waffle in next days :grin:

(Davide Principi) #20

Ok now it’s clear :wink: The label is actually ON_QA! Issues states are migrated as labels in GitHub.