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=---
