November 29, 2012
Holy crap I had no idea that this conference even existed. It turns out I am in melbourne for the next few days for entirely different reasons. Manu thinks I should buy you a drink (i concur)...

I am generally in favour of the language being good rather than being stable at this point in time. This is general keeping with the philosophy that the right way do do things should be the easiest way to do things.



On Thu, Nov 29, 2012 at 8:37 AM, Walter Bright <newshound2@digitalmars.com>wrote:

> On 11/29/2012 3:31 AM, Jonathan M Davis wrote:
>
>> Well, then we're about to reach the point when it's ripe to do that,
>> because
>> D1 is about to no longer be supported. With the beta for 2.061 (whenever
>> that
>> happens), we can adjust how we do the beta process to properly use
>> branches,
>> and then we can adjust how we deal with stable and development branches
>> of D2
>> for future releases.
>>
>
> My thoughts, too.
>
> BTW, just so everyone knows, I am currently in Melbourne at the YOW conference. It's the start of a 3 city tour, so I won't get home until Dec. 8. The hotel internet connection is not much more suitable than for email and newsgroups, and my travel laptop is not well suited for dev, so aside from my conference obligations I intend to be doing things like D articles, learning new stuff, and other back-and-fill work until then.
>
> BTW, it's a great conference. There are a lot of freakin' smart people here, which always makes things a joy.
>


November 29, 2012
On 29 November 2012 11:52, Danni Coy <danni.coy@gmail.com> wrote:

> Holy crap I had no idea that this conference even existed. It turns out I am in melbourne for the next few days for entirely different reasons. Manu thinks I should buy you a drink (i concur)...
>

Yes, and make sure to remind him that it's all your fault! ;)


I am generally in favour of the language being good rather than being
> stable at this point in time. This is general keeping with the philosophy that the right way do do things should be the easiest way to do things.
>
>
>
> On Thu, Nov 29, 2012 at 8:37 AM, Walter Bright <newshound2@digitalmars.com
> > wrote:
>
>> On 11/29/2012 3:31 AM, Jonathan M Davis wrote:
>>
>>> Well, then we're about to reach the point when it's ripe to do that,
>>> because
>>> D1 is about to no longer be supported. With the beta for 2.061 (whenever
>>> that
>>> happens), we can adjust how we do the beta process to properly use
>>> branches,
>>> and then we can adjust how we deal with stable and development branches
>>> of D2
>>> for future releases.
>>>
>>
>> My thoughts, too.
>>
>> BTW, just so everyone knows, I am currently in Melbourne at the YOW conference. It's the start of a 3 city tour, so I won't get home until Dec. 8. The hotel internet connection is not much more suitable than for email and newsgroups, and my travel laptop is not well suited for dev, so aside from my conference obligations I intend to be doing things like D articles, learning new stuff, and other back-and-fill work until then.
>>
>> BTW, it's a great conference. There are a lot of freakin' smart people here, which always makes things a joy.
>>
>
>


November 29, 2012
On 11/29/2012 8:52 PM, Danni Coy wrote:
> Holy crap I had no idea that this conference even existed. It turns out
> I am in melbourne for the next few days for entirely different reasons.
> Manu thinks I should buy you a drink (i concur)...

No need, the booze flows freely here! But hey, drop by. It's in the Sebel Albert Park Hotel.

November 29, 2012
On Thursday, 29 November 2012 at 09:37:57 UTC, Manu wrote:
> On 29 November 2012 03:48, deadalnix <deadalnix@gmail.com> wrote:
>
>> On Thursday, 29 November 2012 at 01:29:12 UTC, Jonathan M Davis wrote:
>>
>>> Since master will almost certainly be the development branch, I don't see
>>> how
>>>
>>> that's a problem. The stable branch will be a separate branch, and
>>> whoever is
>>> managing the stable branch will merge stuff from the master branch into
>>> it.
>>>
>>>
>> In this case, all bug fixes are mixed with new feature and then have to be
>> separated afterward and remerged into the stable branch. This is useless
>> work and it is likely to cause merge conflict in the stable branch.
>>
>> Additionnaly, this become to really suck when several new features are dev
>> at the same time.
>>
>> Finally, yhis is completely inconsistent with how github work in the first
>> place.
>>
>> master make sense as an unstable branch, a release candidate, a beta or
>> whatever, but certainly not a dev branch.
>
>
> Why don't you document precisely what branches you think should exist, and
> the working merge/rebase policies.
> I'm actually very curious to know.
>
>
>  Granted, major stuff like 64-bit Windows support and UDAs should probably
>>> be
>>> introduced on branches separate from master, and it's still a problem if
>>> they're not, but it won't affect the stable branch if they're not.
>>>
>>>
>> It will become all bigfixes will be based on code that contains the new
>> feature.

Manu:
This was mentioned in the group numerous times before, here's one more time to increase awareness even more:
git flow - http://nvie.com/posts/a-successful-git-branching-model/
should be easily adapted for the D development process.

Walter:
a champion cannot solve this issue as this requires participation of all (core) developers. Otherwise we get a _lot_ of redundant after the fact maintenance work. The only way to succeed long term is to remove all single points of failures - the single master branch on the technical side, and a single decision making person (you) on the management side. It can only be possible if you agree to relinquish some control and allow other core developers to _fully_ participate. that includes - review/pull powers, managing their own branches, taking part in the decision making process as to what feature is mature enough to be "released" on the stable branch. No champion can do any of that as it requires your agreement and participation.
Until such changes happen and D becomes _a community process_ (as I see Andrei is rightfully pushing for) there is little chance of a bigger D success.

Also, just to touch the multiple compiler versions overhead you mentioned - The point of maintaining multiple branches is to _minimize_ such overhead, not increase it. This allows for easier management of features, a more gradual release process to prevent regressions and breakage on the release branch, it gives _more control_ and allows for scaling of management to more developers. more branches => less work for you.
November 29, 2012
That is pretty much what I had in mind, but more concrete thought through. I really like it :-) The only things to clear up would be, how long must a release branch exist, before it is considered stable. Which depends on how stable we want things to be.


On Thu, 2012-11-29 at 11:35 +0100, foobar wrote:
> This was mentioned in the group numerous times before, here's one
> more time to increase awareness even more:
> git flow - http://nvie.com/posts/a-successful-git-branching-model/
> should be easily adapted for the D development process.

November 29, 2012
H. S. Teoh wrote:
> Huh? Who said anything about master being stable? Obviously master is unstable by definition, since that's where the development work is being done. The whole point was to introduce a stable branch where we only pull in non-breaking changes from master.

I think you mean "cherry-pick non-breaking changes from master". Cherry- Picking in Git means to just apply one commit from a given branch to another one instead of merging the complete branch.

Thomas Koch
November 29, 2012
On Thu, 2012-11-29 at 12:45 +0100, eskimo wrote:
> That is pretty much what I had in mind, but more concrete thought through. I really like it :-) The only things to clear up would be, how long must a release branch exist, before it is considered stable. Which depends on how stable we want things to be.
> 
> 
> On Thu, 2012-11-29 at 11:35 +0100, foobar wrote:
> > This was mentioned in the group numerous times before, here's one
> > more time to increase awareness even more:
> > git flow - http://nvie.com/posts/a-successful-git-branching-model/
> > should be easily adapted for the D development process.
> 

We would then simply do regular dev releases of the development branch (which is pretty much the releases we have now), so many people test the stuff. Then lots of beta releases from the release branch and after six months or so, the final stable release is made.

November 29, 2012
On 2012-11-29 11:35, foobar wrote:

> Walter:
> a champion cannot solve this issue as this requires participation of all
> (core) developers. Otherwise we get a _lot_ of redundant after the fact
> maintenance work. The only way to succeed long term is to remove all
> single points of failures - the single master branch on the technical
> side, and a single decision making person (you) on the management side.
> It can only be possible if you agree to relinquish some control and
> allow other core developers to _fully_ participate. that includes -
> review/pull powers, managing their own branches, taking part in the
> decision making process as to what feature is mature enough to be
> "released" on the stable branch. No champion can do any of that as it
> requires your agreement and participation.
> Until such changes happen and D becomes _a community process_ (as I see
> Andrei is rightfully pushing for) there is little chance of a bigger D
> success.
>
> Also, just to touch the multiple compiler versions overhead you
> mentioned - The point of maintaining multiple branches is to _minimize_
> such overhead, not increase it. This allows for easier management of
> features, a more gradual release process to prevent regressions and
> breakage on the release branch, it gives _more control_ and allows for
> scaling of management to more developers. more branches => less work for
> you.

So true.

-- 
/Jacob Carlborg
November 29, 2012
On Thu, Nov 29, 2012 at 08:54:43AM +0100, Jacob Carlborg wrote:
> On 2012-11-29 02:08, H. S. Teoh wrote:
> 
> >I think ultimately, as Walter has said, nothing is going to change unless somebody steps up to the plate and champions the effort to make a stable branch. Writing up proposals, specs, and other docs are good in theory, but won't accomplish a thing if nobody actually *does* anything about it. I think 1100110 has stepped up to make a stable branch; let's work with him to make it actually happen.
> 
> I don't think that is enough. We need to get some assurance that if someone creates a stable branch/fork there should be releases based on this branch on dlang.org and the site should be pointing users to the stable version first and foremost.
[...]

Didn't Walter already say that if somebody steps up to do it, he would endorse it?


T

-- 
"640K ought to be enough" -- Bill G., 1984. "The Internet is not a primary goal for PC usage" -- Bill G., 1995. "Linux has no impact on Microsoft's strategy" -- Bill G., 1999.
November 29, 2012
On 28 November 2012 21:40, 1100110 <0b1100110@gmail.com> wrote:
> On 11/28/2012 02:48 PM, Iain Buclaw wrote:
>>
>> On 28 November 2012 20:15, Jacob Carlborg<doob@me.com>  wrote:
>>>
>>> On 2012-11-28 20:54, 1100110 wrote:
>>>
>>>
>>>> Soo....  Theoretically Speaking.
>>>>
>>>> If I were to create an Organization on Github for the management of stable D versions, would you work on it?
>>>
>>>
>>>
>>> Yes, theoretically speaking. Unfortunately I don't have the time to do that.
>>>
>>> --
>>> /Jacob Carlborg
>>
>>
>> So the plans of a stable releases branch never came into fruition?
>>
>
> Would you be interested in helping?

I would support it if were made available.  To do double work is probably out of the question.


-- 
Iain Buclaw

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