Dconf AGM draft agenda

Seb seb at wilzba.ch
Wed Apr 3 11:53:11 UTC 2019


On Wednesday, 3 April 2019 at 00:10:53 UTC, Nicholas Wilson wrote:
> The Dconf AGM draft agenda  is up at 
> https://github.com/thewilsonator/Dlang-AGM
>
> If you feel that something is missing or I've messed something 
> up please do open a PR.

Thanks a lot for this!

It would be super nice to have handy links to the relevant GH 
PRs, Bugzilla issue or forum discussion.
Also each point should have a short description, because I don't 
know what you want to discuss with e.g. "Stuff from 
github.com/truedat101/dlang-sv-community".

Anyhow, a few points:

> Deprecate autodecode – plan of action

tl;dr: the only way we can get rid of it is std.v2

> Dub tester to regression scan for dmd releases - Neia

How is this different to the existing project tester?

> 64 compiler release for windows

It's listed twice.
In short: the release setup is pretty complicated and only Martin 
has all the VMs required for the build setup.
Also, you might want to add to your list that the binaries for 
Windows are no longer signed.

> int[$] arr = [1,2,3,4];

I wouldn't get my hopes up for this one.
A DMD PR has been reverted and then closed.

https://github.com/dlang/dmd/pull/3615
https://github.com/dlang/dmd/pull/4377

Since then `staticArray` has been added to Phobos:

> changes w.r.t DIP1000, c.f. dlang.org#2453

the subpoints seem unrelated.

> Quality of documentation

It's pretty bad. DMD documentation is almost unusable, for 
druntime many modules don't have long descriptions or examples. 
Phobos is a lot better, but the ddoc <-> ddox duplication is 
still around.
The tour.dlang.io should have been revisited and reworked a long 
time ago, but no one got around (in short: we want to have a more 
natural intro for readers and show off D features in the 
beginning, not end).

> Transition from DMC+OPTLINK to msvc/mingw + lld

I have tried this before. Walter will definitely object to this. 
Other people also gave it a shot, see e.g.

https://github.com/dlang/dmd/pull/8347
https://github.com/dlang/dmd/pull/9085

With mingwg + lld there is also this problem: 
https://issues.dlang.org/show_bug.cgi?id=19760

At least, dub now does the sensible thing:

https://github.com/dlang/dub/pull/1661

> FreeBSD 11/12

It's a mess and as almost no one uses D on FreeBSD, this doesn't 
move forward:

https://github.com/dlang/dmd/pull/8567

FWIW toolchain triplet selection would have been nice too:

https://github.com/dlang/dmd/pull/8020

> State of std.experimental

The entire idea of std.experimental kinda failed, because 
breaking changes can't be SemVer-ed,
If you're asking whether anything can be stabilized, we're far 
from it:

- stdx.logger: people want a @nogc logger (and IIRC there were 
some API issues)
- stdx.checkedint: it's not even @safe by default (see e.g. 
https://github.com/dlang/phobos/pull/6369, 
https://github.com/dlang/phobos/pull/5928, 
https://github.com/dlang/phobos/pull/6550)
- stdx.allocator: still changes happening very often. The 
community fork diverged and is usable with betterC 
(https://github.com/dlang-community/stdx-allocator). There are 
also quite a few bugzilla issues on it
- stdx.typecons: probably the only module that could be 
stabilized (though it only contains two functions)

I'm not sure what to do with wrap as the existing wrap would need 
to be deprecated and removed, but we could stabilize Final (D's 
head-const):

https://dlang.org/phobos/std_experimental_typecons.html#.Final

> DMD as a library

With stuff like https://github.com/dlang/dmd/pull/9507, it's a 
constant battle :/

> Get bugzilla under control (prioritisation)

We tried quite a few things over the last years:

- #dbugfix campaign
- voting on Bugzilla issues

Currently, we're back to people complaining loudly on the NG 
about very important issues as this is the only way to grab 
attention.

About a year ago, I started an internal discussion about moving 
the issues to GitHub. I tested a potential migration and it 
looked pretty promising. The two big downsides were:
- issue numbers would be different (though a redirect on 
issues.dlang.org and mentioning the original issue number should 
help greatly with that. Furthermore, we could create empty 
"dummy" issues to align the issue numbers if deemed necessary)
- no longer in one global issue database (though since GitHub 
supports issue transfers, probably not a big problem anymore)

In the end it wasn't done because of the fear of loosing control 
over the issue data as the only way to programmatically export 
them is the GitHub API which is severely rate-limited. Though to 
be honest, at the moment Brad is the only with access to 
issues.dlang.org (and no one else to my knowledge is keeping 
backups of issues.dlang.org).

The migration script is here: 
https://github.com/wilzbach/bugzilla-migration


More information about the Digitalmars-d mailing list