On 10/18/2013 1:29 PM, Andrej Mitrovic wrote:
> 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.

As I've posted elsewhere, I want very much to have the package build process to be a single command. I want Brad's autotester to build those packages as part of its regular build/test runs.

I'd like Brad, Nick, Jordi, Jacob, and anyone else involved with the installers to get together to get this done.

As to why I didn't do this for the beta zip - because the install package builders break with every new release, and for the initial beta I just wanted to see where we were with the regressions - and there's a lot of work to do just to fix those, before getting to a release candidate.

We do need a Build Czar, because the install builds break every time, due to things like failure to update the manifests, new build targets, new features, etc. Somebody has to be responsible for getting all the scripts tested and working again - which is also why I want this to be part of the autotester, so problems will show up sooner. (And heck, just building the zip file exposed a lot of breakage.)

On Friday, October 18, 2013 15:31:05 Walter Bright wrote:
> We do need a Build Czar, because the install builds break every time, due to things like failure to update the manifests, new build targets, new features, etc. Somebody has to be responsible for getting all the scripts tested and working again - which is also why I want this to be part of the autotester, so problems will show up sooner. (And heck, just building the zip file exposed a lot of breakage.)

I would suggest making a very prominent post about this in the newsgroup -
that you want a build czar. If you make it clear that the position needs to be
filled, and that it's your intention to offload that work to the build czar, then
someone may step up to do it - especially if they're unhappy with the current
process. Most of the push on that thus far has been towards trying to get you
to change what you're doing, and I'm not sure that it's clear enough to
everyone that you're ready and willing to have someone else shoulder those
responsibilities. And without that being clear, I think that it's a lot less
likely for someone to step up and offer to do it. We _have_ had some folks step
up to start working on some of it (e.g. Nick with the zip file generation), so
maybe making it clear that the position is open and that we want it filled will
make it so that someone like that will step up and do it. Sometimes the problem
isn't finding someone who's ready and willing but rather making it clear what's
needed so that someone who's already ready and willing knows what they can do
to help.

- Jonathan M Davis

On Friday, 18 October 2013 at 20:29:29 UTC, Andrej Mitrovic wrote:
> On 10/18/13, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>> 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.

Idea:
We can use Twittwer API to automaticly publish a news like "new betta". I did it via PHP for Drupal, and it wasn't so difficult.
So, we can create a package build process. It creates new betta, publish announcement in the D forum, in the D homepage, in the D dowload page and in the D twitter.

Am Fri, 18 Oct 2013 11:45:27 -0700
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> > - 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).
> 
> I understand how that can be a bother. Walter figures the time is ripe for a new release when we have enough compelling features and fixes. I'll try to make the appropriate announcements in the future prior to deciding on starting a beta.
> 

Why is everyone here so obsessed with feature based releases? Quoting Iain's post from 30.8:
> It has been about 3 months since the last release of the D front-end implementation.  Three years experience and carrying out over 100 merges into GDC tells me that each time the development cycle starts edging towards it's fourth month, it makes things an absolute nightmare, in both the time consumed merging in the changes, and with time spent tracking down bug reports for unittests/testsuite cases that test backend code generation - with 2.060, 2.061 and 2.063 being the worst releases I have ever had to deal with - before 2.060 the release schedule (if it even qualifies as a 'schedule') was anywhere between 1-2 months.

Even a rough schedule (We try to release a new frontend version every 2 months) would help. Would it have been the end of the world if we just released 2.064 two months ago and 2.065 now?

But what's worse: If we keep making feature based releases then the
criteria for release should be documented by those making the decision.
It's as simple as writing two sentences on a wiki page.
Right now I don't have any clue why the 'time is ripe' now and not 2
months ago, or one month ago, or in two weeks... It seems like Walter
is just flipping a coin every month (I don't say it is like that -
but it looks like that because there's no information on the release
criteria)

And btw: 5 months between releases is just way too long for users as well. Although the features Walter envisioned for 2.064 may not have been ready 2 months ago we could have shipped many bug fixes two months earlier.

Am 18.10.2013 20:45, schrieb Andrei Alexandrescu:
> Walter and I frequently think of ways to gently steer people toward
> working on specific items. Votes, categorization, discussions are of
> limited impact. On occasion we've emailed major contributors directly
> and asked politely but point blank if they could look into an issue
> (sometimes something they had an expertise in, or even an issue they had
> caused). The rate of success has been very low. People still love
> working on things, just not on the things they're told to.

I think you should continue to do that. Even if it only has a small sucess rate. I for example wouldn't have noticed that the stack trace code I submitted into druntime did cause long startup times for D-Programms that are run directly from the root of a disk drive if Walter wouldn't have send me the e-mail with the bug in it. After the e-mail I even fixed the bug ;-)

Kind Regards
Benjamin Thaut

On Oct 18, 2013 3:09 PM, "Andrej Mitrovic" <andrej.mitrovich@gmail.com> wrote:
>
> On 10/18/13, eles <eles@eles.com> wrote:
> > IIRC, Walter wanted that file to always be named dmd.zip or dmd2.zip or whatever, in order to allow a permanent download link, while guaranteeing the file to be the latest version of the tool.
>
> This is the wrong approach. There should be a "latest_beta" file which holds the name of the latest beta zip. Then automatic download tools can read this file before attempting to download the beta. And for everyone else who manually downloads, they should be able to see what the latest version is on the website.
>
> This isn't a novelty approach, many open-source libraries host their sources in a tarball on an FTP server with a LATEST file.
>

+1 to tarballs and a LATEST file. Infact, a folder structure in the same manner would go away long way too.

Eg:
2.063/
   dmd2.tar.gz
   dmd2.zip
2.063.1/
   dmd2.tar.gz
   dmd2.zip
2.064-development/
   dmd2.tar.gz
   dmd2.zip
LATEST/   <- symlink to development or last stable.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Oct 18, 2013 7:45 PM, "Andrei Alexandrescu" < SeeWebsiteForEmail@erdani.org> wrote:
>
> 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?
>

I would have preferred Remedy working with the community, rather than talking behind closed doors to those who concern only them.  And I say this as someone who was part involved before UDAs and the public announcement came into the picture.

What I did find interesting, in reflection at dconf, was that Manu countered all arguments (that I could recall) Walter made to keeping the deprecation in place.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Oct 19, 2013 10:11 AM, "Johannes Pfau" <nospam@example.com> wrote:
>
> Am Fri, 18 Oct 2013 11:45:27 -0700
> schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:
>
> > > - 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).
> >
> > I understand how that can be a bother. Walter figures the time is ripe for a new release when we have enough compelling features and fixes. I'll try to make the appropriate announcements in the future prior to deciding on starting a beta.
> >
>
> Why is everyone here so obsessed with feature based releases? Quoting Iain's post from 30.8:
> > It has been about 3 months since the last release of the D front-end implementation.  Three years experience and carrying out over 100 merges into GDC tells me that each time the development cycle starts edging towards it's fourth month, it makes things an absolute nightmare, in both the time consumed merging in the changes, and with time spent tracking down bug reports for unittests/testsuite cases that test backend code generation - with 2.060, 2.061 and 2.063 being the worst releases I have ever had to deal with - before 2.060 the release schedule (if it even qualifies as a 'schedule') was anywhere between 1-2 months.
>
> Even a rough schedule (We try to release a new frontend version every 2 months) would help. Would it have been the end of the world if we just released 2.064 two months ago and 2.065 now?
>
> But what's worse: If we keep making feature based releases then the
> criteria for release should be documented by those making the decision.
> It's as simple as writing two sentences on a wiki page.
> Right now I don't have any clue why the 'time is ripe' now and not 2
> months ago, or one month ago, or in two weeks... It seems like Walter
> is just flipping a coin every month (I don't say it is like that -
> but it looks like that because there's no information on the release
> criteria)
>
> And btw: 5 months between releases is just way too long for users as well. Although the features Walter envisioned for 2.064 may not have been ready 2 months ago we could have shipped many bug fixes two months earlier.

And a big +1 to that as well.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 19 October 2013 21:29, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

>
> On Oct 18, 2013 7:45 PM, "Andrei Alexandrescu" < SeeWebsiteForEmail@erdani.org> wrote:
> >
> > 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?
> >
>
> I would have preferred Remedy working with the community, rather than talking behind closed doors to those who concern only them.  And I say this as someone who was part involved before UDAs and the public announcement came into the picture.
>
Surely you can appreciate that we weren't ready for it to be made public information. We didn't really have much choice. There's always company bureaucracy to deal with.

What I did find interesting, in reflection at dconf, was that Manu
> countered all arguments (that I could recall) Walter made to keeping the
> deprecation in place.
>
I had no idea about the deprecation of the original syntax. I don't recall
ever being a party to any discussion on that matter. The community clearly
voted for @attribute syntax, and as soon as it was done, I switched all our
code over.
I wasn't personally precious about which way the syntax went. We just
needed the feature, and it seems to have been successfully used by many
others since us too, so I really hope most people agree it was a valuable
addition, despite materialising fairly abruptly.
It's also not like I was the first to come up with it either, people had
been talking about attributes for years, I just gave it a nudge.
If we were the only people that *ever* used the initial (experimental)
C#-style [attribute] syntax, then it should be removed and put an end to
this criticism, since I changed our code over within minutes of the new
syntax being made available :)
There's probably no D code anywhere that uses the original C#-style syntax.

On 20 October 2013 07:06, Manu <turkeyman@gmail.com> wrote:
> On 19 October 2013 21:29, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>>
>>
>> On Oct 18, 2013 7:45 PM, "Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote:
>> >
>> > 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?
>> >
>>
>> I would have preferred Remedy working with the community, rather than talking behind closed doors to those who concern only them.  And I say this as someone who was part involved before UDAs and the public announcement came into the picture.
>
> Surely you can appreciate that we weren't ready for it to be made public information. We didn't really have much choice. There's always company bureaucracy to deal with.
>

I can partly understand, and I never felt inclined to push them through the proper channels when I received in personal emails from staff.  For me, if I use a product/project and like a product/project, I want to get involved in with the product/project.  But I suppose not everyone in a games dev company wants to chip in with aiding development of a library/toolchain when they've got a deadline on a game to finish first...


>> What I did find interesting, in reflection at dconf, was that Manu countered all arguments (that I could recall) Walter made to keeping the deprecation in place.
>
> I had no idea about the deprecation of the original syntax. I don't recall
> ever being a party to any discussion on that matter. The community clearly
> voted for @attribute syntax, and as soon as it was done, I switched all our
> code over.
> I wasn't personally precious about which way the syntax went. We just needed
> the feature, and it seems to have been successfully used by many others
> since us too, so I really hope most people agree it was a valuable addition,
> despite materialising fairly abruptly.
> It's also not like I was the first to come up with it either, people had
> been talking about attributes for years, I just gave it a nudge.
> If we were the only people that *ever* used the initial (experimental)
> C#-style [attribute] syntax, then it should be removed and put an end to
> this criticism, since I changed our code over within minutes of the new
> syntax being made available :)
> There's probably no D code anywhere that uses the original C#-style syntax.

That was near enough exactly the answer to the question I recall from dconf.  :o)

The question being on how true Walter was in saying that whoever was using the C#-style syntax had a large codebase, and change-over was not simple for them.  However it is entirely possible that he was referring to another company other than Remedy.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';