On 6/15/14, 11:46 AM, Dicebot wrote:
Big problem with GitHub issues is how simplistic those are. All
Simplistic they are indeed. But how does that detract from the utility
of the product. As programmers we are may be drawn to complexity, but
some things need not be complex to be effective.
categorization is done by labels with no internal differentiation,
advanced search queries are not possible. Also bugzilla is self-hosted
solution we have full control about and with GitHub you can only rely on
what external API exposes.
True, we do not have access to anything but the external API, however I
don't see that as a limiting factor. When I conduct a search in DITS, I
effectively search through labels. Of course those labels present
themselves as data fields/values in some row of a table but they are
labels none the less. If I want to find issues filed under multiple
labels, i simply include all labels of interest in my search. The same
is possible in GitHub, except they are presented right there on the
screen for immediate access. Want to know how many "bug" request were
"closed" as "invalid" or "wontfix"? Click on the labels and walla, your
search is complete. I have had experienced zero issues finding
information on GitHub, in spite of their overly simplistic interface.
As for internal differentiation of labels... A label is simply a label.
It has no differentiation or meaning except that applied to it by the
community. Marking something as
Product: D
Component: DMD
Version: D1 & D2
Hardware: All All
is absolutely no different than creating the labels D1, D2, and All in
the DMD repo and assigning all three labels to the issue. The only thing
that gives increase meaning to the labels any label (P1, P2, etc.), is
the value we, the users, assign to them. As far as I can see the only
thing GitHub is missing is a way to vote up the value of a label.
Also consider effort needed for moving all issues from existing database
and breaking routine workflow of all active dmd/Phobos developers.
Breaking what routine workflow? You can claim that if it's required to
file an issue in DITS before anything can be done on GitHub but that's
not the case. You can also claim that if every issue resolved via GitHub
is explicitly linked to it's originating issue on DITS but that's not
the case either.
As for the effort to move the issues I'm sure there is a process for
automatically moving the DITS records to GitHub. And if there isn't, I'm
not against doing the work myself.
Personally I don't think this is as much of an issue. Issues don't get
much attention because there are only few people looking at them (other
than own issues). Most D users don't have any reason to do so.
You are quite correct, most people will only work on what they want to
work on. But I think a lot of these issues are ignored because they are
just not being seen. This move may not motivate any specific person to
work on any specific bug but it integrates the two processes, and
automates some of the more often neglected trivialities. It also has the
added benefit of always visible so it has the positive effect of being a
constant reminder.
