Sounds reasonable! Also @jgjimenezs worked hard on documentation side
honestly, i like redmine
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…
- 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.”
- 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…
- 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 )
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.
Maybe https://bitbucket.org/ it is good enought
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?
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?
We can keep the wiki just on https://github.com/NethServer/nethserver-docs
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
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.
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: http://www.koddi.com/better-github-qa/
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
I’m experimenting a migration path from Redmine to GitHub. This is a brief list:
- Any ON_DEV, MODIFIED, VERIFIED issue on dev.nethserver.org should complete the natural development process, towards the CLOSED state.
- Any NEW and TRIAGED issue is migrated to GitHub and closed as DUPLICATE on dev.nethserver.org. A link is added to the issue description, to preserve the original reference. Around ~100 issues are currently on these states.
- All CLOSED issues are saved as static HTML files. This is an example hosted on GitHub pages
The final URL result unchanged, to preserve all links
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 https://github.com/NethServer/testdev1/issues/125 to http://dev.nethserver.org/issues/1612. Of course, if we like it, we can discuss any possible enhancements and limitations of the migration process.
Please share your thoughts!
as always , thank you for your work , but … can i create the QA label ?
does this means that from now a new issue has to be created directly on github or always on redmine ?
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
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
Ok now it’s clear The label is actually ON_QA! Issues states are migrated as labels in GitHub.
We should beware of GitHub issues They
- cannot be deleted (useful for spam)
- cannot be private (may be useful for security bugs)
However the past history suggests we’ll rarely deal with such cases.
Just a question, (maybe not so bright) We are keeping the old redmine active and use Git in parallel so that information is duplicated ? Or we will migrate all the information ?