why not go all in github , which may not be perfect but is far better than osdn, and directly linked to code, and other branches like freeciv-web ?
Or add a redmine instance on the same server as freeciv-web ?
Reply To alain_bkr
why not go all in github
https://www.hostedredmine.com/issues/896778?pn=1#change-2018503
I love redmine, but as of today 2022 , in github you have 4 ways to sorts things, this seems to be enough
A quick look at wesnoth (which is similar complexity to freeciv, maybe a bit bigger, more bugs, mores branches, more developers)
https://github.com/wesnoth/wesnoth/projects/7
In the redmine link you care about Review period
I think you cannot get much more than 1 guy tested it, and it is in one branch, alpha, beta ...
Using github forks can be very useful, and much simpler and efficient than attached patched like in the 90's
Freeciv is not a compiler, maybe we could relax , and simplify the workflow, to make it easier and faster for everyone, including newcomers.
OSDN really sucks
Gitlab has the huge advantage to link tickets and commits, and avoid to go to an unrelated site all is integrated.
If github was so bad compared to osdn, all projects would be here (on osdn), and many projects find it good enough, for sure it is better than osdn
Another solution could be GitLab , or create a redmine instance on the freeciv-web server, but please, get a decent bug tracker. :-)
Reply To alain_bkr
Another solution could be GitLab , or create a redmine instance on the freeciv-web server, but please, get a decent bug tracker. :-)
As gitlab has already introduced some limitations to open source projects (limited free CI runtime - understandable limitation, but we regularly use ten times what they would provide per month), I wouldn't invest there.
Likely solution is RT on freeciv.org (back to where we started). As for schedule - hopefully this year.
OSDN ticket system has its limitations compared to what we had in hrm (or in gna before that). Figure out processes to work with these limitations.
1) There seems to be no good tools for defining ticket relations with each other 2) There's no ticket status suitable for marking patch/fix to be in "Review Period"