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/ezldcjzpmsnxvvncn...@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
