[dokuwiki] Re: Move the issue & bug tracking to Github
- From: Anika Henke <anika@xxxxxxxxxxxxxxx>
- To: dokuwiki@xxxxxxxxxxxxx
- Date: Mon, 27 Aug 2012 09:29:47 +0100
Hi all,
I generally like the idea of GitHub as a bug tracker and would
theoretically prefer it over Flyspray, mainly because it is linked to
the repository which makes a few things slicker.
But I think it might not be worth it...!
Flyspry is quite good, but not perfect. So is the GitHub issue tracker.
The effort and time you need to move issues over is the main drawback to
me. So, in case we go for it, we should *not* just do it but *plan* it
properly. Because we need to avoid someone half finishing and then
leaving us because it's not as easy as they predicted (similar to the
jQuery integration).
* markdown parsing makes it hard for novice users to simply
copy'n'paste examples, code snippets or anything else that conflicts
with markdown
How many "novice" users are there reporting bugs actually? In my
experience, no novice users are really reporting bugs, because EVERY
issue tracker is way beyond them. But I could be wrong there.
I'd say there are quite a few novice users reporting bugs.
But I wouldn't say that speaks against Markdown.
* no way to attach a file to bug reports (this is the most serious
thing IMHO)
Yup. You're right there and if this is happening often, it's a show
stopper.
Yes, I agree.
But I can imagine that they will integrate it someday!?
A solution could be to tell users to use gist.github.com for text files
and an image upload service for images. Not very user-friendly, though. :-/
Why not postpone this discussion until they have integrated it? Is there
any feature request for it where we can see what the GitHub team
responded to that so far and if it's likely they will implement it?
* I'm not sure if non-committers are able to attach tags and thus help
categorizing tickets
That's true. But: We require registration for adding new issues - so
we're not having any "non-commiters" and I'd like to ask, how good - in
your experience - are the user-submitted categories actually?
The user-submitted categories are usually *very good*. We very rarely
need to change them.
Having said that, I don't think not having any user-submitted categories
is such a big issue. It would be better to have them, yes, but they are
not vital, because it will probably cost a developer two minutes to add
them.
But thinking about it, it is true, that we will loose the two categories
Flyspray currently has: an issue type (bug, feature request, todo) and
an issue category (ACL, Template, etc.). As long as we're not using tags
like "ACL - bug", "ACL - Feature request", etc. (which we will certainly
NOT be doing) we will lose that. Again, how important is that?
That won't be a problem at all. Have one set of severity/priority tags
(I never understood the difference between those two), one set of type
tags (bug, feature, todo) and another set of category tags. And then you
just add three tags to an issue (nicely colour-coded), so e.g. "ACL",
"Feature request" and "priority: medium".
We don't have a specialized team in which we could auto-assign ACL
issues to the ACL team and template issues to the template team
(actually, we have a template team. Bad example ;) ).
We have a template team?
I guess that's dysfunctional then. ;-)
* we'd need to write an export/import script to move all previous
tickets to github (any volunteers?)
If I can find the time, I'll do that.
As I said before, please *plan* it properly. Otherwise, thanks. :)
* we would have ID clashes for the 100 or so existing ticket IDs (from
pull requests)
Isn't that what was meant by talking to github about starting at issue
ID #5000 or so?
No, the point is that we *already have issues* in the GitHub issue
tracker, because pull requests are handled as issues.
But as those would be clashes from *early* tickets (from 2005), I don't
think that's a big issue. (And there are ways around that.)
* as far as I know, existing developers are familar and happy with
flyspray's features (correct me if I'm wrong)
At least I am happy with Flyspray. But I wouldn't say that's an argument
at all. ;-) I'm happy with GitHub, too.
* there's no easy way to send a weekly bug summary mail to the
mailinglist
No easy way, but a way after all (using github's API).
I never read the weekly bug summary, because I read the bug repots when
they appear in my feed reader. ;-)
But there is no RSS feed for GitHub issues, is there? :(
* we rely with a crucial part of our devel process on a 3rd party that
proved to be deaf to our support pleas before
But wouldn't that be even worse for the actual code, that is already in
"their hands"?
I'm with Dennis here. We rely heavily on GitHub already.
Although because git is decentralised/distributed, that's not much of an
issue, because it's extremely easy to work on it if GitHub is
temporarily faulty or to move to a different service. (BTW, do we have a
mirror? Shouldn't we have one?)
I personally think the best solution would be a "distributed bug
tracker", i.e. bug reports should be kept on a branch of a repository,
so they would always move with the repository.
There are a few solutions out there which do that, but until all the big
players decide on the same format how to keep them and have interfaces
for them, it's not much worth. Although, if you have your own interface
running somewhere, that's less of an issue.
Cheers,
Anika
--
DokuWiki mailing list - more info at
http://www.dokuwiki.org/mailinglist
Other related posts:
