3 months of waiting...

[berni44]

On Thursday, 6 February 2020 at 22:53:19 UTC, Petar Kirov 
[ZombineDev] wrote:
> I really hope you would reconsider.

Mixed feelings currently. Today the %e-PR was merged. I don't 
know if that is a coincidence (as I never have seen Nicholas 
Wilson posting anything in the forum) or just because of my 
posting here. Anyway, I decided to remove the merge conflicts of 
the %f-PR, as this is for me a matter of some minutes while 
others might need long to understand what's going on.

I've been thinking a lot on this today, and I still came to no 
conclusion. A few things, that crossed my mind:

On Thursday, 6 February 2020 at 20:29:31 UTC, Walter Bright wrote:
> This one is always going to be a tough one:
>
> https://github.com/dlang/phobos/pull/7264

Yes, that's the one I'm talking about.

> Floating point code is extremely difficult to get right, and
> contains a lot of very subtle traps for the unwary.

The nice thing about this is, that it has almost nothing to do 
with floating point. The first step is to copy the floating point 
bit patterns to ulong (if ucent where available, the algorithm 
could also be used for reals by the way), and from there on it's 
integer arithmetics with the expression a * 2^^b. The difficult 
thing is to get the mix of all the flags, precission, width and 
rounding right.

> If there's a mistake in it that subtly breaks someone's 
> floating point code, it would cause them to not trust
> D. Just finding someone capable of reviewing it thoroughly
> would be very difficult for any community.

I question this a little bit. Not, that it would not be nice to 
have such reviewers. But I fear we do not have them and so an 
other way of dealing with such PRs is needed. Here, for example, 
one could run test scripts comparing the output of snprintf with 
the new function. This is something one could do, without 
understanding the details of the function. (I even provided 
several such test script, which I used myself to find corner 
cases I got wrong, when implementing.) Doing this for say 24h 
without finding any difference (other than the fixed bugs), would 
be a high evidence that the code has no bugs.

> One thing you can do when things are being overlooked is to get
> behind and push. I often do that - people don't just pull
> things because I wrote them.

This is something I quite dislike. Maybe it's my personality - I 
often feel importunate, when doing so.

On Thursday, 6 February 2020 at 17:35:36 UTC, H. S. Teoh wrote:
> Honestly, if it were up to me, I'd add you to the Phobos team.

I didn't even know that such a team exists... Maybe it would 
indeed help to be in such a team, because I'd have some people I 
can ask without the need to discuss everything here in the forum. 
On the other hand I'm not sure if being added to such a team 
comes with expectations I cannot meet...

On Thursday, 6 February 2020 at 17:47:14 UTC, Jonathan Marler 
wrote:
> Unfortunately, there's not much you or I can do, it's in the
> hands of the leadership.

Again: I even don't know exactly who this is. OK, Walter, that's 
clear. And I could guess a few others - Mike, Atila, Nicholas, 
Vladimir and Andrei come to my mind (and the foundation page list 
Ali too).

Maybe it would be a good thing to have some overview about the 
teams and groups somewhere.

On Thursday, 6 February 2020 at 17:24:52 UTC, Les De Ridder wrote:

> Also, while the core issue here may not have an obvious 
> solution, we
> should make sure we don't worsen it by arbitrarily closing 
> old/'stale'
> issues or PRs. Some open-source projects have recently fallen 
> into this
> trap, e.g. by using a GitHub bot to automatically close old 
> issues
> and/or PRs, which is confusing for users and discouraging for
> contributors.

I would actally recommend to close old PRs. I allready thought 
about going through all the old PRs and checking if anything of 
them can still be used. I think, this would considerably reduce 
the amount of open PRs and make it less likely, that PRs are 
missed.

But of course, this should not be done by a bot. At least, before 
closing an issue, a thorough statement, why this is closed, 
should be given. For example

https://github.com/dlang/phobos/pull/7297

is IMHO a candidate to be closed. I gave a statement there where 
I pointed out, why this PR would worsen the result of the pow 
function. Actually, this PR even shows, that the x^^-2 special 
case should be removed too, which has the same problem (and maybe 
the x^^2 special case too, which is not of a problem, but IMHO 
completely unnecessary, because the general case is doing 
identical calculations). So finally, that PR helps to improve 
this function, though not the way it was originally intended. But 
maybe, this is some sort of consolation for the PRs author.


And some other things that crossed my mind and where not touched 
by your replies:

* Recently the testers had a lot of false positives, mainly 
because of missing internet. That doesn't feel good. The PRs get 
red for no real reason and I've got no real means to do anything 
about it. Just rebase and push, rebase and push, ..., but I do 
not want to do that all the time. Maybe the missing internet 
errors could be caught and the result of the tests postponed 
somehow? I have no experience with this, so I cannot say, if this 
is lot of work or simple to implement. Just a suggestion.

* Labels. I havn't found a way to add labels to my PR. I guess, I 
just can't. Some of them would be helpful, especially WIP (and 
auto-merge ;-) ). Maybe the bot could recognise +WIP and -WIP and 
just add and remove this label.

* IMHO there are too many DIPs. If it were my decission, I would 
stop the DIPs for, let's say 3 months (maybe more or a repetition 
in a year is needed), and proclaim this time to be dedicated to 
bugfixes and documentation. So everyone would be asked to help to 
remove bugs and improve the documentation during this period. 
IMHO in the long run this makes for a faster improvement, because 
it's much easier to implement new things, when not having to hack 
around several bugs. And it would make for a stable version which 
deserves this name.


Enough for today. I still don't know, if I will leave or stay...