Start of dmd 2.064 beta program

[Andrej Mitrovic]

On 10/18/13, Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:
> nobody has the time and inclination to actually _be_ the
> build czar (which is entirely understandable).

Building something should be a command on the command-line. The whole
issue is about currently having a person in place of a tool.

> You yourself didn't find the time to update a task you volunteered on.

You mean https://github.com/D-Programming-Language/dmd/pull/2235 ?
I'll get back to it soon.

> We'll look into it, but this harkens back to the simple dynamics
> mentioned above. That is essentially a request for Walter to change the
> way he does releases, and people tend to get set in their ways and have
> difficulty finding the time to stop and change things when there are so
> many other things vying for their attention. The best solution here is
> if Nick (or someone else) would _be_ the build manager using those great
> tools that Nick wrote.

Like I said before, it's a command, you don't need a manager to do it,
you need a reliable tool. "$ make_build" is all it takes. This
"manager" and "czar" nonsense is really a corporate way of solving
issues. I can see how you might have gotten used to that when you have
people on a payroll that you can easily asign to a task. Even if
ultimately it's beneficial for having a tool in place of a person, a
company might decide against it if it can "hammer the nail right away
and make the problem go away" (until the problem comes walking back).
We're programmers, we should rely on tools for automated tasks.

And I want this not because I'm an automation freak (I'm not), but
precisely because Walter has screwed up the zip package many times
before. Hence, if Walter is the one who is currently in control, why
doesn't he interact with Nick to ease into using a build tool rather
than use some X number of scripts that he keeps on his PC only?

> As a simple start, did you consider announcing the beta yourself?

I didn't, because I disliked the current model and tied my hands when
I saw the new beta was out due to the sum of frustrations which I've
listed. This will change if the situation improves, of course.

> Anyone can tweet #dlang @D_programming, and in all likelihood we and many
> others would retweet.

Good. I'll certainly start to build a better online presence,
including tweeting, and I should start blogging too (there's plenty to
blog about w.r.t. D). I can't be the pot calling the kettle black.

> Also, did you consider submitting a pull request
> for placing the beta announcement on the homepage?

Good idea, and it's something I can work on.

But I hope you understand this isn't really about you or Walter not
doing these things yourself, but rather the fact that you didn't seem
to recognize this as being a problem. I've mentioned the build/release
issue many times, and now we finally have a pull request that could
make this problem go away. Just as I thought the problem was being
resolved, Walter announced the new beta. So clearly he still doesn't
see the pull request as being important.

> Probably that's a good thing to do, and easy enough. I don't think it
> would push the needle significantly.

But that's just the thing. The things I've listed are what pushed the
needled "too much to the left" for me. Small improvements like this
are great, and they add up. Otherwise people (like me) will keep
complaining about small issues, which collect and add up to the
frustration.

> We can't have a phone conversation with the community.

Why do you even need these phone conversations related to D or
decision making? The community has an insane number of intelligent
people who can contribute to resolving issues.

> Then, your first three points complain
> about a lack of leadership, and in the same breath you complain about
> there being too much of it.

Lack of leading the community and the development process, not lack of
decision making.

> Walter scrambled to implement UDAs in a rush and breaking protocol in
> order to win a corporate D user, Remedy Games. It was a major,
> exceptional event. Would you have preferred the protocol to have been
> followed at the cost of Remedy?

This is what doesn't inspire me at all. So in the future when company
X decides it wants some feature in the language you're saying we
should not follow the protocol like we do for all the other
user-requested features? Because the news of company X using D will
create headlines?

> I agree that's a problem. Probably what would help would be more quality
> reviews and pulls by our members with commit rights, of whom you are one.

I don't see what this has to do with not understanding Git basics. If
I merge more pull requests it isn't going to improve Walter's
knowledge of Git. Also, I tend to review pull requests which I
actually understand (doing otherwise would be counter-productive).
Sometimes I fall behind track because I also want to work on some of
my own D projects. I know we're all very busy, but I didn't say Walter
didn't want to review something, I said in particular that Walter is
still struggling with Git fundamentals.

> I agree I could probably spend more time
> on carefully analyzing interactions between pulls, but that's time I
> can't afford.

Well that's a damn shame. You see, most of us who have commit rights
wait for the pull request questions to be answered, for commits to be
properly reviewed, and for any final bookkeping and polishing to be
done, and then we wait for the lights to go green before we pull.

> I guess such accidents are bound to happen to the best of us. A build
> czar with the appropriate skills would have swiftly undone the damage.
> But there is no build czar.

Here we go again with this corporate speak. Now you want to add
another person to the mix, when we already have the tooling in place.
Don't merge a pull request unless it's green, how can that be so hard
to understand?

> We're in this together; to wit, for many of the things you're asking why
> they don't get done, you could be asked the same thing.
> Now you're not doing that work in protest against... not enough work
> getting done.

I see that most of your arguments ultimately revolve around throwing
the ball to my side, and asking why I didn't do all the things I
listed. That's completely fair game (it is), but I still can't control
when we do a beta/release cycle, and I can't control zipping up a
release package (and I don't want to, I just want this to become a
small task of issuing a command on the command line). Now we have a
shot at the second problem with automatic tooling to make the release
package. Is Walter going to be ok with this?

Btw, if you think that I'm just going to put my tail between my legs
and run, you're out of your mind. I'll deliver on the promises I made
(which includes the part about twitter/blogging/etc), and I'll make
the 2.064 changelog, and probably future ones as well. I can bite the
bullet and do hard work for D.

But, if you're going to keep saying things like:

- Damn the protocol, don't you see feature X for Company Y is
important? We'll implement it regardless of community.
- Damn the protocol, the pull request list is long and I'll just do
whatever I want to reduce it, even if it means having a broken master.

Then you cannot expect me to be silent about it. This little protest
of mine was an attention grabber to the issues that we face, and
especially to some issues that I'm personally frustated about. You can
consider the protest over.

As for me, I'll do my part to improve whatever I can with regards to
D. I love D and the community too much to be stopped from contributing
more just out of a few frustrations.