On Wed, 18 Jul 2012 22:20:51 -0700, Caligo <iteronvexor@gmail.com> wrote:

> Just curious, if Walter is too busy to make DMD more stable, then what
> does he spend most of his time on?  I thought we were done with adding
> new features to the language (at least for now)?

While COFF/x64 support for is technically a new feature, it's also one required for the survival of D. x86 is dead on OS X, and dying on Windows and Linux. So i'd say that it's pretty important for Walter to get it in now.

> On Mon, Jul 16, 2012 at 1:29 PM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>> On Monday, July 16, 2012 13:18:55 Caligo wrote:
>>> What?!
>>>
>>> All he has to do is create a branch and call it stable, or whatever,
>>> and use cherry-pick to move small stables patches from other branches
>>> to the stable branch. What's so difficult about that? I don't get
>>> it.
>>
>> It takes up his time for him to do it, and I don't think that there's any
>> chance whatsoever of him giving someone else commit access to the main dmd
>> repository to do this (certainly not at this point). He wasn't interested in
>> changing the versioning or branching stuff at all. He agreed to this plan
>> (which should be minimally disruptive to him) as an experiment. Depending on
>> how it goes, we may change how we deal with the main repo, but for now, we're
>> trying this. And since the likely alternative was that we would continue on
>> exactly as we have been, this is presumably an improvement for the folks who
>> wanted a branch with bug fixes with more frequent releases.
>>
>> - Jonathan M Davis


-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Thursday, July 19, 2012 00:20:51 Caligo wrote:
> Just curious, if Walter is too busy to make DMD more stable, then what does he spend most of his time on?  I thought we were done with adding new features to the language (at least for now)?

No one said anything about Walter not making dmd more stable. What he doesn't have time to spend on is managing a separate branch which includes only bug fixes. He spends lots of time on both bug fixing and new stuff, and his skills are valuable enough that his time is better spent on actually coding than dealing with branch management.

Currently, he's focusing on adding COFF support for Windows, which will make it possible to link using Microsoft's linker and generate 64-bit binaries. It's not a new feature in the sense that the language itself is gaining a feature, but it _is_ new functionality for the compiler.

- Jonathan M Davis

Adam Wilson, el 16 de July a las 11:01 me escribiste:
> On Mon, 16 Jul 2012 01:56:23 -0700, Leandro Lucarella <luca@llucax.com.ar> wrote:
>
> >Adam Wilson, el 16 de July a las 00:51 me escribiste:
> >>As a result of the D Versioning thread, we have decided to create a new organization on Github called dlang-stable. This organization will be responsible for maintaining stable releases of DMD, DRuntime, and Phobos.
> >
> >What will be the version scheme of this dlang-stable compiler? If the git master branch will be the "release", will you increase that version number on each and every commit?
>
> We will probably only bump the version number for packaged releases. Anything else is going to be a lot of relatively useless wheel-spinning.

What I would suggest is if you fork from 1.060, to release 1.060.1, 1.060.2, etc. So is easy to find out what set of features are present in a stable release every time.

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Robar un alfajor es revolucionario, pues rompe con la idea de propiedad,
incluso más que si se tratara de dinero.
	-- publikazion anarkista mdp (hablando de los destrozos de la
	   Cumbre de las Americas en Mar del Plata, 2005)

Adam Wilson, el 16 de July a las 10:56 me escribiste:
> >So if I were to represent a theoretical merge sequence in ascii:
> >
> >            ... former releases ...
> >    DMD Development             GDC Development
> >         >---- DMD 2.060 release ---->
> >         |                           |
> >     DMD Development         DMD 2.060.1 release
> >         v                           v
> >         |                           |
> >         |                   DMD 2.060.2 release
> >         |                           v
> >         |                           |
> >         |                   DMD 2.060.3 release
> >         |                           v
> >         |                           |
> >     DMD 2.061 beta          DMD 2.060.4 release
> >         v                           v
> >         |                           |
> >     DMD 2.061 RC            DMD 2.060.5 release
> >         v                           v
> >         |                           |
> >         >-- DMD 2.061 release ------>
> >
> >
> >Would this be a correct way of utilising this new process?
> >
>
> I'd say mostly correct. The last step is the one where we might

Mmm, this makes me wonder if the stable releases based on a particular official release will live only until the next official release is out, or if they will be long-term. I thought it was the later, so people don't have to worry about bugs related to new features they don't care about, but now I'm not so sure.

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
ACCIDENTE FATAL EN FLORES, MUEREN DOS PERSONAS Y UN BOLIVIANO
	-- Crónica TV

Andrei Alexandrescu, el 16 de July a las 12:41 me escribiste:
> On 7/16/12 3:51 AM, Adam Wilson wrote:
> >As a result of the D Versioning thread, we have decided to create a new organization on Github called dlang-stable. This organization will be responsible for maintaining stable releases of DMD, DRuntime, and Phobos.
> [snip]
> >Thank you for reading and I hope you enjoy D's new Stable releases!
>
> This is a wonderful initiative that I hope will catch on.
>
> Walter and I are fully behind this experiment. We will make/accept changes to the download pages to take into account this new branch.
>
> The main threat I see is bugfixes that depend on code previously introduced with now features. I'm not sure how frequent that situation is.
>
> Finally, one suggestion: I suggest you relentlessly work to automate the process to the point where you issue e.g. the command
>
> ./merge 534d44c979 70dcb958ea
>
> and the script merges in the two specified commits, builds everything, runs the test suite, runs the Phobos unittests, and if all worked, builds packages and uploads them making them available right away.

If he is just going to cherry pick patches, then that can be all automated using git directly, using a commit hook to test the commit (and reject it if it fails). Something that everybody should have if running the test suite weren't so slow :P

What you can do is have a git repository in the test suite server, and plug git to the autotester, and make it only succeed if the autotester result was good, the resulting repository will NEVER have a non-working DMD. This way the testing is asynchronous, so it doesn't bother the developer, but you also make sure the "good" public repository is always healthy, something that is not happening now because is the other way around. Walter first pushes changes to the "good" public repository and the autotester runs after the commits are published, so there is no way to undo the commits and fix them privately.

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
"The Guinness Book of Records" holds the record for being the most stolen book in public libraries

On Sat, 21 Jul 2012 07:32:19 -0700, Leandro Lucarella <luca@llucax.com.ar> wrote:

> Adam Wilson, el 16 de July a las 10:56 me escribiste:
>> >So if I were to represent a theoretical merge sequence in ascii:
>> >
>> >            ... former releases ...
>> >    DMD Development             GDC Development
>> >         >---- DMD 2.060 release ---->
>> >         |                           |
>> >     DMD Development         DMD 2.060.1 release
>> >         v                           v
>> >         |                           |
>> >         |                   DMD 2.060.2 release
>> >         |                           v
>> >         |                           |
>> >         |                   DMD 2.060.3 release
>> >         |                           v
>> >         |                           |
>> >     DMD 2.061 beta          DMD 2.060.4 release
>> >         v                           v
>> >         |                           |
>> >     DMD 2.061 RC            DMD 2.060.5 release
>> >         v                           v
>> >         |                           |
>> >         >-- DMD 2.061 release ------>
>> >
>> >
>> >Would this be a correct way of utilising this new process?
>> >
>>
>> I'd say mostly correct. The last step is the one where we might
>
> Mmm, this makes me wonder if the stable releases based on a particular
> official release will live only until the next official release is out,
> or if they will be long-term. I thought it was the later, so people
> don't have to worry about bugs related to new features they don't care
> about, but now I'm not so sure.

Actually, I specifically mention that new features will left out until stability is achieved. But at some point we will fold in the new features from HEAD, our goal is to specifically AVOID creating a D1/D2 style split.

> --
> Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
> ----------------------------------------------------------------------
> GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
> ----------------------------------------------------------------------
> ACCIDENTE FATAL EN FLORES, MUEREN DOS PERSONAS Y UN BOLIVIANO
> 	-- Crónica TV


-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Sat, 21 Jul 2012 07:27:39 -0700, Leandro Lucarella <luca@llucax.com.ar> wrote:

> Adam Wilson, el 16 de July a las 11:01 me escribiste:
>> On Mon, 16 Jul 2012 01:56:23 -0700, Leandro Lucarella
>> <luca@llucax.com.ar> wrote:
>>
>> >Adam Wilson, el 16 de July a las 00:51 me escribiste:
>> >>As a result of the D Versioning thread, we have decided to create a
>> >>new organization on Github called dlang-stable. This organization
>> >>will be responsible for maintaining stable releases of DMD,
>> >>DRuntime, and Phobos.
>> >
>> >What will be the version scheme of this dlang-stable compiler? If the
>> >git master branch will be the "release", will you increase that version
>> >number on each and every commit?
>>
>> We will probably only bump the version number for packaged releases.
>> Anything else is going to be a lot of relatively useless
>> wheel-spinning.
>
> What I would suggest is if you fork from 1.060, to release 1.060.1,
> 1.060.2, etc. So is easy to find out what set of features are present in
> a stable release every time.

This seems to be the general consensus and I think it's where we'll go.

> --
> Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
> ----------------------------------------------------------------------
> GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
> ----------------------------------------------------------------------
> Robar un alfajor es revolucionario, pues rompe con la idea de propiedad,
> incluso más que si se tratara de dinero.
> 	-- publikazion anarkista mdp (hablando de los destrozos de la
> 	   Cumbre de las Americas en Mar del Plata, 2005)


-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Adam Wilson, el 21 de July a las 15:03 me escribiste:
> >Mmm, this makes me wonder if the stable releases based on a particular official release will live only until the next official release is out, or if they will be long-term. I thought it was the later, so people don't have to worry about bugs related to new features they don't care about, but now I'm not so sure.
>
> Actually, I specifically mention that new features will left out until stability is achieved. But at some point we will fold in the new features from HEAD, our goal is to specifically AVOID creating a D1/D2 style split.

Yes, of course, but these updates will not be done for each and every official DMD release, they will be done in a timespan in the order of years for example? I.e. like any other serious language out there? :P

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
The biggest lie you can tell yourself is
When I get what I want I will be happy

On Sun, 22 Jul 2012 11:59:39 -0700, Leandro Lucarella <luca@llucax.com.ar> wrote:

> Adam Wilson, el 21 de July a las 15:03 me escribiste:
>> >Mmm, this makes me wonder if the stable releases based on a particular
>> >official release will live only until the next official release is out,
>> >or if they will be long-term. I thought it was the later, so people
>> >don't have to worry about bugs related to new features they don't care
>> >about, but now I'm not so sure.
>>
>> Actually, I specifically mention that new features will left out
>> until stability is achieved. But at some point we will fold in the
>> new features from HEAD, our goal is to specifically AVOID creating a
>> D1/D2 style split.
>
> Yes, of course, but these updates will not be done for each and every
> official DMD release, they will be done in a timespan in the order of
> years for example? I.e. like any other serious language out there? :P
>
> --
> Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
> ----------------------------------------------------------------------
> GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
> ----------------------------------------------------------------------
> The biggest lie you can tell yourself is
> When I get what I want I will be happy

I can't really say, but it sounds like what you are asking for is D2/D3, thats not really the scope of the dlang-stable project, we just want builds of D2 that do not include new features until the community feels that those features are stable enough. Which means we will periodically roll in the new features, probably on the order of months, which pretty typical for 2.x type releases.

If Walter does eventually decide on a D3, then we will probably maintain a separate D2 maintenance branch for a while, like all the other big compilers, but that's years on down the road.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Mon, 16 Jul 2012 13:05:29 -0700, Brad Anderson <eco@gnuk.net> wrote:

> On Monday, 16 July 2012 at 19:35:47 UTC, Andrei Alexandrescu wrote:
>> [snip]
>>
>> I agree this would be more direct. But I fail to see how Walter cherry-picking stuff is "basically no additional work", whereas Adam doing essentially the same is an unenviable "amount of labor".
>>
>
> He wouldn't be cherry-picking anything. All he'd have to do is a checkout (one command) before switching between working on features (and by features I mean breaking or major changes) or bugs. Adam, on the other hand, would be running git cherry-pick over and over dodging changes he determines are too risky to include in stable. It also seems like there is a lot more room for mistakes to be made doing it this way.

There certainly is more room for mistakes, which is why I think that a team-based approach is better. I've also finished putting together some scripts to automate the various processes. I think that the merge script can especially take a lot of the work and time out of the equation. With a single call we can merge as many commits as we feel comfortable with, build them, run unittests and push the changes to the server. At this point i'll probably spend more time deciding which commits are safe to pick than I will actually merging them. At least until I hit a decent merge conflict. But hey, everything helps! :-)

Scripts are available here: https://github.com/dlang-stable/utilities

>> Besides, if Walter is at the same time doing things and deciding their category may work worse than a small team making the assessment by consensus.
>>
>
> Perhaps. More eyes are better. It just seems like way more work than is necessary to accomplish the goal of isolating breaking changes so that stable releases can go out easier. The end result is all I'm interested in personally since I'm not the one doing the work here. I'm not too concerned with whether you use my idea or not. I just thought you guys might like to hear an alternative that is much easier for you while remaining easy for Walter.
>
> Regards,
> Brad Anderson


-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/