Date: Mon, 8 Nov 2021 12:16:30 +0200
On Mon, 8 Nov 2021 at 00:14, René Ferdinand Rivera Morell via SG14
<sg14_at_[hidden]> wrote:
>
> On Sun, Nov 7, 2021 at 3:49 PM Matt Bentley via SG14 <sg14_at_[hidden]> wrote:
>>
>> Just an update to all,
>> unfortunately the elders of LEWG have decided to postpone hive telecon
>> till the C++26 period, for reasons of:
>> 1. There are many other things in the pipeline which have already been
>> discussed and desperately need further discussion in order to
>> make/not-make it into C++23.
>> 2. They believe Hive would need a couple of telecons at least in order
>> to properly discuss, and there isn't the time.
>>
>> I think these are fair reasons, though it seems to me to be a slight
>> mistep as the paper is pretty solid at this point and doesn't require a
>> lot of adjustment I think.
>
>
> Thank you for the update. But I disagree on your estimation. I think it is unfair. Unfair that a well thought out, and discussed, component of existing practice is overridden by priorities of not as grounded features.
The features that get higher priority than std::hive are well
thought-out and discussed components of existing practice.
If you want to convince me that there's something unfair going on, you
need to start making more sense.
The scheduling decisions seem to be going in a fashion compatible with
the priority plan, and it could just as well
be said to be unfair if we suddenly deviate from that plan after
working according to it for all of the C++23 cycle.
For the remaining scheduling and prioritizing of Bucket 3 items, I'm
sure someone will be unhappy about every
possible decision that could be made, and the whole idea of the train
model we've operated with since
the C++14 cycle is that if you didn't get on a particular train, board
the next one.
There's of course the possibility of changing our planning and
execution approach. No proposals for doing that
have materialized, so the only logical conclusion is that the
complaints on various forums are not something
we should take seriously. The onus is on the complainers to prove otherwise.
<sg14_at_[hidden]> wrote:
>
> On Sun, Nov 7, 2021 at 3:49 PM Matt Bentley via SG14 <sg14_at_[hidden]> wrote:
>>
>> Just an update to all,
>> unfortunately the elders of LEWG have decided to postpone hive telecon
>> till the C++26 period, for reasons of:
>> 1. There are many other things in the pipeline which have already been
>> discussed and desperately need further discussion in order to
>> make/not-make it into C++23.
>> 2. They believe Hive would need a couple of telecons at least in order
>> to properly discuss, and there isn't the time.
>>
>> I think these are fair reasons, though it seems to me to be a slight
>> mistep as the paper is pretty solid at this point and doesn't require a
>> lot of adjustment I think.
>
>
> Thank you for the update. But I disagree on your estimation. I think it is unfair. Unfair that a well thought out, and discussed, component of existing practice is overridden by priorities of not as grounded features.
The features that get higher priority than std::hive are well
thought-out and discussed components of existing practice.
If you want to convince me that there's something unfair going on, you
need to start making more sense.
The scheduling decisions seem to be going in a fashion compatible with
the priority plan, and it could just as well
be said to be unfair if we suddenly deviate from that plan after
working according to it for all of the C++23 cycle.
For the remaining scheduling and prioritizing of Bucket 3 items, I'm
sure someone will be unhappy about every
possible decision that could be made, and the whole idea of the train
model we've operated with since
the C++14 cycle is that if you didn't get on a particular train, board
the next one.
There's of course the possibility of changing our planning and
execution approach. No proposals for doing that
have materialized, so the only logical conclusion is that the
complaints on various forums are not something
we should take seriously. The onus is on the complainers to prove otherwise.
Received on 2021-11-08 04:16:43