December 31, 2017
On Saturday, 30 December 2017 at 16:36:57 UTC, Iain Buclaw wrote:
>
> All open issues are actionable, and require some action.  They are not noise, and many issues whose fix requires a change in language specification or semantics are understandably left to the few who have the authoritative to make such final decisions on whether it should be accepted or rejected.
>
> Age of issue is not a big deal.  In fact I see it as a good sign that at least issues are left to breathe while we wait and understand the impact or urgency of it.  As opposed to jumping in and fixing issues immediately without taking due diligence on the wider picture it affects.

Is this a problem with triage?

i.e. like a hositpital emergency ward chaos rules, cause nobody is on duty triaging.

How does a contributor prioritise their contribution to items in bugzilla?

Or is it perhaps a tooling problem? (i.e. bugzilla lacks features that are needed).

Or is it a problem with not having enough people on duty, triaging?

Or is it a problem with just too many patients coming in?

Or .. ??
December 31, 2017
On 12/30/2017 04:07 AM, IM wrote:
> I like what the D foundation did to the website, the language and library docs, the Learn section, the forums, the resources ... etc. That definitely gives the impression of maturity.

As far as I'm aware, the foundation isn't too active in those areas; unless Vladimir or Seb are on their payroll now. Maybe the foundation pays the electricity bills, but the work is done by volunteers.
December 31, 2017
On 31 December 2017 at 02:07, codephantom via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Saturday, 30 December 2017 at 16:36:57 UTC, Iain Buclaw wrote:
>>
>>
>> All open issues are actionable, and require some action.  They are not noise, and many issues whose fix requires a change in language specification or semantics are understandably left to the few who have the authoritative to make such final decisions on whether it should be accepted or rejected.
>>
>> Age of issue is not a big deal.  In fact I see it as a good sign that at least issues are left to breathe while we wait and understand the impact or urgency of it.  As opposed to jumping in and fixing issues immediately without taking due diligence on the wider picture it affects.
>
>
> Is this a problem with triage?
>
> i.e. like a hositpital emergency ward chaos rules, cause nobody is on duty triaging.
>
> How does a contributor prioritise their contribution to items in bugzilla?
>

Either:
1. By picking up an issue that you have a vested interest in seeing fixed.

2. Feel free to look at the list of regressons.
    https://issues.dlang.org/buglist.cgi?bug_severity=regression&component=dmd&list_id=218477&query_format=advanced&resolution=---

Bigger projects or features are delegated between the core maintainers, or if a champion comes to take the reigns, then they have the freedom to go ahead.  For everything else, it is pretty much a free-for-all in terms of what you want to get fixed.  Almost nobody is being paid to contribute to the language here.
December 31, 2017
On Sunday, 31 December 2017 at 02:06:03 UTC, Iain Buclaw wrote:
>
> 2. Feel free to look at the list of regressons.
>     https://issues.dlang.org/buglist.cgi?bug_severity=regression&component=dmd&list_id=218477&query_format=advanced&resolution=---
>

"This list is too long for Bugzilla's little mind"

Mmm..just imagine how our human mind reacts then ;-)

But... as you point out...some 'filtering' makes it 'seem' a little less daunting ;-)


December 30, 2017
On 12/30/2017 6:42 AM, Muld wrote:
> In contrast this same problem exists for Bugzilla. You say it's working cause it's better than using notepad or some other stupid shit. Bugzilla isn't the issue, it's the fact the people maintaining it aren't willing to commit to anything and leave issues open that shouldn't be left open. That just results in noise making it difficult to see what actual issues are. I'm not even talking about duplicate entries as you seem to have have misunderstood.

Anyone can contribute to bugzilla with reasoned advice about what to do with various issues, and can review PRs. The people responsible are, well, anyone who wants to be.

Please join and help out.
December 31, 2017
On Sunday, 31 December 2017 at 05:43:57 UTC, Walter Bright wrote:
> On 12/30/2017 6:42 AM, Muld wrote:
>> In contrast this same problem exists for Bugzilla. You say it's working cause it's better than using notepad or some other stupid shit. Bugzilla isn't the issue, it's the fact the people maintaining it aren't willing to commit to anything and leave issues open that shouldn't be left open. That just results in noise making it difficult to see what actual issues are. I'm not even talking about duplicate entries as you seem to have have misunderstood.
>
> Anyone can contribute to bugzilla with reasoned advice about what to do with various issues, and can review PRs. The people responsible are, well, anyone who wants to be.
>
> Please join and help out.

While we are discussing it here, could you please let me know what the bug triage process for each release cycle is? Is it random that anyone picks up whatever bug s/he feels like fixing? Or is it that if contributors will contribute X number of patches this cycle, then there is some sort of guidance and direction of this effort towards fixing some high priority bugs?
December 30, 2017
On 12/30/2017 11:23 PM, IM wrote:
> While we are discussing it here, could you please let me know what the bug triage process for each release cycle is? Is it random that anyone picks up whatever bug s/he feels like fixing? Or is it that if contributors will contribute X number of patches this cycle, then there is some sort of guidance and direction of this effort towards fixing some high priority bugs?

Bugs are ranked by severity, but generally what gets fixed are bugs that a particular person self-selects an interest in fixing it.

Often people who just want to help out will peruse the buglist looking for issues that match their skill levels that they can fix.

December 31, 2017
On Saturday, 30 December 2017 at 14:42:45 UTC, Muld wrote:
> On Saturday, 30 December 2017 at 06:55:13 UTC, Walter Bright wrote:
>> It's not like we have a shortage of bugzilla issues and are wondering what to do next.
>
> Yah there are a ton of Bugzilla issues, that's the problem. More than half of them aren't "actionable" as you put it.
>
> Here's the problem, look at something like Rust:
>
> Pull requests? 95 open, it's about the same as Dlang, But if you go to the last page...
>
> https://github.com/rust-lang/rust/pulls?page=4&q=is%3Apr+is%3Aopen
>
> Look at that the oldest one is from October 15th, 20_17_.
>
> Now we go to DMD...
>
> https://github.com/dlang/dmd/pulls?page=6&q=is%3Apr+is%3Aopen
>
> Oldest one is from January 17, 20_13_.

This is a problem that many of us are working on fixing. The main reason many of these old zombie PRs stick around is that historically, people are hesitant to close things (for a variety of social reasons, I feel). While there is still the slightest chance that something might someday be merged, it is kept open. Rust is a lot more aggressive about closing bad or outdated PRs and either guiding PRs that need work to get to a mergeable state, or closing them and communicating that this is not the correct way to go. I watched a talk by a Rust contributor specifically on this point awhile ago - they have a bot that does a lot of the PR closure work to get around the fact that people are hesitant to be the "bad guy" and tell someone that their work is not good enough. D needs to get much better at this, and I think things are happening - slowly. The bad optics and demoralizing effect of letting things sit forever without definitive action outweighs the potential loss from being more aggressive about closing or merging.
December 31, 2017
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:

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.

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.

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.

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.
December 31, 2017
On Sunday, 31 December 2017 at 09:37:35 UTC, Meta wrote:
> On Saturday, 30 December 2017 at 14:42:45 UTC, Muld wrote:
>> On Saturday, 30 December 2017 at 06:55:13 UTC, Walter Bright wrote:
>>> It's not like we have a shortage of bugzilla issues and are wondering what to do next.
>>
>> Yah there are a ton of Bugzilla issues, that's the problem. More than half of them aren't "actionable" as you put it.
>>
>> Here's the problem, look at something like Rust:
>>
>> Pull requests? 95 open, it's about the same as Dlang, But if you go to the last page...
>>
>> https://github.com/rust-lang/rust/pulls?page=4&q=is%3Apr+is%3Aopen
>>
>> Look at that the oldest one is from October 15th, 20_17_.
>>
>> Now we go to DMD...
>>
>> https://github.com/dlang/dmd/pulls?page=6&q=is%3Apr+is%3Aopen
>>
>> Oldest one is from January 17, 20_13_.
>
> This is a problem that many of us are working on fixing. The main reason many of these old zombie PRs stick around is that historically, people are hesitant to close things (for a variety of social reasons, I feel). While there is still the slightest chance that something might someday be merged, it is kept open. Rust is a lot more aggressive about closing bad or outdated PRs and either guiding PRs that need work to get to a mergeable state, or closing them and communicating that this is not the correct way to go. I watched a talk by a Rust contributor specifically on this point awhile ago - they have a bot that does a lot of the PR closure work to get around the fact that people are hesitant to be the "bad guy" and tell someone that their work is not good enough. D needs to get much better at this, and I think things are happening - slowly. The bad optics and demoralizing effect of letting things sit forever without definitive action outweighs the potential loss from being more aggressive about closing or merging.

Yes, Dlang-bot was able to detect stalled issues for a while, but we didn't turn this on for all repositories. I have just enabled it:

https://github.com/dlang-bots/dlang-bot/pull/153

For the moment, it is just labelling issues with e.g. "needs work", "needs rebase", "stalled", "stalled-stable".
In a next stage it will start to actively ping people or close PRs.
Also automatically rebasing PRs if there are no conflicts is on the radar (the GitHub UI is quite conservative in this regard).