On Sunday, 24 January 2021 at 13:00:41 UTC, Max Haughton wrote:
> On Sunday, 24 January 2021 at 12:36:16 UTC, Timon Gehr wrote:
>> On 18.01.21 10:21, Mike Parker wrote:
>>> Thanks once more to Symmetry Investments, we have a new paid staffer in the D Language Foundation family.
>>> 
>>> Though I call him my "assistant", I can already see he will be more than that. He'll be taking some things off my shoulders, sure, but he also has ideas of his own to bring into the mix. Adding him to the team is certain to be a boon for the D community.
>>> 
>>> So, a word of warning to those of you who haven't heard from me in a while pestering you for blog posts: get used to the name "Max Haughton".
>>> 
>>> And congratulate him while you're at it!
>>
>> Congratulations. However, Max seems to be just closing all enhancement requests on bugzilla as invalid. This is the behavior of a vandal. Please stop. Any policy that requires this is ill-advised. Issues are valuable and binning them like this is disrespectful to the time of the reporters.
>
> I was going through trying to close things that are either not bugs anymore because they haven't been touched from 2010 and they've been fixed by entropy, or language changes which will never be looked at again because they aren't DIPs. They're still in public record but fundamentally they're just not useful anymore - I was literally just going through bugs FILO and trying to either reproduce or at least characterise whether they even can be acted on by the foundation.
>
> It's entirely possible I was overzealous and if I was, obviously reopen them but ultimately the enhancements have to go through a DIP because it's not 2012 anymore.
>
> I also updated Stephen S's shared-delegate race condition bug to have a test case that actually compiles, and that's from 2010 - theadsan catches it now although it doesn't work with @safe either so I'm not sure whether we should be embarrassed or not.

Imo it's reasonable to close or archive issues that are older than 10 years.
#controversial

Reason:
If it has been almost a hundred releases since the issue was created, the probability of it even being reproducible is quite small, and the quality of the fix might be reduced.

While I do agree that "an issue is an issue regardless of time" it's a bit misleading when you get down to the details. I think you know what I mean.

Take a moment and think about every single change that has happened since 2010:

2.095.0 (Jan 01, 2021)
2.094.2 (Nov 20, 2020)
2.094.1 (Oct 18, 2020)
2.094.0 (Sep 22, 2020)
2.093.1 (Aug 15, 2020)
2.093.0 (Jul 07, 2020)
2.092.1 (Jun 10, 2020)
2.092.0 (May 10, 2020)
2.091.1 (Apr 17, 2020)
2.091.0 (Mar 08, 2020)
2.090.1 (Feb 06, 2020)
2.090.0 (Jan 05, 2020)
2.089.1 (Dec 14, 2019)
2.089.0 (Nov 02, 2019)
2.088.1 (Oct 11, 2019)
2.088.0 (Sep 01, 2019)
2.087.1 (Aug 04, 2019)
2.087.0 (Jul 01, 2019)
2.086.1 (Jun 15, 2019)
2.086.0 (May 04, 2019)
2.085.1 (Apr 05, 2019)
2.085.0 (Mar 01, 2019)
2.084.1 (Feb 09, 2019)
2.084.0 (Jan 01, 2019)
2.083.1 (Dec 08, 2018)
2.083.0 (Nov 01, 2018)
2.082.1 (Oct 10, 2018)
2.082.0 (Sep 01, 2018)
2.081.2 (Aug 12, 2018)
2.081.1 (Jul 10, 2018)
2.081.0 (Jul 01, 2018)
2.080.1 (Jun 07, 2018)
2.080.0 (May 01, 2018)
2.079.1 (Apr 14, 2018)
2.079.0 (Mar 01, 2018)
2.078.3 (Feb 15, 2018)
2.078.2 (Feb 07, 2018)
2.078.1 (Jan 21, 2018)
2.078.0 (Jan 01, 2018)
2.077.1 (Nov 29, 2017)
2.077.0 (Nov 1, 2017)
2.076.1 (Oct 09, 2017)
2.076.0 (Sep 1, 2017)
2.075.1 (Aug 11, 2017)
2.075.0 (Jul 19, 2017)
2.074.1 (May 30, 2017)
2.074.0 (Apr 10, 2017)
2.073.2 (Mar 09, 2017)
2.073.1 (Feb 16, 2017)
2.073.0 (Jan 22, 2017)
2.072.2 (Dec 31, 2016)
2.072.1 (Nov 30, 2016)
2.072.0 (Oct 30, 2016)
2.071.2 (September 19, 2016)
2.071.1 (June 27, 2016)
2.071.0 (Apr 5, 2016)
2.070.2 (Mar 3, 2016)
2.070.1 (Feb 27, 2016)
2.070.0 (Jan 27, 2016)
2.069.2 (Dec 3, 2015)
2.069.1 (Nov 11, 2015)
2.069.0 (Nov 3, 2015)
2.068.2 (Sep 23, 2015)
2.068.1 (Sep 06, 2015)
2.068.0 (Aug 09, 2015)
2.067.1 (Apr 25, 2015)
2.067.0 (Mar 24, 2015)
2.066.1 (October 15, 2014)
2.066.0 (August 18, 2014)
2.065.0 (February 24, 2014)
2.064 (November 5, 2013)
2.063 (May 28, 2013)
2.062 (Feb 18, 2013)
2.061 (Jan 1, 2013)
2.060 (Aug 2, 2012)
2.059 (Apr 12, 2012)
2.058 (Feb 14, 2012)
2.057 (Dec 13, 2011)
2.056 (Oct 26, 2011)
2.055 (Sep 4, 2011)
2.054 (Jul 10, 2011)
2.053 (May 12, 2011)
2.052 (Feb 17, 2011)
2.051 (Dec 21, 2010)
2.050 (Oct 29, 2010)
2.049 (Sep 13, 2010)
2.048 (Aug 8, 2010)
2.047 (Jun 11, 2010)
2.046 (May 10, 2010)
2.045 (May 4, 2010)
2.044 (Apr 30, 2010)
2.043 (Apr 6, 2010)
2.042 (Mar 19, 2010)
2.041 (Mar 7, 2010)
2.040 (Jan 29, 2010)
2.039 (Jan 1, 2010)

Keep this changelog in your mind while you try the fix the bug.

Proposed solution:
Archive issues older than 10 years (and maybe some critera based on latest updated). If they are relevant, it's the authors responsibility to update the issue so that it's reproducible in the latest release.
#reasonablebutcontroversial

We are only a certain number of people being able to fix issues, we have to be realistic.

Critical / high impact bugs should be fixed first, otherwise they are not critical neither high impact, and should be reclassified.

#peace

On 25.01.21 07:46, Imperatorn wrote:
> Proposed solution:
> Archive issues older than 10 years (and maybe some critera based on latest updated). If they are relevant, it's the authors responsibility to update the issue so that it's reproducible in the latest release.
> #reasonablebutcontroversial

Just no. Reproducibility is a criterion. Age isn't.

On Monday, 25 January 2021 at 06:59:00 UTC, ag0aep6g wrote:
> On 25.01.21 07:46, Imperatorn wrote:
>> Proposed solution:
>> Archive issues older than 10 years (and maybe some critera based on latest updated). If they are relevant, it's the authors responsibility to update the issue so that it's reproducible in the latest release.
>> #reasonablebutcontroversial
>
> Just no. Reproducibility is a criterion. Age isn't.

Sure, but how do you define it?

On 1/24/2021 10:46 PM, Imperatorn wrote:
> Imo it's reasonable to close or archive issues that are older than 10 years.

We are not going to do that just because they are old.

If a bug still exists in the current DMD, the bug report stays open.

On Monday, 25 January 2021 at 10:39:14 UTC, Walter Bright wrote:
> On 1/24/2021 10:46 PM, Imperatorn wrote:
>> Imo it's reasonable to close or archive issues that are older than 10 years.
>
> We are not going to do that just because they are old.
>
> If a bug still exists in the current DMD, the bug report stays open.

I can understand why, I really do.

But, at the same time, I guess it could be a bit demoralizing you know?

Like, I don't even know who will be alive in 10 years. There's something symbolical about a decade somehow. If it takes so long for an issue to be looked at, maybe it's not really a big deal. And if it *is*, it's even worse of course, so I hope it's just that people are over reporting minor stuff.

On the other hand, how do you solve an issue if you're not allowed to see it (ie, your argument)? Well, that's a fair point of course!

Let's put it like this:
What *should* the limit be? 20 years? 25? 75?

Whatever the limit, I'm pretty sure that most reporters would like to see an issue fixed before the end of their (average) lives at least. I think that's a reasonable assumption.

It's kinda obvious when you push it to the "limit" that *some* kind of limit has to be put in place.

Maybe it's too easy to report an issue? I don't know.

The obvious solution is to get more people involved in D, I'm trying!

I advertise it to friends and co-workers, write on various sites, try to answer questions on Reddit, FB, Discord etc etc. But there's just so much one person can do..

I have no good idea what the optimal solution should be, but I bet *someone* out there has though about it. I hope so :)

On 25.01.21 11:05, Imperatorn wrote:
> On Monday, 25 January 2021 at 06:59:00 UTC, ag0aep6g wrote:
>> On 25.01.21 07:46, Imperatorn wrote:
>>> Proposed solution:
>>> Archive issues older than 10 years (and maybe some critera based on latest updated). If they are relevant, it's the authors responsibility to update the issue so that it's reproducible in the latest release.
>>> #reasonablebutcontroversial
>>
>> Just no. Reproducibility is a criterion. Age isn't.
> 
> Sure, but how do you define it?

If you need reproducibility to be defined, please stay away from the issue tracker.

On 25.01.21 13:48, Imperatorn wrote:
> On Monday, 25 January 2021 at 10:39:14 UTC, Walter Bright wrote:
>> On 1/24/2021 10:46 PM, Imperatorn wrote:
>>> Imo it's reasonable to close or archive issues that are older than 10 years.
>>
>> We are not going to do that just because they are old.
>>
>> If a bug still exists in the current DMD, the bug report stays open.
> 
> I can understand why, I really do.
> ...

Great, case closed.

On Monday, 25 January 2021 at 13:04:42 UTC, Timon Gehr wrote:
> On 25.01.21 11:05, Imperatorn wrote:
>> On Monday, 25 January 2021 at 06:59:00 UTC, ag0aep6g wrote:
>>> On 25.01.21 07:46, Imperatorn wrote:
>>>> Proposed solution:
>>>> Archive issues older than 10 years (and maybe some critera based on latest updated). If they are relevant, it's the authors responsibility to update the issue so that it's reproducible in the latest release.
>>>> #reasonablebutcontroversial
>>>
>>> Just no. Reproducibility is a criterion. Age isn't.
>> 
>> Sure, but how do you define it?
>
> If you need reproducibility to be defined, please stay away from the issue tracker.

I don't mean the definition of that obviously...

On Monday, 25 January 2021 at 12:48:48 UTC, Imperatorn wrote:
> But, at the same time, I guess it could be a bit demoralizing you know?

That's true. Sometimes, reality is demoralizing. That doesn't mean we should hide our heads in the sand and ignore it.

> It's kinda obvious when you push it to the "limit" that *some* kind of limit has to be put in place.

Is it really, though?

The purpose of a bug report is to provide useful information to anyone who may want to fix the bug in the future. It follows that as long as (a) the information remains useful and (b) there is a possibility someone might want to fix the bug in the future, the bug report should remain open.

On Mon, Jan 25, 2021 at 08:03:53PM +0000, Paul Backus via Digitalmars-d-announce wrote:
> On Monday, 25 January 2021 at 12:48:48 UTC, Imperatorn wrote:
> > But, at the same time, I guess it could be a bit demoralizing you know?
> 
> That's true. Sometimes, reality is demoralizing. That doesn't mean we should hide our heads in the sand and ignore it.
[...]

I think we're looking at this in the wrong way.  While we should certainly work on fixing bugs and thereby improve the language, it's a mistake to try to optimize the number of bugs as a metric.  Reducing the number of bugs equates to improvements in the language *only when the closed bugs correspond to changes that improve the language*.  Reducing the number of bugs as a metric on its own does not necessarily equate to language improvement.

For example, we could declare by pure fiat that starting from today, D has zero bugs, and implement this by closing all bugs in bugzilla.  Does that mean that D is now perfect?  Of course not.  All it means is that we've buried our heads in the sand and pretended that there are no more bugs.  The language, however, remains in exactly the same state as it was yesterday, warts and all.  The act of closing the bugs *has not improved the language by one bit*.

Now look at this another way.  Suppose we start with the current state of the language, but with zero reported bugs.  Then we open the floodgates for people to try out the language and report bugs.  Every bug report, every issue, that gets filed tells us something that we weren't aware of before: an area where the language could be improved. IOW, every bug report is an *opportunity for improvement*.  If after we opened the floodgates no reports are filed, that doesn't mean the language is perfect; rather, it means the language is dead and nobody cares enough about it to file bugs anymore. Or the language has reached a dead-end and cannot be improved any further. The fact that people are still filing bugs means (1) the language is still alive, and (2) there is plenty of room for improvement. I.e., we're not at a dead-end. There's plenty more to look forward to.

So don't look at the bug count as some kind of liability to rid ourselves of by whatever means possible; rather, look at it as a sign of life and the opportunity to grow.


T

-- 
MSDOS = MicroSoft's Denial Of Service