State of issues.dlang.org

[ag0aep6g via Digitalmars-d]

On 10/25/2016 05:17 AM, Jacob wrote:
> I sort of feel that issues.dlang.org is an unmaintained mess. Anyone has
> access to it every aspect of editing anyone else's issue, so anyone
> could be added really without any oversight.

Yet there's very little vandalism going on, aside from the occasional 
spam. We have oversight in the form of people watching every change that 
happens on the bug tracker.

> There's no editing one's
> comments so I often see people making multiple posts to themselves to
> add more information or to correct themselves. That's just a minor
> issue.

I don't think that's really an issue. Bugzilla sends out notification 
emails. An edit feature would complicate that. You'd have to read diffs 
instead of a human-written correction. I think that might be more 
annoying than having multiple comments. If any kind of discussion 
happens you're going to have many comments anyway.

> There are 16k issues (I'm guessing every ID basically means a
> unique issue) for DMD alone.

That's not for dmd alone, it's for all components: dlang.org, dmd, 
druntime, installer, phobos, tools, visuald. The 16000 issues also 
include fixed and otherwise closed ones.

Just dmd has about 3000 open issues at the moment [1]. If we filter out 
enhancements (so we have just actual bugs), the number goes down to 
about 2000 [2]. That's still a lot, but way less than 16000.

> It has some issues where an individual made
> a comment, no tags or anything was set, and then 2-3 years later its
> remained like that til someone reserves it with a change or comment Only
> for there only to be that one additional comment then the issue gets
> buried for another year or so.

Well, that's because there are not enough people to fix the issues. I 
think especially the compiler team could use more hands.

> There are so many like this and it is
> unclear what exactly the issue is or what needs to be done with it.

If the issue description is lacking, ask for clarification. If the 
submitter doesn't respond and it's really not clear what the issue is 
about, close it. Leave comments explaining your actions.

> Almost every issue is like this as well. There are some discussions in
> some of the issues but a lot of the times nothing seems to be done about
> them.

Sadly, yeah. But that's not an issue with Bugzilla, but an issue of too 
many bugs for too few developers.

> Anyways for the site itself, it seems to be lacking features. When
> viewing issues as a list there isn't that much information about the
> issue, other than the summary.

You can change the columns by clicking on "change columns" below the list.

[...]
> So now there are this many issues and it probably won't be an easy task
> to go through all of them and determine which ones are actually valid.

Yeah, one at a time. Baby steps.

> To weed out all the issues that can simply be deleted.

I don't think there actually are that many. I would guess that most bugs 
are actually bugs and most enhancement requests probably need a decision 
by Walter or Andrei.

> It would be nice
> to know what needs to be done for an issue, if it is a small enhancement
> and can simply get a PR to add the functionality.

Easy bugs are usually fixed quickly. Maybe there are some (or many) open 
easy bugs, but when someone can figure that they're easy, that person 
can probably also quickly fix them. So there's not really a list of 
simple stuff.

However, Andrei has recently made an effort tagging issues with 
"bootcamp" [3]. He deems those issues to be fit for newcomers to D. But 
they're not necessarily simple. Might be small or medium sized projects 
of themselves.

For enhancements, you might want to get confirmation first that it's 
going to be accepted, before jumping in and implementing them. I.e., you 
need Walter or Andrei on board. There's a keyword for that: 
"preapproved" [4]. The "bootcamp" issues obviously also have been 
approved by Andrei.

> If it is a bit bigger
> of an enhancement and needs a DIP to add the functionality.

If that's so, I think it gets closed in Bugzilla. At least, that's what 
Andrei has done recently, if I remember correctly.

> Or whether
> an issue exists and how the issue needs to be handled. Is it a feature
> that was implemented incorrectly and needs to be reworked. Or was it
> possibly an oversight of a combination of features and a more thought
> out solution needs to be created, which might involve something more
> extreme as removing a previous feature.

The "severity" field covers this partially:

* enhancement: Not a bug, but a request for an additional feature or such.
* trivial: A bug that should be easy to fix (typos and such).
* minor, normal, major, critical: Greater levels of bugs.
* blocker: Mostly misused as far as I know. Should be blocking a 
release, is often used to indicate that the submitter's work is being 
blocked.
* regression: A new bug in an old feature.

Further than that, the submitter of a bug doesn't usually know how it 
came about. And working out the details is a large part of fixing a bug. 
So once someone has done that work, they can often also fix it. I'd say 
that's why you don't see many open bugs with details on how to fix them.

> Well wrote more than I planned to, didn't re-read it though, probably
> should considering I won't be able to edit it. Oh well.

Off topic: I consider editing to be an anti-feature in discussion 
software. In the worst (and most common) implementations, I just don't 
get an email update when someone edits their posts (looking at you, 
GitHub). Can be confusing when a larger correction or amendment is being 
done by edit. And small typos that don't affect the meaning of the 
message don't really need fixing, anyway.

> TLDR; The issue system in place right now needs to be removed and a
> better system with oversight put in place.

No. If anything, we need to tweak the process and/or Bugzilla.

> Rather than the wildwest it
> is now, with no oversight and issues existing for years before anyone
> looks at them. If anyone even ever looks at them. Some of them aren't
> even real issues and they just end up clogging the pipes, so to speak.

You can't implement oversight in software, you need more people. 
Bugzilla is ok as the software. Putting a moderation system in place 
would just mean that the moderation queue gets clogged instead of the 
issue list.

We could maybe make use of a "VERIFIED" status, different from "NEW". 
But the usefulness of that depends on how many unverified issues we 
have. And we don't know that because we don't have that status ;) If you 
care about this, you will probably have to champion the effort and go 
through lots of issues to apply the new status.

I think you're mistaken in thinking that no one looks at issues. I 
usually at least glance over newly filed ones, and often check if 
they're valid.


[1] 
https://issues.dlang.org/buglist.cgi?component=dmd&limit=0&list_id=211365&order=bug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=D&query_format=advanced&resolution=---

[2] 
https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&component=dmd&limit=0&order=bug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=D&query_format=advanced&resolution=---

[3] 
https://issues.dlang.org/buglist.cgi?keywords=bootcamp%2C%20&keywords_type=allwords&list_id=211370&query_format=advanced&resolution=---

[4] 
https://issues.dlang.org/buglist.cgi?keywords=preapproved%2C%20&keywords_type=allwords&list_id=211371&query_format=advanced&resolution=---