On 2012-07-25 14:47, Don Clugston wrote:

> If we had an agreed release cycle, it would not happen. The release
> cycle would be a higher authority than any single person, even Walter.

I don't think it's that simple. We would also need some kind of window when you're allowed to commit new things to the repository. This window could end one or two weeks before the release should be out. Otherwise people will think that just "their small commit" can be added just a day before the release day "since it won't cause any problems".

-- 
/Jacob Carlborg

Jacob Carlborg, el 25 de July a las 14:32 me escribiste:
> On 2012-07-25 09:43, Don Clugston wrote:
>
> >We don't need this complexity. The solution is *trivial*. We just need to decide in advance that we will target a release every X weeks, and that it should be delayed only for reasons of stability.
>
> Yeah, but what happens when Walter or someone else decides to start a big project, i.e. implementing COFF support, a week before release? We end up with a bunch of half finished things.
>
> A solution to this would be to create a new branch or not push the changes upstream. Although I don't understand why Walter doesn't already do this.

The same reason he is pushing "revert ..." patches all the time, he is using git as if it were svn :P

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Estoy de acuerdo en que el hombre es igual a los ojos de Dios..., pero
hay algunos que, siendo negros, hacen uso de lo que no les corresponde.
Eso Dios no lo ve.
	-- Ricardo Vaporeso. Manifestación en Mississippi a favor de
		los blancos, 1923.

On Wed, 25 Jul 2012 00:43:23 -0700, Don Clugston <dac@nospam.com> wrote:

> On 24/07/12 19:27, Adam Wilson wrote:
>> On Tue, 24 Jul 2012 01:50:02 -0700, Don Clugston <dac@nospam.com> wrote:
>>
>>> On 16/07/12 09:51, 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.
>>>>
>>>> So what is a stable release?
>>>> A stable release is a complete build of DMD, DRuntime, and Phobos that
>>>> ONLY includes the latest bug-fixes and non-breaking enhancements to
>>>> existing features. It will not include, new features, breaking
>>>> enhancements, and any other code that the core development team may be
>>>> working on.
>>>
>>> I'm not actually sure what this means. I fear that it may be motivated
>>> by an inaccurate assessment of the current situation.
>>>
>>> The existing instability comes almost entirely from Phobos, not from
>>> the compiler. Historically there have been very few instances where
>>> you might want to choose an older compiler in preference to the latest
>>> release.
>>>
>>> As I've said before, the one time when a language change caused
>>> *massive* instability was in the attempt to move AAs from language to
>>> library -- even though that wasn't even supposed to affect existing
>>> code in any way. The other thing that typically causes regressions is
>>> fixes to forward-reference bugs.
>>>
>>> Historically, addition of new language features has NOT caused
>>> instability. What has been true is that features have been added to
>>> the compiler before they were really usable, but they have not broken
>>> existing code. Fairly obviously the 64 bit compiler was quite buggy
>>> when initially released. But even that massive change wasn't much more
>>> buggy than the library AAs! So I am not sure that you can correctly
>>> guess where instability will come from.
>>>
>>> In summary -- I would not expect your stable DMD to be very different
>>> from the normal DMD. Phobos is where the instability issue is.
>>
>> There are three issues we are trying to address:
>>
>> The first and largest issue is the long and variable periods between DMD
>> releases. By the end of the 2.060 Beta period there will have been at
>> least 3.5 months since 2.059. And while for the people who can use Git
>> HEAD this may not be a problem, there are MANY who, for whatever reason,
>> must use the released versions. For them the 314 resolved issues and
>> dozens of regressions fixed are a tantalizingly out of reach.
>
> I agree, but the fact that has happened, is just plain silly. There is no sensible reason why this happened. We were in fact ready for a release nearly two months ago. Somehow it did not happen. That ridiculous situation is the thing that needs to be addressed, IMHO.
>
> In fact, I see no reason why we couldn't do a release every month.
>
>> The second issue is the root of the first. Much of the delay was caused
>> by Walter starting to work on COFF. Which brings up the second point of
>> contention in the community, a significant number of bugs are typically
>> introduced when this new work is introduced precisely because it's not
>> ready,
>
> I do not believe that at all. Where is the evidence for it?
>
>> The third is the result of the first two. The slow release cadence
>> combined with the requirement to push new features along side bug-fixes
>> is seriously holding back the growth of the D community. There is a
>> feeling out here that D is lurching unsteadily forward when it should be
>> smoothly accelerating and most of this feeling is rooted in the prior
>> two causes. This has a very corrosive effect on the community and
>> particularly their willingness to contribute.
>>
>> The goal of dlang-stable is to provide the primary development team
>> (you!) with the ability to release whenever you feel a new feature or
>> enhancement is stable enough to be released WITHOUT having to worry
>> about the ever growing number of bugfixes that are backlogged in with
>> the new features. We are trying to reduce the bugfix pressure so that
>> you can focus on delivering high-quality code when it's ready.
>>
>> The community WANTS these new features, but we CAN'T wait 3.5 months (or
>> more!) for the bugfixes that are baked in with them. We have to provide
>> BOTH.
>
> We don't need this complexity. The solution is *trivial*. We just need to decide in advance that we will target a release every X weeks, and that it should be delayed only for reasons of stability.
>
> An agreement is ALL that is required. But despite repeated requests, I have never been able to get any traction on the idea.
> Instead, people propose all kinds of crazy technical solutions, the most recent ones being changes to bugzilla, trello, and now dlang-stable.
>
> If we say, "There will be a new compiler release every 8 weeks", the problem is solved. Seriously. That one-off agreement is ALL that is required.
>
> But the D community finds it easier to implement a new 64-bit Windows compiler, than to make a agreement on a short-term release schedule. We're a strange bunch, I tell you.

I don't think a rigid release schedule has ever worked in software development. Linus is world-renowned for releasing at what looks like utterly random intervals and I know of very little software that ships on a strict time based cadence. It almost ALWAYS slips for some reason or the other.

I guess my point is that it isn't as easy as making the schedule the final arbiter because it is an attempt to deny that the real world exists. What if Walter is on vacation (I don't know if he believes in vacations but, bear with me) during release week? What then? Do we demand that he organize is life around our precious release schedule?

Also, what about projects that absolutely cannot be completed in under X weeks? Do we just leave the code in the release, half working, waiting to spread all KINDS of bugs?

That sounds to almost everyone here like a recipe for complete disaster. More to the point, I know of no successful project, OSS or Commercial, that follows this model. Development and Stable releases are a staple of the Open-Source world, and it would behoove us to learn from those who went before us. If the model doesn't work, why is it nearly universal? Do we really think that we are better than Linux or LibreOffice or Java?

I would make an argument that such thinking is one of the things holding D back. The industry is crying out for something like D ... just look at the proliferation of new native languages that attempt to address the problems of C/C++ in their own ways; and yet, D, with it's clean syntax and multi-paradigm capabilities is a bit player.

If I had my way, this would all be handled by the dev team via Git branching. But it appears that Walter was unwilling to do the work, so we the community have stepped up. It is an entirely predictable outcome of the very real pains felt in the community. And dlang-stable is essentially a branch of the HEAD repos, just with more process in between. Less efficient, certainly. Will it fail ... I doubt it, but let's find out.

And seriously, the flexibility to release whenever and not be pressured by the community at large because we've gone so long with bugfixes should be freeing to the dev team, not constricting!

As a side note, 64-bit support is critical to the long term viability of D. 32-bit is a rapidly dying concern, once ARM 64-bit goes mainstream the party is over. 32-bit will be archaic by the end of the decade, and out of common usage well before then.

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

Jacob Carlborg, el 25 de July a las 17:08 me  escribiste:
> On 2012-07-25 14:47, Don Clugston wrote:
>
> >If we had an agreed release cycle, it would not happen. The release cycle would be a higher authority than any single person, even Walter.
>
> I don't think it's that simple. We would also need some kind of window when you're allowed to commit new things to the repository.

Like Linux's "merge window". It's simple, you accept new features just for a short period of time, and then just work on stabilizing things and bug fixing.

That said, I wish D never include new features (as a language) unless there is a stable branch, which is still maintained for some time and don't get them.

Bare in mind that DMD != D Programming Language, so adding new features to DMD is perfectly fine for me, like COFF or a new architecture. As long as it doesn't break old code is fine.

> This window could end one or two weeks before the release should be out. Otherwise people will think that just "their small commit" can be added just a day before the release day "since it won't cause any problems".

The window doesn't need to be too long, you can always develop new features in parallel in your own branch while a release is being stabilized. You don't have to wait for the merge window to open to develop new features, is just a *merge* window, when it's open you're new feature should be done already, the window is only there to say "hey! Please pull from this branch!".

If you want a monthly release, I'd say a 1 week merge window is enough (leaves you with 3 weeks for stabilization).

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
<mazzi> Estoy en berlin
<mazzi> Es como palermo
<mazzi> Pero
<mazzi> Mas copado
<mazzi> Muuucho menos careta

On 2012-07-25 19:17, Leandro Lucarella wrote:

> Like Linux's "merge window". It's simple, you accept new features just
> for a short period of time, and then just work on stabilizing things and
> bug fixing.

Yes, exactly.

> That said, I wish D never include new features (as a language) unless
> there is a stable branch, which is still maintained for some time and
> don't get them.

I don't mind new features once in a while, if it's done correctly.

> Bare in mind that DMD != D Programming Language, so adding new features
> to DMD is perfectly fine for me, like COFF or a new architecture. As
> long as it doesn't break old code is fine.

I agree. That is another, slightly related problem with D. Currently, D programming language == DMD == Druntime == Phobos. They're all to closely connected. There should be possible to just to a release of Phobos, for example. Or a release of DMD with just bug fixes.

> The window doesn't need to be too long, you can always develop new
> features in parallel in your own branch while a release is being
> stabilized. You don't have to wait for the merge window to open to
> develop new features, is just a *merge* window, when it's open you're
> new feature should be done already, the window is only there to say
> "hey! Please pull from this branch!".

Exactly.

> If you want a monthly release, I'd say a 1 week merge window is enough
> (leaves you with 3 weeks for stabilization).

Yes, the merge window depends on how often we release.

-- 
/Jacob Carlborg

On 2012-07-25 19:08, Leandro Lucarella wrote:

> The same reason he is pushing "revert ..." patches all the time, he is
> using git as if it were svn :P

I'm suspecting that.

-- 
/Jacob Carlborg

> I don't think a rigid release schedule has ever worked in software
> development. Linus is world-renowned for releasing at what looks like
> utterly random intervals and I know of very little software that ships
> on a strict time based cadence. It almost ALWAYS slips for some reason
> or the other.
>
> I guess my point is that it isn't as easy as making the schedule the
> final arbiter because it is an attempt to deny that the real world
> exists. What if Walter is on vacation (I don't know if he believes in
> vacations but, bear with me) during release week? What then? Do we
> demand that he organize is life around our precious release schedule?

You can at least come to an official agreement that we should release on a given interval. Then we don't need to stop the world to make that happened. Sometimes it will be delayed and that would be acceptable. If we do have a release schedule and Walter, for example, knows he will be on vacation during the release week. We can plan ahead and annoyance that the next release will be delayed or skipped.

> Also, what about projects that absolutely cannot be completed in under X
> weeks? Do we just leave the code in the release, half working, waiting
> to spread all KINDS of bugs?

No, no, no. That's another problem. Don't commit anything to upstream/master that isn't finished. I don't know why Walter does that. Does he not have his own fork? Why not create a new branch at least?

> That sounds to almost everyone here like a recipe for complete disaster.
> More to the point, I know of no successful project, OSS or Commercial,
> that follows this model. Development and Stable releases are a staple of
> the Open-Source world, and it would behoove us to learn from those who
> went before us. If the model doesn't work, why is it nearly universal?
> Do we really think that we are better than Linux or LibreOffice or Java?
>
> I would make an argument that such thinking is one of the things holding
> D back. The industry is crying out for something like D ... just look at
> the proliferation of new native languages that attempt to address the
> problems of C/C++ in their own ways; and yet, D, with it's clean syntax
> and multi-paradigm capabilities is a bit player.
>
> If I had my way, this would all be handled by the dev team via Git
> branching. But it appears that Walter was unwilling to do the work, so
> we the community have stepped up. It is an entirely predictable outcome
> of the very real pains felt in the community. And dlang-stable is
> essentially a branch of the HEAD repos, just with more process in
> between. Less efficient, certainly. Will it fail ... I doubt it, but
> let's find out.
>
> And seriously, the flexibility to release whenever and not be pressured
> by the community at large because we've gone so long with bugfixes
> should be freeing to the dev team, not constricting!
>
> As a side note, 64-bit support is critical to the long term viability of
> D. 32-bit is a rapidly dying concern, once ARM 64-bit goes mainstream
> the party is over. 32-bit will be archaic by the end of the decade, and
> out of common usage well before then.
>

Agree.

-- 
/Jacob Carlborg

On Thursday, July 26, 2012 08:35:26 Jacob Carlborg wrote:
> > I don't think a rigid release schedule has ever worked in software development. Linus is world-renowned for releasing at what looks like utterly random intervals and I know of very little software that ships on a strict time based cadence. It almost ALWAYS slips for some reason or the other.
> > 
> > I guess my point is that it isn't as easy as making the schedule the final arbiter because it is an attempt to deny that the real world exists. What if Walter is on vacation (I don't know if he believes in vacations but, bear with me) during release week? What then? Do we demand that he organize is life around our precious release schedule?
> 
> You can at least come to an official agreement that we should release on a given interval. Then we don't need to stop the world to make that happened. Sometimes it will be delayed and that would be acceptable. If we do have a release schedule and Walter, for example, knows he will be on vacation during the release week. We can plan ahead and annoyance that the next release will be delayed or skipped.
> 
> > Also, what about projects that absolutely cannot be completed in under X weeks? Do we just leave the code in the release, half working, waiting to spread all KINDS of bugs?
> 
> No, no, no. That's another problem. Don't commit anything to upstream/master that isn't finished. I don't know why Walter does that. Does he not have his own fork? Why not create a new branch at least?

There are a number of things that we could do to improve our release process - a number of them revolving around taking proper advantage of git (though not all) - but actually effecting those kind of changes has been incredibly difficult as Don has pointed out. So, while there are a number of things that we _could_ do (and probably _should_ do), the fact that Walter has agreed to this scheme with dlang-stable is actually _huge_. It may help open the door to other changes to the release process (like branching for a beta). AFAIK, Walter never branches for _anything_, though maybe he does have branches of some kind on his computer.

- Jonathan M Davis

On 2012-07-26 08:47, Jonathan M Davis wrote:

> There are a number of things that we could do to improve our release process -
> a number of them revolving around taking proper advantage of git (though not
> all) - but actually effecting those kind of changes has been incredibly difficult
> as Don has pointed out. So, while there are a number of things that we _could_
> do (and probably _should_ do), the fact that Walter has agreed to this scheme
> with dlang-stable is actually _huge_. It may help open the door to other
> changes to the release process (like branching for a beta). AFAIK, Walter
> never branches for _anything_, though maybe he does have branches of some kind
> on his computer.

Yeah, hopefully it will open the door for more changes.

-- 
/Jacob Carlborg