3 months of waiting...

[H. S. Teoh]

On Fri, Feb 07, 2020 at 08:00:16PM +0000, berni44 via Digitalmars-d wrote:
[...]
> On Thursday, 6 February 2020 at 20:29:31 UTC, Walter Bright wrote:
[...]
> > 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.

If you could provide such a tool that does this verification, and maybe
include it in phobos/std/internal somewhere (optionally with a rule in
the makefile for running it, so that people can easily check for
themselves), then run it for I dunno, a week or something to go through
all possible 32-bit floats and a significant subset of 64-bit floats,
then we'd have solid evidence that your code has no bugs, as least as
far as snprintf is concerned. (This of course assumes snprintf itself
has no bugs, which I'm actually not 100% confident of, but at least it's
been around for long enough and tested by enough people that the chances
of a bug in some really obscure corner case seems negligibly small.)

I was going to suggest adding this to the Phobos unittests, but I fear
that exhaustive tests of this sort will only add unnecessary burden on
the autotesters and slow everything down for no good cause. So a
separate tool seems to be the best solution.


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

It's OK, back when I still had time to contribute to D regularly, I used
to leaf through old, stagnant PRs, and @ping people to get moving on it.
Some of my pings fell on deaf ears, but I did manage to get a few
stagnant PRs to start moving again, after "annoying" them with regular
pings.


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

Huh, weird. Github used to have icons on a page somewhere that shows
everyone that belonged to a particular organization/team, but it seems
that has disappeared.

As far as Phobos is concerned, basically it just means you get write
access to the repository.  Some years back I was regularly contributing
and complaining that the PR queue was too slow, then suddenly overnight
somebody gave me commit access to Phobos (which I was not expecting).
Then later on I got added to dlang.org and druntime, though not dmd (I
didn't contribute regularly enough, plus I don't think I have the
expertise to review dmd PRs, so that's OK).

Of course, as a committer, it's bad form to pull your own PRs, but at
least you can pull others' PRs (or otherwise ping people, etc.) to get
things moving when the PR queue gets clogged up.


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

I think the only expectation, as far as I'm aware anyway, is that you
don't pull your own PRs, or pull stuff without being reasonably sure
there are no bugs or problems, and that you're familiar enough with
idiomatic D to be able to tell whether a piece of code is good or not.
Other than that, I don't think there are any other expectations.  As far
as my own experience with contributing to Phobos is concerned, I just
refrain from touching PRs that I'm not qualified to review, and
everything else is fair game, I guess. (Although as I said, I do leaf
through old PRs and give them a kick every now and then just to get
things unclogged.)

For a while, the D Foundation was paying Nicholas Wilson to monitor the
PR queue and keep things moving; I'm not sure if they're still doing
that.  From the sound of what you said, though, he's still around
*somewhere*.


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

I'm pretty sure Github used to have a list of these people, but I can't
seem to find that page anymore.


[...]
> * 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.

I used to complain loudly when the autotester got stuck. But these days,
with the increasingly complex CI infrastructure, I don't even know
what's going on anymore.

But either way, false positives from the testers is a problem that needs
to be addressed.  I'd ping the people responsible for it (Vladimir,
IIRC, and Brad perhaps? I forget who else, the Github "conveniently"
disappeared the Dlang organization member list page).


> * 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.
[...]

If you're given commit access, you'd be able to add labels.  For the
time being, though, I'd just stick "[WIP]" in front of the PR title and
leave it at that.  I think that gets the message across.


T

-- 
It is impossible to make anything foolproof because fools are so ingenious. -- Sammy