Hello list.
I decided to make a couple follow-up comments on my own message to this list
from 3 years ago, please see below.
---- On Mon, 08 Jun 2015 14:21:13 +0100 Denis Ovsienko <denis@xxxxxxxxxxxxx>
wrote ----
---- On Mon, 18 May 2015 20:23:05 +0100 Stephen Groat wrote ----
Has there been any thought of moving the issues and wiki from Mantis and
Mediawiki to the Github Issues and Git/Markdown-based wiki?
I just did it for some of the project in my enterprise (using Github
Enterprise) and it worked really well. We mainly did it for centralized
auth and found that we get a lot more issues reported.
There's tools specifically for Mediawiki transfers and Mantis transfers.
You could even move hosting to github pages.
Just an idea, partially because I hate mantis.
Hello.
Your point is easy to understand, but please note there are other points
that are maybe not so obvious but still valid.
GitHub as a web-site or a tool or a collaboration platform is essentially
aligned towards the goals of the business that owns it. It used to be that
those goals can peacefully co-exist with the needs of free/open source
software projects that are looking for a free hosting, but this generally
cannot be relied upon forever. This means that one day GitHub-hosted
projects may have to migrate elsewhere to continue the work and this can be
very inconvenient as GitHub bug tracker is proprietary and they don't give
you your own data in a simple way. Let me remind: the previous RackTables
bug tracker migration from SourceForge to a self-hosted bug tracker was not
as painful as it could be becase it was MantisBT and SourceForge provided
the database dump on request. I don't complain, especially as I am not a
paying customer of GitHub, it is just a brief explanation of how things work.
Even if nothing disappointing happens to the GitHub free service, their bug
tracker is still far from a typical modern bug tracker. For instance, they
have not yet invented the concept of a "duplicate bug", which has been
around in other bug trackers for 10-15 years and proved to be useful. Maybe
later, no problem. This isn't bad in itself (I appreciate their honesty of
calling it "lightweight"), in some use cases this is exactly what people
need. In particular, when people want to learn bug tracking and git version
control and/or how those can work together. Or when they just want to start
a quick hack that is not intended to live long. Or when they are migrating
from another proprietary bug tracker that is in a worse state and there is a
migration tool readily available.
To avoid unnecessary frustration it helps to understand the work you are--
about to do and how the different tools available can and cannot help. In
the case of RackTables, as far as I managed to figure it out, the work falls
into two rough categories:
1. Something that is specific to a released version and that should remain
recorded for a long time to serve as a reference in future when needed.
MantisBT currently does this job and does it sufficiently well.
2. Something that is specific only to the current state of the source code
repository and becomes much less meaningful once the requested changes have
been made to the source code. GitHub pull requests are the right tool for
this.
If you consider this way of thinking you might agree that leaving things as
they currently are may be the best way. But feel free to explain a different
opinion if you want.
Thank you.
--
Denis Ovsienko
