The following:

https://github.com/D-Programming-Language/dmd/pull/3907

https://github.com/D-Programming-Language/dmd/pull/3947

are both significant language changes. Language enhancements should only be pulled by myself. I understand that it is frustrating when I am slow to respond to these issues. I need to do better. But language enhancement approvals are still on my plate.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

There's another problem, exhibited by:

https://github.com/D-Programming-Language/dmd/pull/4043
https://github.com/D-Programming-Language/dmd/pull/3998

What both share is that a significant language change is coupled with the code to implement it. The trouble is the PR then becomes a mixed-up review of the code and the language design change. This makes it hard and confusing to review, and

   -- WORST OF ALL --

if the language design change is rejected, then the PR author's coding effort has gone to waste. We don't have the luxury of throwing peoples' work away like that. It pains me very much when this happens.

So please, please, before submitting a PR that involves a language change, be sure you've got agreement and approval for the change. Otherwise, you risk wasting your time in a most frustrating matter.

I'm also OK with others pulling PR implementations for language changes when the language changes have already been approved.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Fri, Oct 10, 2014 at 3:07 PM, Walter Bright via dmd-internals <dmd-internals@puremagic.com> wrote:

> if the language design change is rejected, then the PR author's coding effort has gone to waste. We don't have the luxury of throwing peoples' work away like that. It pains me very much when this happens.

Walter, this is the most effective way to push for decision on enhancements.  You have an awful track record at deciding on theoretical changes.  It is _supposed_ to pain you when the work gets thrown away.

> So please, please, before submitting a PR that involves a language change, be sure you've got agreement and approval for the change. Otherwise, you risk wasting your time in a most frustrating matter.

Following this would result in near-zero enhancement PRs.  Is that what you want?

> I'm also OK with others pulling PR implementations for language changes when the language changes have already been approved.

That didn't work so well with adding the virtual keyword.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 10/9/2014 10:43 PM, Daniel Murphy wrote:
> On Fri, Oct 10, 2014 at 3:07 PM, Walter Bright via dmd-internals
> <dmd-internals@puremagic.com> wrote:
>
>> if the language design change is rejected, then the PR author's coding
>> effort has gone to waste. We don't have the luxury of throwing peoples' work
>> away like that. It pains me very much when this happens.
> Walter, this is the most effective way to push for decision on
> enhancements.  You have an awful track record at deciding on
> theoretical changes.  It is _supposed_ to pain you when the work gets
> thrown away.

Throwing a valuable contributor's code away should not factor into a decision as to whether a language enhancement is a good idea or not. But doing it this way makes it a factor. This does not lead to the best decisions.


>
>> So please, please, before submitting a PR that involves a language change,
>> be sure you've got agreement and approval for the change. Otherwise, you
>> risk wasting your time in a most frustrating matter.
> Following this would result in near-zero enhancement PRs.  Is that
> what you want?

We need to approach language changes with increasing caution, not less. We get a lot of flak, some of it deserved, for reaching for shiny new features rather than doing the drudgery of making existing features work correctly.


>
>> I'm also OK with others pulling PR implementations for language changes when
>> the language changes have already been approved.
> That didn't work so well with adding the virtual keyword.

Point taken. That was a failure of process.

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Fri, Oct 10, 2014 at 5:42 PM, Walter Bright <walter@digitalmars.com> wrote:
>
> On 10/9/2014 10:43 PM, Daniel Murphy wrote:
>>
>> On Fri, Oct 10, 2014 at 3:07 PM, Walter Bright via dmd-internals <dmd-internals@puremagic.com> wrote:
>>
>>> if the language design change is rejected, then the PR author's coding
>>> effort has gone to waste. We don't have the luxury of throwing peoples'
>>> work
>>> away like that. It pains me very much when this happens.
>>
>> Walter, this is the most effective way to push for decision on enhancements.  You have an awful track record at deciding on theoretical changes.  It is _supposed_ to pain you when the work gets thrown away.
>
>
> Throwing a valuable contributor's code away should not factor into a decision as to whether a language enhancement is a good idea or not. But doing it this way makes it a factor. This does not lead to the best decisions.
>

I can't say I've seen you making bad decisions because of this.  In an ideal world you wouldn't be put in this position, but it's a lot better than the alternative of _never_ getting a decision on enhancements.

The only other options are to post on the newsgroup, which almost always results in nothing useful and no decision, or to approach you or Andrei personally.

>
>>
>>> So please, please, before submitting a PR that involves a language
>>> change,
>>> be sure you've got agreement and approval for the change. Otherwise, you
>>> risk wasting your time in a most frustrating matter.
>>
>> Following this would result in near-zero enhancement PRs.  Is that what you want?
>
>
> We need to approach language changes with increasing caution, not less. We get a lot of flak, some of it deserved, for reaching for shiny new features rather than doing the drudgery of making existing features work correctly.
>

I would consider both of those merged enhancements as arguably making
existing features work correctly.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Oct 10, 2014, at 06:09 AM, Walter Bright via dmd-internals <dmd-internals@puremagic.com> wrote:

> There's another problem, exhibited by:
>
> https://github.com/D-Programming-Language/dmd/pull/4043 https://github.com/D-Programming-Language/dmd/pull/3998
>
> What both share is that a significant language change is coupled with the code
> to implement it. The trouble is the PR then becomes a mixed-up review of the
> code and the language design change. This makes it hard and confusing to review, and
>
> -- WORST OF ALL --
>
> if the language design change is rejected, then the PR author's coding effort has gone to waste. We don't have the luxury of throwing peoples' work away like that. It pains me very much when this happens.
>
> So please, please, before submitting a PR that involves a language change, be sure you've got agreement and approval for the change. Otherwise, you risk wasting your time in a most frustrating matter.

This is the only way to make things happen. Neither you or Andrei are caring about the DIP's people create. They barley get any response at all from you or Andrei when posted on the newsgroups. DIP's are were good ideas go to and die.

--
/Jacob Carlborg

On Oct 10, 2014, at 05:36 AM, Walter Bright via dmd-internals <dmd-internals@puremagic.com> wrote:

> The following:
>
> https://github.com/D-Programming-Language/dmd/pull/3907
>
> https://github.com/D-Programming-Language/dmd/pull/3947
>
> are both significant language changes. Language enhancements should only be pulled by myself. I understand that it is frustrating when I am slow to respond to these issues. I need to do better. But language enhancement approvals are still on my plate.

I would hardly consider those pull requests "significant language changes". It's rather, "why didn't work like that from the beginning?".

--
/Jacob Carlborg

On 10/10/2014 12:14 AM, Daniel Murphy wrote:

>I can't say I've seen you making bad decisions because of this.  In an
ideal world you wouldn't be put in this position, but it's a lot
better than the alternative of_never_  getting a decision on
enhancements.

I've pulled quite a few enhancements. The changelog is full of them.

> I would consider both of those merged enhancements as arguably making existing features work correctly.

This thread is not about whether those were good enhancements or not, it's about the process.

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Fri, Oct 10, 2014 at 8:37 PM, Walter Bright <walter@digitalmars.com> wrote:
>
> On 10/10/2014 12:14 AM, Daniel Murphy wrote:
>
>> I can't say I've seen you making bad decisions because of this.  In an
>
> ideal world you wouldn't be put in this position, but it's a lot better than the alternative of_never_  getting a decision on enhancements.
>
> I've pulled quite a few enhancements. The changelog is full of them.

And how many of those didn't have pull requests?

>
>> I would consider both of those merged enhancements as arguably making existing features work correctly.
>
> This thread is not about whether those were good enhancements or not, it's about the process.
>

The process is broken because you obviously don't have time to
manually approve every single pull request that could potentially be
seen as an enhancement.  I think it's reasonable for decisions on
enhancements that can reasonably be seen as 'removing unnecessary
limitations and inconsistencies of existing features' to be made by
contributors other than you.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 10/10/2014 3:44 AM, Daniel Murphy wrote:
> On Fri, Oct 10, 2014 at 8:37 PM, Walter Bright <walter@digitalmars.com> wrote:
>> On 10/10/2014 12:14 AM, Daniel Murphy wrote:
>>
>>> I can't say I've seen you making bad decisions because of this.  In an
>> ideal world you wouldn't be put in this position, but it's a lot
>> better than the alternative of_never_  getting a decision on
>> enhancements.
>>
>> I've pulled quite a few enhancements. The changelog is full of them.
> And how many of those didn't have pull requests?

I don't understand the point of the question. All of the changes had pull requests.


>>> I would consider both of those merged enhancements as arguably making
>>> existing features work correctly.
>> This thread is not about whether those were good enhancements or not, it's
>> about the process.
>>
> The process is broken because you obviously don't have time to
> manually approve every single pull request that could potentially be
> seen as an enhancement.  I think it's reasonable for decisions on
> enhancements that can reasonably be seen as 'removing unnecessary
> limitations and inconsistencies of existing features' to be made by
> contributors other than you.
>

I understand where you're coming from, and I understand that it's frustrating to funnel things through me. I'm fine with Team DMD pulling bug fixes, optimizations, refactorings, platform support, etc., that's why you guys are on the team. But language changes are a much higher bar than any person on the team deciding to pull it. There are a lot more consequences to such changes. We must be very cautious about these, as we'll have to live with mistakes for a long time. They need to fit into the long term goals of D, not a local problem. I'm uncomfortable with the idea of changes being small - I've blocked enhancements in the past because they had consequences that weren't too obvious, or I thought that a simpler solution needed to be found, etc. I'd also like to make sure there's adequate time for people to find things wrong that nobody noticed, or to find better solutions, again because the consequences of a mistake are so much higher. Also, many times there are reasons why things are they way they are that I have failed to communicate properly, and enhancing them out of existence can break them. I also have a larger responsibility to ensure that D works for all our users, not just the ones active on the n.g., and I must represent our silent users.

I'm fine with people emailing me and pestering me for a review of any particular change that has bubbled to the top in importance.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals