Start of dmd 2.064 beta program

[Andrej Mitrovic]

On 10/16/13, Brad Roberts <braddr at puremagic.com> wrote:
> That's not a what, that's a who.

- We do not have any vision or major plans ahead for the language.
Currently we're stuck in a bug-driven development environment, where
bugs are arbitrarily picked off of bugzilla and fixed. But there's no
major plans ahead, e.g. "let's plan to fix these X major bugs for some
upcoming release". We can't force people to work on X or Y, but if
they're in a visual place and marked important and scheduled to be
fixed, this will give an incentive for contributors to work on these
problems.

- We do not have any defined release timeline. When is it time to
start prepping for a release? It's up to Walter's arbitrary decision
for when this happens, he doesn't even talk to the community or
contributors on whether it's a good time for a beta phase (maybe
there's a huge or disruptive new pull request that's planning to be
merged and a beta should be delayed).

- We do not have a defined timeline for the beta testing period. How
long before we decide that the beta has been tested for long enough
before a release is made? Again, it's up to Walter's decision.

Having a defined release cycle and a beta testing period will
ultimately be beneficial for everyone. People who are busy can
rearrange their schedule to make free time and ensure they have enough
time to test a beta compiler on their projects, and contributors to D
can prepare for a cycle of days or weeks where they can rapidly work
on reducing regressions and polish everything up for the release (e.g.
writing an elaborate changelog).

- We do not have a proper release system. Nick Sabalausky has been
working hard on one[1], but Walter seems to have completely ignored
it. It would have been a terrific opportunity to try and make it work
for this release. What better way to test it than to test it on a
release?

- The betas are still not visible. The homepage makes no notes on a
new beta being available, the download page does not list the betas
either, and AFAICT there's no RSS feed either. The social media groups
are not notified either (neither Andrei's nor Walter's twitter feed
make a mention of a new beta being out, the same applies to
https://twitter.com/D_Programming or the #dlang hash tags). To top it
all off, you cannot post to the dmd-beta newsgroups from the D Forums,
you have to separately register to this mailing list.

If we want user feedback on betas we absolutely must make the betas
visible and give an opportunity for people to post feedback.

- Walter is still not tagging the beta releases by the file name (it's
always dmd2beta.zip). I've complained about this several times and
IIRC someone else did as well at dconf (maybe I'm remembering wrong
though). They should at least be named as "dmd2_064_beta1.zip",
"dmd2_064_beta2.zip". And all of them should always be available for
download (including visibility on the download page), so people who do
not use Git or build manually from master can quicky check whether a
regression was introduced in a specific beta version.

- I still sigh when I hear about Walter and Andrei having private
phone conversations, or any kind of decision is made behind-the-scenes
rather than publicly where the community has a say in it. Walter's
implementation of UDAs directly in master which lead to having a
deprecated syntax even though nobody used this syntax is what comes to
mind.

- Both Walter and Andrei not following the rules and making novice
mistakes w.r.t Git and Github. Walter still seems to struggle with
basic usage of git, where people continually have to re-explain what's
wrong and how to fix an issue. I'm sorry, but if someone bought the
Git book years ago and is still struggling with *concepts* then no
amount of hand-guiding is going to help. And Andrei doing things like
merging a dozen pull requests at once, with complete disregard to the
fact that merging to master means other pulls could easily break (and
so master can be broken). You cannot make so many merges unless you're
absolutely sure each pull request does not interfere with another.

- Back to Walter, a few weeks ago he merged a pull request over night,
without regard to the pull request not being fully tested by the test
machines. The result? Master was broken **for the entire next day**.
Nobody knew which commit broke master, so nothing was done until
Walter came back to Github the next day and started reverting his
pulls. In the meantime the entire day was wasted because nobody's pull
request could get green. Luckily it was a sunday, so there weren't too
many complaints. But I could have easily merged a few pulls that day
(as it happens I like to do things on a sunday), and as a result we
would have a smaller pull queue.

--

There's just many things that are going plain wrong here, and a lot of
promises are always made but ultimately never delivered (whether it's
about breaking changes or an improved development process -- again
think about scheduling bug fixes for the future, we could help people
prepare for the breaking changes).

Personally I find D to be a huge part of me right now (probably not
the other way around, I'm a small part of this compared to the huge
contributors), and I feel really bummed out when both Andrei and
Walter take a casual stance when things are broken (whether it's the
system itself or something specific like master being broken). I
really think we have a great thing going here with the language, but
everything else has to improve, and particularly the development and
release process.

So that's what I'm protesting about.

[1] : https://github.com/D-Programming-Language/installer/pull/24
(release build script)