What don't you switch to GitHub issues

[Jonathan M Davis]

On Sunday, December 31, 2017 11:18:26 Seb via Digitalmars-d wrote:
> On Saturday, 30 December 2017 at 02:50:48 UTC, Adam D. Ruppe
>
> wrote:
> > On Saturday, 30 December 2017 at 02:37:24 UTC, IM wrote:
> >> Just curious, why Bugzilla and not something else?
> >
> > Bugzilla was the most well-known solution at the time. Keep in
> > mind the D bugzilla has been around since 2006. As far as I
> > understand it, migration at this point is deemed a big pain.
>
> No it wouldn't be a big pain. There are many tools for
> automatically migrating issues from Bugzilla. The only thing
> depending on Bugzilla is the changelog generator, but it's API
> calls to Bugzilla can be replaced with GitHub API calls within an
> hour.
> So the entire migration could be easily done in a lot less than a
> day.
>
> The only reason we still use Bugzilla is that the core people are
> used to it. Here are a couple of the common arguments:

I honestly am unaware of any reason why using github issues would be
superior to bugzilla except that some folks expect projects on github to use
github issues for bug reports. And plenty of projects on github don't use
github issues.

If we were starting from scratch, then maybe it would make sense to use
github issues instead of our own bugzilla, but given that we already have
bugzilla, it works just fine, and github issues really don't seem to offer
anything significant that would make them superior to using bugzilla, I
really don't see any reason to switch.

> 1) Bugzilla is our, we don't want to depend on GitHub
>
> The D ecosystem already heavily depends on GitHub. Exporting the
> issues from GitHub would be easy. Besides there is only one
> person with access to the Bugzilla server.

Yes, it would be a pain to switch away from github at this point, but if
github went down permanently tomorrow, it would just be an annoying
roadblock. We almost certainly wouldn't lose any code (at most, a few
commits, if no one pulled recently enough), and we wouldn't lose any bug
reports. We'd have to go to the trouble of setting up our own gitlab or
switching to bitbucket or something like that and pointing all of the
automated stuff to the new place, and it would be a royal pain, but we
wouldn't lose any information. If all of the issues were on github, and
github went away, we'd lose them.

Sure, github is unlikely to go away, but I see no reason to tie ourselves to
it thoroughly enough that we're going to lose data if they go away -
especially since I don't actually see any benefit in switching to github
issues.

> 2) GitHub only has per registry issues
>
> Bugzilla uses components too, they don't support global issues
> either. Besides if that's required one could easily create a meta
> repository for such global tasks.

Well, it wouldn't be the end of the world if the issues were separated by
repos, but having them in a single place where they can be searched together
is beneficial, and it makes it easier to switch an issue between components
when it turns out that it was assigned to the wrong component. Certainly,
switching to github would be negative in this regard, even if it wouldn't be
a deal breaker.

> 3) Bugzilla's issue tracker is more sophisticated
>
> Sure, but does this help when you loose out on many contributors?
> GitHub even has build tools and sites that let anyone discover
> "easy" issues if they are labeled accordingly. It's free
> marketing.

I seriously doubt that we've lost many (if any) contributors because we
don't use github issues, and plenty of other projects use github without
using it as their issue tracker.

> FYI I asked the same question 1 1/2 years ago:
> https://forum.dlang.org/post/ezldcjzpmsnxvvncncsi@forum.dlang.org
>
> Since then, for example, GitHub got voting for issues, but
> Bugzilla lost it.

To be honest, no one seems to pay attention to voting on issues. Having a
voting system is theoretically beneficial, but in practice, it doesn't seem
to have generally had much effect on what gets fixed (not for us anyway).
Almost inevitably, the stuff that actually gets many votes is the hard stuff
that is likely to be sitting around whether folks vote on it or not. Plenty
of those issues really should be fixed sooner, but having a lot of votes on
them isn't what does it. e.g. issue #314 sat around for ages in spite of
everyone agreeing that it needed to be fixed, because it a was a hard
problem, and no one stepped up to the plate to take care of it. The fact
that it had a bunch of votes really didn't matter.

In any case, I have yet to see much on argument for why we would even want
to switch to github issues. It just seems like some folks think that for
some reason, the fact that we have our code up on github means that we
should have our issue tracker there too and that it's weird that we don't.
Personally, I don't see any reason to go to the trouble of searching and
invalidating years worth of links just because using github issues seems to
be the hip thing to do. It needs to provide serious value over using our own
bugzilla, and I am unaware of anything that it does that is significantly
better than using bugzilla.

- Jonathan M Davis