www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Please Congratulate My New Assistant

reply Mike Parker <aldacron gmail.com> writes:
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!
Jan 18 2021
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 18 January 2021 at 09:21:45 UTC, 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!


Welcome aboard Max! Let's make 2021 the year when D shines :)

(Also, general question:
Will the PR guys and Max be on Discord or Slack or will it be too 
much for them?)

Anyway, welcome 🎂
Jan 18 2021
next sibling parent reply M.M. <matus email.cz> writes:
On Monday, 18 January 2021 at 09:32:06 UTC, Imperatorn wrote:

 On Monday, 18 January 2021 at 09:21:45 UTC, Mike Parker wrote:

 [...]


 Welcome aboard Max! Let's make 2021 the year when D shines :)

 (Also, general question:
 Will the PR guys and Max be on Discord or Slack or will it be 
 too much for them?)

 Anyway, welcome 🎂


Great development in the D camp, indeed. It's great for a steady 
focused work on the language.

Is this (and the related PR people) a short-term initiative, or 
is the funding secured for a longer period?
Jan 18 2021
parent Mike Parker <aldacron gmail.com> writes:
On Monday, 18 January 2021 at 09:49:10 UTC, M.M. wrote:


 Is this (and the related PR people) a short-term initiative, or 
 is the funding secured for a longer period?


As far as I know this is long term.
Jan 18 2021
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 18 January 2021 at 09:32:06 UTC, Imperatorn wrote:



 (Also, general question:
 Will the PR guys and Max be on Discord or Slack or will it be 
 too much for them?)


That's up to them, but I guess Max probably will be.



 Jan 18 2021



  parent  Mike Parker <aldacron gmail.com>  writes:


On Monday, 18 January 2021 at 13:08:58 UTC, Mike Parker wrote:

 On Monday, 18 January 2021 at 09:32:06 UTC, Imperatorn wrote:



 (Also, general question:
 Will the PR guys and Max be on Discord or Slack or will it be 
 too much for them?)


 That's up to them, but I guess Max probably will be.


I should clarify that I was referring to Discord. They're on 
Slack already.



 Jan 18 2021



prev sibling  parent  Max Haughton <maxhaton gmail.com>  writes:


On Monday, 18 January 2021 at 09:32:06 UTC, Imperatorn wrote:

 On Monday, 18 January 2021 at 09:21:45 UTC, 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!


 Welcome aboard Max! Let's make 2021 the year when D shines :)

 (Also, general question:
 Will the PR guys and Max be on Discord or Slack or will it be 
 too much for them?)

 Anyway, welcome 🎂


I am on slack under my real name (IIRC) and I can found on the 
discord under the name "mhh__"

Feel free to ping me on either although there may be some latency 
because the notifications are completely broken on my phone.



 Jan 18 2021



prev sibling next sibling parent reply IGotD- <nise nise.com>  writes:


On Monday, 18 January 2021 at 09:21:45 UTC, 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!


What is the tasks of this new "assistant"?



 Jan 18 2021



  parent reply Max Haughton <maxhaton gmail.com>  writes:


On Monday, 18 January 2021 at 22:33:43 UTC, IGotD- wrote:

 On Monday, 18 January 2021 at 09:21:45 UTC, 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!


 What is the tasks of this new "assistant"?


It's looking like the things I'll be doing can be split under two 
major categories - the first is "just" generally doing whatever 
Mike needs doing (He's a busy man), and some more autonomous 
things like scouting for the blog. The second category is a bit 
looser, as there are some things I'd like to do that come under 
the community relations remit that aren't as structured - e.g. I 
am very interested in getting a proper working group together to 
try and iterate through designs properly rather than incremental 
DIPs.



 Jan 18 2021



 next sibling parent  Imperatorn <johan_forsberg_86 hotmail.com>  writes:


On Tuesday, 19 January 2021 at 00:12:49 UTC, Max Haughton wrote:

 On Monday, 18 January 2021 at 22:33:43 UTC, IGotD- wrote:

 On Monday, 18 January 2021 at 09:21:45 UTC, Mike Parker wrote:

 [...]


 What is the tasks of this new "assistant"?


 It's looking like the things I'll be doing can be split under 
 two major categories - the first is "just" generally doing 
 whatever Mike needs doing (He's a busy man), and some more 
 autonomous things like scouting for the blog. The second 
 category is a bit looser, as there are some things I'd like to 
 do that come under the community relations remit that aren't as 
 structured - e.g. I am very interested in getting a proper 
 working group together to try and iterate through designs 
 properly rather than incremental DIPs.


👍



 Jan 18 2021



prev sibling next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com>  writes:


On Tuesday, 19 January 2021 at 00:12:49 UTC, Max Haughton wrote:


 The second category is a bit looser, as there are some things 
 I'd like to do that come under the community relations remit 
 that aren't as structured - e.g. I am very interested in 
 getting a proper working group together to try and iterate 
 through designs properly rather than incremental DIPs.


That would be great!



 Jan 19 2021



  parent  Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com>  writes:


On Tuesday, 19 January 2021 at 09:33:26 UTC, Paolo Invernizzi 
wrote:

 On Tuesday, 19 January 2021 at 00:12:49 UTC, Max Haughton wrote:


 The second category is a bit looser, as there are some things 
 I'd like to do that come under the community relations remit 
 that aren't as structured - e.g. I am very interested in 
 getting a proper working group together to try and iterate 
 through designs properly rather than incremental DIPs.


 That would be great!


+1



 Jan 19 2021



prev sibling  parent  SealabJaster <sealabjaster gmail.com>  writes:


On Tuesday, 19 January 2021 at 00:12:49 UTC, Max Haughton wrote:

 The second category is a bit looser, as there are some things 
 I'd like to do that come under the community relations remit 
 that aren't as structured - e.g. I am very interested in 
 getting a proper working group together to try and iterate 
 through designs properly rather than incremental DIPs.


Excited to see what comes from this.



 Jan 19 2021



prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Welcome Max and congratulations!



 Jan 21 2021



  parent  Max Haughton <maxhaton gmail.com>  writes:


On Thursday, 21 January 2021 at 10:53:47 UTC, Walter Bright wrote:

 Welcome Max and congratulations!


Thanks everyone



 Jan 21 2021



prev sibling  parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


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.



 Jan 24 2021



  parent reply Max Haughton <maxhaton gmail.com>  writes:


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.



 Jan 24 2021



 next sibling parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 24.01.21 14:00, 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,


I can get behind this. You closed one of my issues that was fixed this 
way, but I don't usually report INVALID issues, this is why there is a 
WORKSFORME category.


 or language changes which will never be looked at 
 again because they aren't DIPs.


Of course they won't be looked at again if you claim they are invalid 
just by virtue of being enhancement requests. Obviously you looked at 
them now, so your reasoning here makes no sense. This is why there is an 
enhancement request category in the first place. They are not invalid 
issues, they are enhancement request issues.


 They're still in public record but 
 fundamentally they're just not useful anymore


Issues are not useful anymore when they are fixed or there is a good 
reason why they should not be fixed.


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


Why does it seem like people who are hired to help improve D instead 
always start closing bugzilla issues without actually fixing them? This 
is meaningless optimization of indicators that don't even mean what you 
seem to think they mean. It's a waste of time and resources.


 It's entirely possible I was overzealous and if I was, obviously reopen 
 them


I don't have time for that, I don't get notified for all of them, just 
the ones I reported or interacted with. I have no idea what other 
potentially valuable enhancement requests you closed with a 
condescending "INVALID" verdict just because they were enhancement requests.

Please reopen all enhancement requests that you closed even though they 
remain unfixed.


 but ultimately the enhancements have to go through a DIP because 
 it's not 2012 anymore.
 ...


That does not change what those enhancement requests are for, it just 
makes it a bit harder to fix them. Obviously, nowadays the proper way to 
get rid of enhancement requests is by pushing them through the DIP 
process (or perhaps just making a good point to the reporter why it 
would be a bad idea to implement them), but of course, that requires 
more work than a couple of clicks and button presses. Closing as invalid 
because it is an enhancement request is not a valid way to get rid of 
enhancement requests.

If you really want to enact a policy that new enhancement requests 
should be illegal, I guess DLF can do that even though it is obviously a 
stupid idea (a DIP is a lot more formal, a large bar to overcome, so you 
will lose a lot of ideas), but how about you at least don't close issues 
that were made at a time when this was the officially encouraged way to 
track ideas? IMNSHO it should stay this way, there is no reason to 
dislike enhancement requests. They don't have the same purpose as DIPs 
(and DIPs are sometimes even necessary to fix issues that are not 
enhancement requests, for example type system unsoundness).


 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.
 


There is certainly useful work to be done in the issue tracker. I am 
here objecting to certain systematic destructive practices that do not 
even have any upside. I wish this kind of behavior would stop forever. 
You are not the first person to engage into careless issue closing 
sprees. I think the underlying issue is a bad understanding of the value 
of issues in the issue tracker and some sort of irrational assignment of 
cost to open issues. Walter always says: Put this in bugzilla, it will 
get lost on the forums, and he is right.



 Jan 24 2021



 next sibling parent  Max Haughton <maxhaton gmail.com>  writes:


On Sunday, 24 January 2021 at 13:49:20 UTC, Timon Gehr wrote:

 On 24.01.21 14:00, Max Haughton wrote:

 [...]


 I can get behind this. You closed one of my issues that was 
 fixed this way, but I don't usually report INVALID issues, this 
 is why there is a WORKSFORME category.

 [...]


I was wrong on the enhancement requests, and the WORKSFORME one 
shouldn't have been marked invalid but I think I misclicked.



 Jan 24 2021



prev sibling  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 1/24/2021 5:49 AM, Timon Gehr wrote:

 There is certainly useful work to be done in the issue tracker. I am here 
 objecting to certain systematic destructive practices that do not even have
any 
 upside. I wish this kind of behavior would stop forever. You are not the first 
 person to engage into careless issue closing sprees. I think the underlying 
 issue is a bad understanding of the value of issues in the issue tracker and 
 some sort of irrational assignment of cost to open issues. Walter always says: 
 Put this in bugzilla, it will get lost on the forums, and he is right.


You're right this has come up before.

I strongly oppose closing Issues and PRs just because they are old. There must 
be a better and conclusive reason to close them.

We had a recent discussion about what to do with stale PRs that are years old.
I 
opposing closing them without a conclusive reason for closing. The stale PRs do 
pose "drag" on things like the autotester. What I'd like is a "backburner" 
category for PRs, but there doesn't seem to be such a feature. So what we came 
up with was:

1. If it doesn't have a bugzilla issue, make a bugzilla issue for it.
2. Put a link to the stale PR in that issue.
3. Close, but do not delete, the PR.

This makes these PRs still accessible via bugzilla, and bugzilla has much
better 
categorization abilities than github PRs do.



 Jan 24 2021



prev sibling  parent reply Imperatorn <johan_forsberg_86 hotmail.com>  writes:


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



 Jan 24 2021



 next sibling parent reply ag0aep6g <anonymous example.com>  writes:


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.



 Jan 24 2021



  parent reply Imperatorn <johan_forsberg_86 hotmail.com>  writes:


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?



 Jan 25 2021



  parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


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.



 Jan 25 2021



  parent  Imperatorn <johan_forsberg_86 hotmail.com>  writes:


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



 Jan 25 2021



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


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.



 Jan 25 2021



  parent reply Imperatorn <johan_forsberg_86 hotmail.com>  writes:


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 :)



 Jan 25 2021



 next sibling parent  Timon Gehr <timon.gehr gmx.ch>  writes:


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.



 Jan 25 2021



prev sibling  parent reply Paul Backus <snarwin gmail.com>  writes:


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.



 Jan 25 2021



 next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


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



 Jan 25 2021



 next sibling parent  jmh530 <john.michael.hall gmail.com>  writes:


On Monday, 25 January 2021 at 21:25:28 UTC, H. S. Teoh wrote:

 [snip]

 I think we're looking at this in the wrong way.  [snip]


AKA
https://en.wikipedia.org/wiki/Goodhart%27s_law



 Jan 25 2021



prev sibling  parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com>  writes:


On Monday, 25 January 2021 at 21:25:28 UTC, H. S. Teoh wrote:

 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.


Depends on the nature of the bug, doesn't it?

If the bug is related to the compiler rejecting too many 
programs, then it is ok.

If the bug is related to accepting programs it cannot generate 
correct for, then that is a big issue...



 Jan 26 2021



 next sibling parent  Imperatorn <johan_forsberg_86 hotmail.com>  writes:


On Tuesday, 26 January 2021 at 13:15:05 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 25 January 2021 at 21:25:28 UTC, H. S. Teoh wrote:

 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.


 Depends on the nature of the bug, doesn't it?

 If the bug is related to the compiler rejecting too many 
 programs, then it is ok.

 If the bug is related to accepting programs it cannot generate 
 correct for, then that is a big issue...


True



 Jan 26 2021



prev sibling  parent reply Paul Backus <snarwin gmail.com>  writes:


On Tuesday, 26 January 2021 at 13:15:05 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 25 January 2021 at 21:25:28 UTC, H. S. Teoh wrote:

 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.


 Depends on the nature of the bug, doesn't it?

 If the bug is related to the compiler rejecting too many 
 programs, then it is ok.

 If the bug is related to accepting programs it cannot generate 
 correct for, then that is a big issue...


Well, the incorrect behavior is a liability whether we have an 
issue for it in bugzilla or not. The issue itself is an asset.



 Jan 26 2021



  parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com>  writes:


On Tuesday, 26 January 2021 at 16:05:03 UTC, Paul Backus wrote:

 Well, the incorrect behavior is a liability whether we have an 
 issue for it in bugzilla or not. The issue itself is an asset.


IFF there is development process that ensure that old issues are 
being reconsidered for every release. Having a process where >3 
year issues are being recorded in a document in a structured 
fashion probably would be a good idea. Then they could be used 
for planning. Without that they will most likely never be 
included in any kind of plan? It is just easier to ignore an 
"issue" that has been silently accepted for a decade than a 
recent one.



 Jan 26 2021



  parent  Paul Backus <snarwin gmail.com>  writes:


On Tuesday, 26 January 2021 at 16:40:23 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 26 January 2021 at 16:05:03 UTC, Paul Backus wrote:

 Well, the incorrect behavior is a liability whether we have an 
 issue for it in bugzilla or not. The issue itself is an asset.


 IFF there is development process that ensure that old issues 
 are being reconsidered for every release. Having a process 
 where >3 year issues are being recorded in a document in a 
 structured fashion probably would be a good idea. Then they 
 could be used for planning. Without that they will most likely 
 never be included in any kind of plan? It is just easier to 
 ignore an "issue" that has been silently accepted for a decade 
 than a recent one.


And how are you ever going to implement such a development 
process if you don't have the old bug reports lying around to 
begin with? :)

I agree that the process you describe would be better than what 
we currently have, but that does not mean what we currently have 
is completely worthless.



 Jan 26 2021



prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 25.01.21 21:03, Paul Backus 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.


I beg to differ. Open issues are not demoralizing.


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


What's demoralizing about this exchange is that it seems to imply there 
are people around who have nothing better to do than waiting for you to 
die so they can close your issues in the issue tracker. Apparently they 
will even feel like they are doing a good thing as they destroy your 
legacy. :(



 Jan 25 2021



  parent  Imperatorn <johan_forsberg_86 hotmail.com>  writes:


On Tuesday, 26 January 2021 at 01:47:36 UTC, Timon Gehr wrote:

 On 25.01.21 21:03, Paul Backus 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.


 I beg to differ. Open issues are not demoralizing.


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


 What's demoralizing about this exchange is that it seems to 
 imply there are people around who have nothing better to do 
 than waiting for you to die so they can close your issues in 
 the issue tracker. Apparently they will even feel like they are 
 doing a good thing as they destroy your legacy. :(


Yeah, that's exactly what I meant, 10/10
#apocalypse

RIP devs 😢



 Jan 26 2021



prev sibling  parent  Imperatorn <johan_forsberg_86 hotmail.com>  writes:


On Monday, 25 January 2021 at 20:03:53 UTC, Paul Backus 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.


 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.


Agree, the only point I'm trying to make is about a).

But well, having them forever is ofc the easiest solution. Its 
not a big deal, if the community can handle it.



 Jan 26 2021