July 16, 2012
On 16 July 2012 18:56, Adam Wilson <flyboynw@gmail.com> wrote:
> On Mon, 16 Jul 2012 10:26:31 -0700, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>
>> On Monday, 16 July 2012 at 16:39:45 UTC, Marco Leise wrote:
>>>
>>> Am Mon, 16 Jul 2012 17:21:39 +0100
>>> schrieb Iain Buclaw <ibuclaw@ubuntu.com>:
>>>
>>>> On 16 July 2012 14:00, Marco Leise <Marco.Leise@gmx.de> wrote:
>>>> > Am Mon, 16 Jul 2012 00:51:16 -0700
>>>> > schrieb "Adam Wilson" <flyboynw@gmail.com>:
>>>> >
>>>> > As it shows, the beta phase doesn't always catch all > regressions in people's code, so I encourage you to do this > project and eventually it will be used by GDC and other > major from-source projects. By the way: Should this also > later become the base for the official zip file download?
>>>> > > IIRC Walter wanted to keep track of the DMD downloads from > the main web
>>>> > site (no redistribution) and hotfixed versions > of D could become
>>>> > increasingly popular.
>>>> >
>>>> > --
>>>> > Marco
>>>> >
>>>>  And what benefits would GDC get from opting to use this rather than
>>>> the normal releases?
>>>
>>>
>>> What he said, [regression] fixes that didn't make it into the initial
>>> release. I don't know about GDC's 'patch level', but for 2.059 I applied
>>> patches for the following issues after release, to have it feel as solid as
>>> good old 2.058:
>>> - issue-7907
>>> - issue-7911
>>> - issue-7922
>>> - outOfMemoryError-undeprecation
>>> - std-path-sep-deprecation
>>>
>>> In case crypto algorithms become part of Phobos, some patches may improve security as well. Didn't you say you work only with the GitHub release tags for stability?
>>
>>
>> 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 differ though, as we may choose to wait on regression and other bug-fixes to any new features in that release. But we might not wait if the build consists of no new features, just breaking changes to existing ones. It will be more of a conversation with the community about how stable they feel the changes in the latest release are. For example, of the new COFF support is still highly unstable (lots of fix commits), we might wait until that settles down before merging in the entirety of the development repos.
>

And how does DMD backend support for COFF affect GDC? :-)



-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
July 16, 2012
On Monday, 16 July 2012 at 07:51:16 UTC, 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.
>
> How often will you release?
> The goal of this project is that D is stable at all times. Therefore, our primary method of release will simply be Git-HEAD. However, we will also make available frequent packaged distributions for those who may be unable to use Git-HEAD. While the exact release cadence is to be determined, we expect it to be more frequent then the current release schedule.
>
> What if a bug fix breaks my code?
> We will still issue the fix. Fixing the broken behavior is more important than allowing broken code to continue.
>
> How much will the core team be involved?
> The idea behind this project is that the core team needs to focus on developing D as fast as possible. However, we will coordinate with them as necessary when it is time to pull in the latest work from the development repositories and as any conflicts arise to between the two codebases.
>
> Is this a fork of D?
> No. Our goal is to follow the development of D perfectly. All the code for the stable releases will be received from the primary repositories. We will simply be cherry-picking the commits we want in the release.
>
> Will new features ever be merged from the primary repositories?
> Yes. As new features mature, they will be pulled into the stable repos. Precisely when this happens will be a mutual decision by all the developers involved and the community at large.
>
> I have a bug fix ready to go. Who do I send the pull request to?
> Please send all pull requests to the primary development repositories (D-Programming-Language). From there we will incorporate your fixes as they are merged into the primary repositories.
>
> I still want to hack on DMD/DRuntme/Phobos. Where do I point my local repositories?
> Then nothing will change for you. You can keep all your existing remotes.
>
> Who is developing this project?
> For the moment, just myself, with support from Andrei. Although, it would be much appreciated if a few others would step forward as release maintainers to help with the bug fix merges and quality control. If you are interested, I would love to hear from you. You can reply here, send me an email, or contact me on GitHub (handle: LightBender).
>
> OK, I'm sold! When will the first Stable release be ready?
> Not until after the official release of 2.060. We feel that it is best to this project from a released build of DMD and from then on maintain the stable versions. While it is technically feasible to go back and start from 2.059, the number of bug fixes since then it would make it a gargantuan task. In addition, this period allows us to build-up the release team, synchronize with the core team, and polish our release procedures. After 2.060 we will begin releasing stable versions of D
>
> Where can I find these stable releases?
> The stable releases are located on GitHub at https://github.com/dlang-stable
> Once the packaged release become available you can expect to see them on http://www.dlang.org/
>
> If you have any more questions or comments, please reply below and will attempt to answer them to the best of my ability.
>
> Thank you for reading and I hope you enjoy D's new Stable releases!

Even though I've said this to you in IRC, I'll share here publicly that I think this should really be done on a branch in the main repo[1].  This setup seems overly complicated and confusing (though I recognize you are just working with limitations imposed upon you).


I'd like to propose an alternative to this cherry-picking solution though which is much easier and plays to git's strengths.

1. Features would be pull requests targeting D-P-L/dmd:master. Walter could still push his features directly.

2. Bugfixes would be pull requests targeting D-P-L/dmd:stable. Walter could still push his bugfixes directly.

3. D-P-L/dmd:master would periodically merge D-P-L/dmd:stable to pull bug fixes in.


This setup requires almost no changes by all contributors. Here is a mini guide for contributors outlining the slightly changed workflow.

Working on a bugfix:
1. git checkout -b issue-555 stable
2. ... hack hack hack commit ...
3. git push origin issue-555 (Walter can just do `git push origin stable` and skip step 4, assuming origin is D-P-L)
4. Make pull request targeting stable

(most people already do this but branch from master)

Working on a feature:
1. git checkout -b constpocalypse master
2. ... hack hack hack commit ...
3. git push origin constpocalypse (Walter can just do `git push origin master` and skip step 4)
4. Make pull request targeting master

(this is exactly the workflow people already use)

Even easier is that Walter can work directly on local master and stable branches if he'd like to not use topic branches. The only thing he'd have to do is `git checkout stable` before working on a bug and `git checkout master` before working on a feature. No other changes are required.

Periodically someone (anyone with push access) does the following to pull bug fixes into master:
1. git checkout master; git merge stable; git push origin;

What is gained by this is that nobody needs to cherry-pick bugfixes into a stable repo. Cherry-picking is a substantial amount of work (for which I salute you for volunteering to undertake). It just seems unnecessary in the world of git.

I'd like to stress one more time that **this is basically no additional work for contributors or Walter**.  It's simply categorizing changes.

The setup you are planning will work, of course, but I do not envy the amount of labor it will require. Whichever way it is done is a step in the right direction and I'm glad you are taking it on.

Regards,
Brad Anderson

[1] For those that are afraid of less established people having push access to the main repo, just remember that the worst thing that can happen is history is "lost" through a push -f which can be easily undone by anyone else on the team doing their own push -f to restore. The hitmen can be dispatched at our leisure.

P.S. This would be my real ideal setup (and is one I use daily) but would require more changes: http://nvie.com/posts/a-successful-git-branching-model/
July 16, 2012
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.



On Mon, Jul 16, 2012 at 1:03 PM, Adam Wilson <flyboynw@gmail.com> wrote:
> On Mon, 16 Jul 2012 10:51:59 -0700, Caligo <iteronvexor@gmail.com> wrote:
>
>> Good thing that this is an experiment because creating a new organization just for something like this is a stupid idea.  Is it so difficult to create branches and use the features that git provides?!?
>
>
> Walter was very uneasy about opening up the primary DMD repo in that manner. Maybe if this experiment proves successful he will be more open to allowing the work to take place in the primary repo? Let's make this project successful and show Walter the true power of Git!
>
>
> --
> Adam Wilson
> IRC: LightBender
> Project Coordinator
> The Horizon Project
> http://www.thehorizonproject.org/
July 16, 2012
On Mon, 16 Jul 2012 11:12:38 -0700, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> On 16 July 2012 18:56, Adam Wilson <flyboynw@gmail.com> wrote:
>> On Mon, 16 Jul 2012 10:26:31 -0700, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>>
>>> On Monday, 16 July 2012 at 16:39:45 UTC, Marco Leise wrote:
>>>>
>>>> Am Mon, 16 Jul 2012 17:21:39 +0100
>>>> schrieb Iain Buclaw <ibuclaw@ubuntu.com>:
>>>>
>>>>> On 16 July 2012 14:00, Marco Leise <Marco.Leise@gmx.de> wrote:
>>>>> > Am Mon, 16 Jul 2012 00:51:16 -0700
>>>>> > schrieb "Adam Wilson" <flyboynw@gmail.com>:
>>>>> >
>>>>> > As it shows, the beta phase doesn't always catch all > regressions  
>>>>> in
>>>>> > people's code, so I encourage you to do this > project and  
>>>>> eventually it
>>>>> > will be used by GDC and other > major from-source projects. By the  
>>>>> way:
>>>>> > Should this also > later become the base for the official zip file  
>>>>> download?
>>>>> > > IIRC Walter wanted to keep track of the DMD downloads from > the  
>>>>> main web
>>>>> > site (no redistribution) and hotfixed versions > of D could become
>>>>> > increasingly popular.
>>>>> >
>>>>> > --
>>>>> > Marco
>>>>> >
>>>>>  And what benefits would GDC get from opting to use this rather than
>>>>> the normal releases?
>>>>
>>>>
>>>> What he said, [regression] fixes that didn't make it into the initial
>>>> release. I don't know about GDC's 'patch level', but for 2.059 I applied
>>>> patches for the following issues after release, to have it feel as solid as
>>>> good old 2.058:
>>>> - issue-7907
>>>> - issue-7911
>>>> - issue-7922
>>>> - outOfMemoryError-undeprecation
>>>> - std-path-sep-deprecation
>>>>
>>>> In case crypto algorithms become part of Phobos, some patches may improve
>>>> security as well. Didn't you say you work only with the GitHub release tags
>>>> for stability?
>>>
>>>
>>> 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 differ
>> though, as we may choose to wait on regression and other bug-fixes to any
>> new features in that release. But we might not wait if the build consists of
>> no new features, just breaking changes to existing ones. It will be more of
>> a conversation with the community about how stable they feel the changes in
>> the latest release are. For example, of the new COFF support is still highly
>> unstable (lots of fix commits), we might wait until that settles down before
>> merging in the entirety of the development repos.
>>
>
> And how does DMD backend support for COFF affect GDC? :-)
>

Very little I imagine. But we are working against DMD. Since you only want the front-end fixes, I imagine that (at least in terms of the backend) you won't care much when we merge that feature. My point was more general to versioning, in that we might update the stable branches to the new release day one. The new fixes will still appear though. Obviously this would have more impact for you with any new front-end features.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
July 16, 2012
On Mon, 16 Jul 2012 11:18:55 -0700, Caligo <iteronvexor@gmail.com> 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.
>
>
>
> On Mon, Jul 16, 2012 at 1:03 PM, Adam Wilson <flyboynw@gmail.com> wrote:
>> On Mon, 16 Jul 2012 10:51:59 -0700, Caligo <iteronvexor@gmail.com> wrote:
>>
>>> Good thing that this is an experiment because creating a new
>>> organization just for something like this is a stupid idea.  Is it so
>>> difficult to create branches and use the features that git provides?!?
>>
>>
>> Walter was very uneasy about opening up the primary DMD repo in that manner.
>> Maybe if this experiment proves successful he will be more open to allowing
>> the work to take place in the primary repo? Let's make this project
>> successful and show Walter the true power of Git!
>>
>>
>> --
>> Adam Wilson
>> IRC: LightBender
>> Project Coordinator
>> The Horizon Project
>> http://www.thehorizonproject.org/

He already works on D full-time, this would only slow him down. The other option is to open the repos to even more people with master push rights, and it was a months-long struggle to convince him to let Kenji, Brad, and Don push. Imagine the effort it will take to convince him to let someone else in with push rights?

This is a step in the process. Should it prove successful we can reopen the organizational discussion, but first, let's just make it work.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
July 16, 2012
On Mon, 16 Jul 2012 11:14:07 -0700, Brad Anderson <eco@gnuk.net> wrote:

> On Monday, 16 July 2012 at 07:51:16 UTC, 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.
>>
>> How often will you release?
>> The goal of this project is that D is stable at all times. Therefore, our primary method of release will simply be Git-HEAD. However, we will also make available frequent packaged distributions for those who may be unable to use Git-HEAD. While the exact release cadence is to be determined, we expect it to be more frequent then the current release schedule.
>>
>> What if a bug fix breaks my code?
>> We will still issue the fix. Fixing the broken behavior is more important than allowing broken code to continue.
>>
>> How much will the core team be involved?
>> The idea behind this project is that the core team needs to focus on developing D as fast as possible. However, we will coordinate with them as necessary when it is time to pull in the latest work from the development repositories and as any conflicts arise to between the two codebases.
>>
>> Is this a fork of D?
>> No. Our goal is to follow the development of D perfectly. All the code for the stable releases will be received from the primary repositories. We will simply be cherry-picking the commits we want in the release.
>>
>> Will new features ever be merged from the primary repositories?
>> Yes. As new features mature, they will be pulled into the stable repos. Precisely when this happens will be a mutual decision by all the developers involved and the community at large.
>>
>> I have a bug fix ready to go. Who do I send the pull request to?
>> Please send all pull requests to the primary development repositories (D-Programming-Language). From there we will incorporate your fixes as they are merged into the primary repositories.
>>
>> I still want to hack on DMD/DRuntme/Phobos. Where do I point my local repositories?
>> Then nothing will change for you. You can keep all your existing remotes.
>>
>> Who is developing this project?
>> For the moment, just myself, with support from Andrei. Although, it would be much appreciated if a few others would step forward as release maintainers to help with the bug fix merges and quality control. If you are interested, I would love to hear from you. You can reply here, send me an email, or contact me on GitHub (handle: LightBender).
>>
>> OK, I'm sold! When will the first Stable release be ready?
>> Not until after the official release of 2.060. We feel that it is best to this project from a released build of DMD and from then on maintain the stable versions. While it is technically feasible to go back and start from 2.059, the number of bug fixes since then it would make it a gargantuan task. In addition, this period allows us to build-up the release team, synchronize with the core team, and polish our release procedures. After 2.060 we will begin releasing stable versions of D
>>
>> Where can I find these stable releases?
>> The stable releases are located on GitHub at https://github.com/dlang-stable
>> Once the packaged release become available you can expect to see them on http://www.dlang.org/
>>
>> If you have any more questions or comments, please reply below and will attempt to answer them to the best of my ability.
>>
>> Thank you for reading and I hope you enjoy D's new Stable releases!
>
> Even though I've said this to you in IRC, I'll share here publicly that I think this should really be done on a branch in the main repo[1].  This setup seems overly complicated and confusing (though I recognize you are just working with limitations imposed upon you).
>
>
> I'd like to propose an alternative to this cherry-picking solution though which is much easier and plays to git's strengths.
>
> 1. Features would be pull requests targeting D-P-L/dmd:master. Walter could still push his features directly.
>
> 2. Bugfixes would be pull requests targeting D-P-L/dmd:stable. Walter could still push his bugfixes directly.
>
> 3. D-P-L/dmd:master would periodically merge D-P-L/dmd:stable to pull bug fixes in.
>
>
> This setup requires almost no changes by all contributors. Here is a mini guide for contributors outlining the slightly changed workflow.
>
> Working on a bugfix:
> 1. git checkout -b issue-555 stable
> 2. ... hack hack hack commit ...
> 3. git push origin issue-555 (Walter can just do `git push origin stable` and skip step 4, assuming origin is D-P-L)
> 4. Make pull request targeting stable
>
> (most people already do this but branch from master)
>
> Working on a feature:
> 1. git checkout -b constpocalypse master
> 2. ... hack hack hack commit ...
> 3. git push origin constpocalypse (Walter can just do `git push origin master` and skip step 4)
> 4. Make pull request targeting master
>
> (this is exactly the workflow people already use)
>
> Even easier is that Walter can work directly on local master and stable branches if he'd like to not use topic branches. The only thing he'd have to do is `git checkout stable` before working on a bug and `git checkout master` before working on a feature. No other changes are required.
>
> Periodically someone (anyone with push access) does the following to pull bug fixes into master:
> 1. git checkout master; git merge stable; git push origin;
>
> What is gained by this is that nobody needs to cherry-pick bugfixes into a stable repo. Cherry-picking is a substantial amount of work (for which I salute you for volunteering to undertake). It just seems unnecessary in the world of git.
>
> I'd like to stress one more time that **this is basically no additional work for contributors or Walter**.  It's simply categorizing changes.
>
> The setup you are planning will work, of course, but I do not envy the amount of labor it will require. Whichever way it is done is a step in the right direction and I'm glad you are taking it on.
>
> Regards,
> Brad Anderson
>
> [1] For those that are afraid of less established people having push access to the main repo, just remember that the worst thing that can happen is history is "lost" through a push -f which can be easily undone by anyone else on the team doing their own push -f to restore. The hitmen can be dispatched at our leisure.
>
> P.S. This would be my real ideal setup (and is one I use daily) but would require more changes: http://nvie.com/posts/a-successful-git-branching-model/

As I said on IRC, I tend to agree with you that this is a better solution, and it certainly plays to git's strengths. However, it's the best compromise we could get for now, and something needs to be done for everyone waiting on bug-fixes.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
July 16, 2012
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
July 16, 2012
On Mon, 16 Jul 2012 10:39:04 -0700, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> On 16 July 2012 18:31, Adam Wilson <flyboynw@gmail.com> wrote:
>> On Mon, 16 Jul 2012 09:21:39 -0700, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>>
>>> On 16 July 2012 14:00, Marco Leise <Marco.Leise@gmx.de> wrote:
>>>>
>>>> Am Mon, 16 Jul 2012 00:51:16 -0700
>>>> schrieb "Adam Wilson" <flyboynw@gmail.com>:
>>>>
>>>> As it shows, the beta phase doesn't always catch all regressions in
>>>> people's code, so I encourage you to do this project and eventually it will
>>>> be used by GDC and other major from-source projects. By the way: Should this
>>>> also later become the base for the official zip file download? IIRC Walter
>>>> wanted to keep track of the DMD downloads from the main web site (no
>>>> redistribution) and hotfixed versions of D could become increasingly
>>>> popular.
>>>>
>>>> --
>>>> Marco
>>>>
>>>
>>> And what benefits would GDC get from opting to use this rather than
>>> the normal releases?
>>>
>>
>> The main benefit I could see is the faster cycle focusing on bugs. I don't
>> know what GCC's release cycle is (something tells me it's pretty glacial),
>> but for any users of your Git-HEAD code, the bug fixes could certainly
>> appear faster.
>>
>
> It's roughly once a year, maybe a little less.  Depends on
> regressions, open bugs, etc.
>

In other words, glacial. :-) But, if it's of interest to you to use the stable releases as a basis for GDC we wouldn't mind.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
July 16, 2012
On 16 July 2012 19:48, Adam Wilson <flyboynw@gmail.com> wrote:
> On Mon, 16 Jul 2012 10:39:04 -0700, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>
>> On 16 July 2012 18:31, Adam Wilson <flyboynw@gmail.com> wrote:
>>>
>>> On Mon, 16 Jul 2012 09:21:39 -0700, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>>>
>>>> On 16 July 2012 14:00, Marco Leise <Marco.Leise@gmx.de> wrote:
>>>>>
>>>>>
>>>>> Am Mon, 16 Jul 2012 00:51:16 -0700
>>>>> schrieb "Adam Wilson" <flyboynw@gmail.com>:
>>>>>
>>>>> As it shows, the beta phase doesn't always catch all regressions in
>>>>> people's code, so I encourage you to do this project and eventually it
>>>>> will
>>>>> be used by GDC and other major from-source projects. By the way: Should
>>>>> this
>>>>> also later become the base for the official zip file download? IIRC
>>>>> Walter
>>>>> wanted to keep track of the DMD downloads from the main web site (no
>>>>> redistribution) and hotfixed versions of D could become increasingly
>>>>> popular.
>>>>>
>>>>> --
>>>>> Marco
>>>>>
>>>>
>>>> And what benefits would GDC get from opting to use this rather than the normal releases?
>>>>
>>>
>>> The main benefit I could see is the faster cycle focusing on bugs. I
>>> don't
>>> know what GCC's release cycle is (something tells me it's pretty
>>> glacial),
>>> but for any users of your Git-HEAD code, the bug fixes could certainly
>>> appear faster.
>>>
>>
>> It's roughly once a year, maybe a little less.  Depends on regressions, open bugs, etc.
>>
>
> In other words, glacial. :-) But, if it's of interest to you to use the stable releases as a basis for GDC we wouldn't mind.
>
>


Will see how it goes.  Typically in the past I have cherry picked creamy features (__vector support, the recent updates to align) and merged in any fixes for bugs raised in GDC that are because of, and fixed in the D frontend prior to merging releases.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
July 16, 2012
On 7/16/12 2:14 PM, Brad Anderson wrote:
[snip]
> What is gained by this is that nobody needs to cherry-pick bugfixes into
> a stable repo. Cherry-picking is a substantial amount of work (for which
> I salute you for volunteering to undertake). It just seems unnecessary
> in the world of git.
>
> I'd like to stress one more time that **this is basically no additional
> work for contributors or Walter**. It's simply categorizing changes.
>
> The setup you are planning will work, of course, but I do not envy the
> amount of labor it will require. Whichever way it is done is a step in
> the right direction and I'm glad you are taking it on.
>
> Regards,
> Brad Anderson

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".

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.


Andrei