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
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
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
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
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
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
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
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
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
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
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
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
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
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Welcome Max and congratulations!
Jan 21
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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