On Saturday, 19 October 2013 at 11:39:08 UTC, Iain Buclaw wrote:
>> > 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.
>
> And a big +1 to that as well.

Can't merges be done without release at your discretion in a separate branch or repo? If you keep track of it monthly, then you would have less to merge at the time of release.

Andrei Alexandrescu, el 18 de October a las 11:45 me escribiste:
> >- 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.

Just a brief comment about this: sometimes regularity could be better than tons of new features/bugfixes.

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

That's not the entire story. Back then Walter still push changes to the repo himself. That was the main problem, and fortunately it finally changed. He did that all the time in the past, UDAs wasn't an exception, but it had a high impact back then because Walter was the only one not going through the review process, it so felt doubly unfair.

> So when I have a few free minutes, I try to take a look at the extant pull requests - really, any would do. I try to pull in those that are meaningful and uncontroversial. I agree I could probably spend more time on carefully analyzing interactions between pulls, but that's time I can't afford.

I think the alternative is merging one, wait for the autotester, merge
another and wait for the autotester, and so on. I would be more annoying
having to wait for every test, but there is really no rush to make
a bunch in one go. I think it would be extremely helpful to have some
help from the autotester to auto-merge too. Like marking a pull request
as approved so the auto-tester merges it automatically when it passes the
test. Dreaming?

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
<o_O> parakenotengobarraespaciadora
<o_O> aver
<o_O> estoyarreglandolabarraporkeserompiounapatita

Why not just copy what Linus does with the Linux kernel. Different people in charge of different parts of the compiler. Pull requests should go to the correct person, who then makes a pull request that goes to the main line.



On Mon, Oct 21, 2013 at 12:31 PM, Leandro Lucarella <luca@llucax.com.ar>wrote:

> Andrei Alexandrescu, el 18 de October a las 11:45 me escribiste:
> > >- 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.
>
> Just a brief comment about this: sometimes regularity could be better than tons of new features/bugfixes.
>
> > 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?
>
> That's not the entire story. Back then Walter still push changes to the repo himself. That was the main problem, and fortunately it finally changed. He did that all the time in the past, UDAs wasn't an exception, but it had a high impact back then because Walter was the only one not going through the review process, it so felt doubly unfair.
>
> > So when I have a few free minutes, I try to take a look at the extant pull requests - really, any would do. I try to pull in those that are meaningful and uncontroversial. I agree I could probably spend more time on carefully analyzing interactions between pulls, but that's time I can't afford.
>
> I think the alternative is merging one, wait for the autotester, merge
> another and wait for the autotester, and so on. I would be more annoying
> having to wait for every test, but there is really no rush to make
> a bunch in one go. I think it would be extremely helpful to have some
> help from the autotester to auto-merge too. Like marking a pull request
> as approved so the auto-tester merges it automatically when it passes the
> test. Dreaming?
>
> --
> Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
> ----------------------------------------------------------------------
> GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
> ----------------------------------------------------------------------
> <o_O> parakenotengobarraespaciadora
> <o_O> aver
> <o_O> estoyarreglandolabarraporkeserompiounapatita
>

On 22 October 2013 08:35, Rory McGuire <rjmcguire@gmail.com> wrote:
> Why not just copy what Linus does with the Linux kernel. Different people in charge of different parts of the compiler. Pull requests should go to the correct person, who then makes a pull request that goes to the main line.
>
>


The thing is, there are too few components of D that make it work.

Take DMD for example, you've got: backend, glue, front-end, ctfe.  You could probably stretch it out further into port, target, lexer/parse, template, speller, cppmangle/mangle, hdrgen.   But these are small and on their own don't get many changes to.


Regards
-- 
Iain Buclaw

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

Beta 3:

http://ftp.digitalmars.com/dmd.2.064.beta.3.zip

On 24 October 2013 02:29, Walter Bright <newshound2@digitalmars.com> wrote:
> Beta 3:
>
> http://ftp.digitalmars.com/dmd.2.064.beta.3.zip


I suppose I better start opening a branch in gdc for the new release....


-- 
Iain Buclaw

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

On 24 October 2013 07:44, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> On 24 October 2013 02:29, Walter Bright <newshound2@digitalmars.com> wrote:
>> Beta 3:
>>
>> http://ftp.digitalmars.com/dmd.2.064.beta.3.zip
>
>
> I suppose I better start opening a branch in gdc for the new release....
>
>

Noticed this in meld, the readme.txt file is different in the beta zip for the frontend.

Don't know how you managed it...

https://github.com/D-Programming-Language/dmd/blob/master/src/readme.txt

-- 
Iain Buclaw

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

On Saturday, 12 October 2013 at 22:16:13 UTC, Walter Bright wrote:
> http://ftp.digitalmars.com/dmd2beta.zip
>
> Current list of regressions:
>

It is a specific reason why this is kept?:

http://forum.dlang.org/thread/ohduisigpwdiqhpdewdz@forum.dlang.org#post-btwbpwgluzyxmhphwebp:40forum.dlang.org

On Saturday, 12 October 2013 at 22:16:13 UTC, Walter Bright wrote:
> http://ftp.digitalmars.com/dmd2beta.zip
>
> Current list of regressions:
>
> http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
>

And the famous

int[$] x = [1,2,3];

to declare static arrays and force the compiler to compute the length?

On Friday, 25 October 2013 at 13:24:12 UTC, eles wrote:
> On Saturday, 12 October 2013 at 22:16:13 UTC, Walter Bright wrote:
>> http://ftp.digitalmars.com/dmd2beta.zip
>>
>> Current list of regressions:
>>
>> http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
>>
>
> And the famous
>
> int[$] x = [1,2,3];
>
> to declare static arrays and force the compiler to compute the length?

When was decided to add this? I would love it, but I cannot remember that this was decided.