On 11/30/2012 05:30 AM, 1100110 wrote:
> A few of the requests were:(in no specific order)
> Base Update and Upgrade paths on successful projects, such as Debian's
> Three branches.

To be honest, I don't think that what is needed is a detailed proposal for the branch structure etc.  There are only so many ways you can do it, after all, and the details don't matter so much as long as an effective stable version comes out of it.

What _is_ needed is to get people committed to actually doing the work to maintain a stable version.  Once you have the people, they can work out the details for themselves.


> I can also include specific versions of LDC and GDC (and any other compiler
> willing to target a release.)

I think that before bringing LDC/GDC into the equation, it would help if we got to the point where the frontend was genuinely portable, as discussed e.g. here:
http://forum.dlang.org/post/mailman.1565.1352137245.5162.d.gnu@puremagic.com

On 11/30/12 4:49 AM, 1100110 wrote:
> Andrei's support is also necessary, IIRC he is one of main person behind
> phobos. A stable version of D is not useful without a stable version of
> phobos and druntime to go with it.

I'm very supportive of a serious, meaningful initiative.

My perception is that we're having growing pains - our process is lagging behind the participation in the project and the attention it receives. If Walter and I do not acknowledge that in time and act swiftly on it, we're heading toward a crisis in the community much, much larger and dangerous than the D1/D2 schism.


Andrei

On Friday, 30 November 2012 at 04:30:10 UTC, 1100110 wrote:
> In the thread: Breaking D2 Language/Spec, A lot of good points were made regarding a Stable branch for D.
>
> A few of the requests were:(in no specific order)
> Base Update and Upgrade paths on successful projects, such as Debian's
> Three branches.
>
> 1. Stable branch
> - Stable branch only receives bug fixes and is updated at predetermined intervals.
> - Updates are clones of upstream.
> - Do not update too often, as that causes too much work. (6, 8, 12 months)
> - Do not break code unless extremely necessary. (Not even then?)
> - Document all changes, Document every release
> - Make each transition as simple as possible.
> - Warn stable users about soon to be broken code.
> - Do not allow Stable and upstream to diverge too much. (See Walters's comment regarding D1.)
>
> 2. Tools
> - Provide Tools to allow easier transition between releases.
>
> 3. Testing branch.
> - What should go here?  Need clear lines in the sand.
>
> There's more, but this is already way too much for one person to handle.
> But with enough support, all of them are entirely possible.
>
> So here I have a few questions, both for the D maintainers and the community.
>
> 1. What did I miss that is requested?
> 2. What should definitely be removed?
>
> The question was raised as to why I created a project instead of a simple branch.
>
> If people want to volunteer, I can set permissions to allow them access.
> A project and a branch are not mutually exclusive.
> Druntime and Phobos depend on specific versions on D, do they not?
> So those projects would need to remain in sync as well.
>
> A project simplifies things to an extent.
> The dmd developers do not need to have any involvement at all, or it can be as tightly integrated as they wish.
>
> I can also include specific versions of LDC and GDC (and any other compiler willing to target a release.)
>
> I wanted room to expand.
> The worse that can happen is that this is completely ignored, nobody uses it, and I eventually lose interest in something that has no support from the community or the devs. (I'm not stopping for any other condition. You're stuck with me.)
>
> The best that can happen is that D Stable receives support from the D Developers and the community, allowing for many tools to be created targeting a Stable specification of the Language.
>
>
> Let's define a specification for this thing, shall we?
> First things first!
>
> How long should support of the Stable branch last?
> 1. 6 months
> 2. 12 months
> 3. longer (specify and give reasons)
>
> Now how do we organize this?
> 1.
> The current git master will be considered Unstable, and will freeze to define the next Stable.
> Are there better ideas than this?
>
> 2.
> Do we want to go with Stable, Testing, Unstable or another system?
> I'd like to see some pros and cons before making any decisions.
> I'm leaning towards the 3 stage system.
>
> Yes, this is ambitious.  So is D.  And D appears to be thriving.
> Yes, I know that I cannot even accomplish half of this alone.
> That's the point.  There was a lot of discussion, so this obviously interests many people.
> By myself, I can maintain a specific version of DMD with non-breaking bugfixes.  That is about it.
>
> Let's do this thing.

For all this to actually be possible we need branch maintainers - it is not an easy job and not many people are capable of doing it on production level. It is easy to complain and whine about problems. I haven't seen people actually offer to help here...

On Friday, 30 November 2012 at 15:08:24 UTC, Andrei Alexandrescu wrote:
> On 11/30/12 4:49 AM, 1100110 wrote:
>> Andrei's support is also necessary, IIRC he is one of main person behind
>> phobos. A stable version of D is not useful without a stable version of
>> phobos and druntime to go with it.
>
> I'm very supportive of a serious, meaningful initiative.
>
> My perception is that we're having growing pains - our process is lagging behind the participation in the project and the attention it receives. If Walter and I do not acknowledge that in time and act swiftly on it, we're heading toward a crisis in the community much, much larger and dangerous than the D1/D2 schism.
>

The thing is that I don't see that succeed as an external project.

This is like we wanted both vegetarian and non vegetarian food, and reached that goal by cooking everything all together and then some people spent their time to separate the meat from the rest.

Most likely they'll get bored rapidly as it is a lot of boring work, that is useless if the process don't mix everything in the first place.

On Friday, 30 November 2012 at 18:14:58 UTC, deadalnix wrote:
>
> The thing is that I don't see that succeed as an external project.
>

I agree that it cannot be an external project, and instead it has to become the official D process.

For example, as was discussed, and i think generally agreed on, we have to change the way the version numbering works to a major.minor.revision model  (unless someone has a better idea to propose, which I'd love to know about).

There's been mention that maintaining multiple branches will fail, and I see that someone has previously attempted to create a stable version of D that has in fact failed.

Rather than taking on a defeatist attitude, we need to look at those past failures and learn from them, so as not to repeat the same mistakes over again, and also to figure out a better solution that has a better chance for success.

There's been mention that branch maintenance will be a great deal of tedium for a maintainer, so I think that's an area that needs to be dealt with first. If it's too difficult to maintain, I agree it probably won't be maintained for very long.

We have to make it so that the path of least resistance for everyone is to follow whatever process is eventually worked out.

I also do expect to see some failures here and there, but that's normal and to be expected, we just have to be persistent until a workable solution is found.

The issue here, as stated by Andrei, which I fully agree with, is that D is fighting for its own life. We have no choice but to improve the process, otherwise D will never grow past the current point it is at and will eventually fade away into obscurity.

This is a do or die situation IMO.

--rt

On Friday, 30 November 2012 at 19:42:12 UTC, Rob T wrote:
> The issue here, as stated by Andrei, which I fully agree with, is that D is fighting for its own life. We have no choice but to improve the process, otherwise D will never grow past the current point it is at and will eventually fade away into obscurity.
>
> This is a do or die situation IMO.
>
> --rt

Sorry, that came out in an overly bleak way. The really REALLY good news, is that D has grown to the point where we are being forced to adapt to the growth. What we're hoping to achieve is a way that removes the limiters that are holding D back from further growth.

The "do or die" scenario only happens if D cannot continue to grow, and other competing languages take over, like Rust and perhaps Go. That's the only dire part to pay attention to, the optimistic point being that we are forced to grow because of D's success, not because of its failures.

--rt

On Friday, 30 November 2012 at 19:52:44 UTC, Rob T wrote:
> On Friday, 30 November 2012 at 19:42:12 UTC, Rob T wrote:
>> The issue here, as stated by Andrei, which I fully agree with, is that D is fighting for its own life. We have no choice but to improve the process, otherwise D will never grow past the current point it is at and will eventually fade away into obscurity.
>>
>> This is a do or die situation IMO.
>>
>> --rt
>
> Sorry, that came out in an overly bleak way. The really REALLY good news, is that D has grown to the point where we are being forced to adapt to the growth. What we're hoping to achieve is a way that removes the limiters that are holding D back from further growth.
>
> The "do or die" scenario only happens if D cannot continue to grow, and other competing languages take over, like Rust and perhaps Go. That's the only dire part to pay attention to, the optimistic point being that we are forced to grow because of D's success, not because of its failures.
>
> --rt

A much simpler way to state the current situation is that we're in fact experiencing a "good problem"!

--rt

On Fri, 2012-11-30 at 06:02 -0600, 1100110 wrote:
> I have just been reading that for advice and find the --no-ff
> comments
> confusing.  Can you explain that please?  I see two contradicting
> claims.
> 
> 

Well the comments say that --no-ff does not create a single commit of the merged in commits, but only create a merge commit. Which is right, but it suffices to preserve the merge information and what was merged. In a fast forward merge basically the following happens:


---*----*-----*-----*master
You branch to my_branch and do a commit

---*----*-----*-----*master
                    |----*mybranch

If you merge mybranch into master now:
---*----*-----*-----*----*master/mybranch


The information is now lost that the last commit actually came from mybranch, with --no-ff you get a merge commit, which is special because it has two parents:

git merge --no-ff mybranch:


---*----*-----*-----*---- * master
                    |    /
                    |----*mybranch

You can now list the commits that came from mybranch with the following
command:
git log master^..master^2

or simply visually print the merge graph in the log messages: git log --graph

On 11/30/2012 09:08 AM, Andrei Alexandrescu wrote:
> On 11/30/12 4:49 AM, 1100110 wrote:
>> Andrei's support is also necessary, IIRC he is one of main person behind
>> phobos. A stable version of D is not useful without a stable version of
>> phobos and druntime to go with it.
>
> I'm very supportive of a serious, meaningful initiative.
>
> My perception is that we're having growing pains - our process is
> lagging behind the participation in the project and the attention it
> receives. If Walter and I do not acknowledge that in time and act
> swiftly on it, we're heading toward a crisis in the community much, much
> larger and dangerous than the D1/D2 schism.
>
>
> Andrei

I know, I feel the same way.

On Saturday, 1 December 2012 at 03:16:36 UTC, 1100110 wrote:
> On 11/30/2012 09:08 AM, Andrei Alexandrescu wrote:
>> On 11/30/12 4:49 AM, 1100110 wrote:
>>> Andrei's support is also necessary, IIRC he is one of main person behind
>>> phobos. A stable version of D is not useful without a stable version of
>>> phobos and druntime to go with it.
>>
>> I'm very supportive of a serious, meaningful initiative.
>>
>> My perception is that we're having growing pains - our process is
>> lagging behind the participation in the project and the attention it
>> receives. If Walter and I do not acknowledge that in time and act
>> swiftly on it, we're heading toward a crisis in the community much, much
>> larger and dangerous than the D1/D2 schism.
>>
>>
>> Andrei
>
> I know, I feel the same way.

The alienation will be between those who want to see D continue to evolve, vs those who want to see D cast in stone from any further breaking changes.

Example, check out the madness being argued in this thread ...
http://forum.dlang.org/thread/sdcmmiqtlcfrfgvmwvrr@forum.dlang.org?page=1

This kind of clashing will only get worse unless something is done about it.
--rt