www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D Stable Proposal

reply 1100110 <0b1100110 gmail.com> writes:
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.
Nov 29 2012
next sibling parent reply "Rob T" <rob ucora.com> writes:
On Friday, 30 November 2012 at 04:30:10 UTC, 1100110 wrote:

 Let's do this thing.


I can help with formulating a process and I can also help write 
up the guidelines and so forth, so I'll sign up.

If we can decide on a road map and write it up, and get enough 
consensus for implementing it, then everyone will know what they 
should be working on, and also what to expect.

How many people do you think we need to get started, 5 or so?

--rt
Nov 29 2012
next sibling parent "Rob T" <rob ucora.com> writes:
On Friday, 30 November 2012 at 05:17:20 UTC, Rob T wrote:

 How many people do you think we need to get started, 5 or so?


PS: We can use ALL the help we can get, I was talking about 
forming a core group of people who are responsible for moving 
things forward and getting the work organized.

--rt
Nov 29 2012
prev sibling next sibling parent 1100110 <0b1100110 gmail.com> writes:
On 11/29/2012 11:17 PM, Rob T wrote:

 On Friday, 30 November 2012 at 04:30:10 UTC, 1100110 wrote:

 Let's do this thing.


 I can help with formulating a process and I can also help write up the
 guidelines and so forth, so I'll sign up.

 If we can decide on a road map and write it up, and get enough consensus
 for implementing it, then everyone will know what they should be working
 on, and also what to expect.

 How many people do you think we need to get started, 5 or so?

 --rt


I would hate to admit that I would consider that very optimistic...
But 5 would be more than enough to start out with.

If we get 5 now, then we will most likely achieve enough goals to truly 
stabilize everything from the end users perspective.

Once we start, and people start writing Code to target a release, then 
it's possible to do the very cool things such as automatic conversion of 
code to a new Version.  We just have to get to that point.
Nov 29 2012
prev sibling parent reply 1100110 <0b1100110 gmail.com> writes:
On 11/29/2012 11:17 PM, Rob T wrote:

 On Friday, 30 November 2012 at 04:30:10 UTC, 1100110 wrote:

 Let's do this thing.


 I can help with formulating a process and I can also help write up the
 guidelines and so forth, so I'll sign up.

 If we can decide on a road map and write it up, and get enough consensus
 for implementing it, then everyone will know what they should be working
 on, and also what to expect.

 How many people do you think we need to get started, 5 or so?

 --rt


I've started work on the specification here 
https://github.com/D-Programming-Language-Stable/dmd/wiki/Specification

I'd like for someone else to start with the writeup, since I've pretty 
much made my ideal known by this point.

If you have a github account, give me your user name and I'll add you to 
the Project.

It'll at least give us a public place to define things for right now.
Nov 29 2012
next sibling parent "Rob T" <rob ucora.com> writes:
On Friday, 30 November 2012 at 05:49:34 UTC, 1100110 wrote:

 I've started work on the specification here 
 https://github.com/D-Programming-Language-Stable/dmd/wiki/Specification

 I'd like for someone else to start with the writeup, since I've 
 pretty much made my ideal known by this point.

 If you have a github account, give me your user name and I'll 
 add you to the Project.

 It'll at least give us a public place to define things for 
 right now.


I'm pretty much done for the day, so will look this in detail 
tomorrow.

BTW, Debian has an experimental branch, any use? I don't know 
really, this is just something I'm tossing out for consideration 
before I sign out.

--rt
Nov 29 2012
prev sibling parent reply Robert <jfanatiker gmx.at> writes:
My github account is eskimor. I think the model described in:
http://nvie.com/posts/a-successful-git-branching-model/

is a really good one, to get started. If we want to keep changes to a
minimum, then the development branch in the model could simply be the
current master.

The master branch in the model would be the master branch of dmd-stable.

Feature branches already exist in form of pull requests.

Release/hotfix branches would have to be introduced. A little education
of people would be needed. (E.g. where and when to merge things,
bugs/features.) Where and how changes are documented.

I would volunteer to help writing an automatic upgrade tool. We should,
define things there, so reports of breaking changes/deprecations, the
developers provide, could then be already in a format the tool can
understand.

On Thu, 2012-11-29 at 23:49 -0600, 1100110 wrote:

 On 11/29/2012 11:17 PM, Rob T wrote:

 On Friday, 30 November 2012 at 04:30:10 UTC, 1100110 wrote:

 Let's do this thing.


 I can help with formulating a process and I can also help write up the
 guidelines and so forth, so I'll sign up.

 If we can decide on a road map and write it up, and get enough consensus
 for implementing it, then everyone will know what they should be working
 on, and also what to expect.

 How many people do you think we need to get started, 5 or so?

 --rt


 
 I've started work on the specification here 
 https://github.com/D-Programming-Language-Stable/dmd/wiki/Specification
 
 I'd like for someone else to start with the writeup, since I've pretty 
 much made my ideal known by this point.
 
 If you have a github account, give me your user name and I'll add you to 
 the Project.
 
 It'll at least give us a public place to define things for right now.
Nov 30 2012
parent reply 1100110 <0b1100110 gmail.com> writes:
On 11/30/2012 04:22 AM, Robert wrote:

 My github account is eskimor. I think the model described in:
 http://nvie.com/posts/a-successful-git-branching-model/


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.

Also you have been added as a member.


 is a really good one, to get started. If we want to keep changes to a
 minimum, then the development branch in the model could simply be the
 current master.

 The master branch in the model would be the master branch of dmd-stable.


I agree that we should be smart about this, but I'm not quite following 
you.  Please explain the best design that you have in mind.

In my mind, stable is just an abstraction over the stable branch, we 
should be working as close to the development branch as we can, to 
prevent useless duplication.


 Feature branches already exist in form of pull requests.

 Release/hotfix branches would have to be introduced. A little education
 of people would be needed. (E.g. where and when to merge things,
 bugs/features.) Where and how changes are documented.


Exactly. We develop a standard. We follow that standard.



 I would volunteer to help writing an automatic upgrade tool. We should,
 define things there, so reports of breaking changes/deprecations, the
 developers provide, could then be already in a format the tool can
 understand.


Very good!  And yes, I think that a proper automatic upgrade tool(and 
warning system!) should work with the existing systems as much as 
possible.  That would be beautiful.

You are in the "Trusted" team on the project since everything is in 
flux.  Expect to move or be moved to a team that is limited to something 
similar to a tools repo for what you want to work on.

If you want to actually get started, I'll create a Tools repo(or a 
better name?) and give you commit access.  But right now, you do not 
have commit access.
Nov 30 2012
parent Robert <jfanatiker gmx.at> writes:
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
Nov 30 2012
prev sibling next sibling parent reply 1100110 <0b1100110 gmail.com> writes:
 Take for example Gerrit + Jenkins: Every commit is first sent to Gerrit.
 Gerrit triggers Jenkins to run all unit tests over the new commit. Jenkins
 reports the result back to Gerrit. If all tests are green and another
 developer gives his "Looks good to me" (lgtm) then the commit is applied to
 the target branch.


How would this fit into the Stable model?

Assuming 3 branches, I doubt it would be prudent to run every test 
multiple times.
Ideas?
Nov 29 2012
parent reply "Rob T" <rob ucora.com> writes:
On Friday, 30 November 2012 at 06:05:51 UTC, 1100110 wrote:

 Take for example Gerrit + Jenkins: Every commit is first sent 
 to Gerrit.
 Gerrit triggers Jenkins to run all unit tests over the new 
 commit. Jenkins
 reports the result back to Gerrit. If all tests are green and 
 another
 developer gives his "Looks good to me" (lgtm) then the commit 
 is applied to
 the target branch.


 How would this fit into the Stable model?

 Assuming 3 branches, I doubt it would be prudent to run every 
 test multiple times.
 Ideas?


I'm pretty much done for the day, so will look what you wrote up 
in detail tomorrow.

One quick suggestion before I call it a day, is for there to be 
an "experimental branch" for the great minds behind D to play 
around with (eg UDA's etc). We probably don't want experimental 
stuff going directly into a branch that is destined for stable. 
Unstable should be for items that are relatively finalized in 
terms of design and agreement that the concept is to be 
eventually incorporated into stable, i.e., moving a new feature 
into unstable starts the refinement process towards a stable 
release of that feature.

We could say that individual forks are good for experimental 
work, so there's no need for an official experimental branch, 
however, that will leave out the unconnected people who may want 
to tinker with the latest and greatest ideas that are being 
worked on.

I don't know really, this is just something I'm tossing out for 
consideration. Debian has an experimental branch, and I have a 
lot of respect for what that organization has achieved, so it's 
probably there for a good reason.

--rt
Nov 29 2012
next sibling parent 1100110 <0b1100110 gmail.com> writes:
On 11/30/2012 12:31 AM, Rob T wrote:

 On Friday, 30 November 2012 at 06:05:51 UTC, 1100110 wrote:

 Take for example Gerrit + Jenkins: Every commit is first sent to Gerrit.
 Gerrit triggers Jenkins to run all unit tests over the new commit.
 Jenkins
 reports the result back to Gerrit. If all tests are green and another
 developer gives his "Looks good to me" (lgtm) then the commit is
 applied to
 the target branch.


 How would this fit into the Stable model?

 Assuming 3 branches, I doubt it would be prudent to run every test
 multiple times.
 Ideas?


 I'm pretty much done for the day, so will look what you wrote up in
 detail tomorrow.

 One quick suggestion before I call it a day, is for there to be an
 "experimental branch" for the great minds behind D to play around with
 (eg UDA's etc). We probably don't want experimental stuff going directly
 into a branch that is destined for stable. Unstable should be for items
 that are relatively finalized in terms of design and agreement that the
 concept is to be eventually incorporated into stable, i.e., moving a new
 feature into unstable starts the refinement process towards a stable
 release of that feature.

 We could say that individual forks are good for experimental work, so
 there's no need for an official experimental branch, however, that will
 leave out the unconnected people who may want to tinker with the latest
 and greatest ideas that are being worked on.

 I don't know really, this is just something I'm tossing out for
 consideration. Debian has an experimental branch, and I have a lot of
 respect for what that organization has achieved, so it's probably there
 for a good reason.

 --rt


Hmmm...  You can easily see the available branches in git, so I'm not 
quite sure if this would be a good idea..

This might be where the metaphor breaks down.
We should definitely look at Debian as a successful, widely-used stable 
system, but we shouldn't simply copy them.

I can't think of a good reason to do this right now.

Good idea though, I hadn't even considered that myself.
Nov 29 2012
prev sibling parent reply Robert <jfanatiker gmx.at> writes:
On Fri, 2012-11-30 at 07:31 +0100, Rob T wrote:

 One quick suggestion before I call it a day, is for there to be 
 an "experimental branch" for the great minds behind D to play 
 around with (eg UDA's etc). We probably don't want experimental 
 stuff going directly into a branch that is destined for stable. 
 Unstable should be for items that are relatively finalized in 
 terms of design and agreement that the concept is to be 
 eventually incorporated into stable, i.e., moving a new feature 
 into unstable starts the refinement process towards a stable 
 release of that feature. 


Totally agreed. In the development branch only already finalized things
should be merged.

Having official experimental branch(es) is a good idea.  I think the
things people are working on should be easily accessible. So other
people can contribute and test the stuff. These branches should then
also be included in dpaste.dzfl.pl. Maybe a dmd-experimental project,
where people can get access to, very easily. So they can push their
branches there. It should be as easy for people to try out experimental
things as to try out things from the development branch, to get as much
early testing as possible. Automatic creation of binary releases would
also be cool.

So the workflow could be something like: 

1. Document on a dedicated wiki page that you start working on feature X
or bug fix Y.
2. Get started on a private/semipublic feature branch.
3. As soon as you got something push it to dmd-experimental
4. Continue to work and improve things there
5. Experimental branches are considered for inclusion in devel.
6. Things are tested in an integrated way in devel, with binary releases
every two months or so. (Much like we have now)
7. At predefined intervals you branch of a release branch and stabilize
things further.
8. Release branch is merged in dmd-stable/master


Someone posted this, as why not to use feature branches:

http://www.youtube.com/watch?v=xzstASOvqNc&feature=youtu.be

I personally don't think that feature branches are the problem, but more
a lack of communication. If people work on the same stuff you get merge
conflicts, that is granted, so you should know on what people are
working before starting to work. A wiki page where you add a link to
your feature branch and what you are currently working on and
dmd-experimental could help in this regard.
Nov 30 2012
parent 1100110 <0b1100110 gmail.com> writes:
On 11/30/2012 04:40 AM, Robert wrote:

 On Fri, 2012-11-30 at 07:31 +0100, Rob T wrote:

 One quick suggestion before I call it a day, is for there to be
 an "experimental branch" for the great minds behind D to play
 around with (eg UDA's etc). We probably don't want experimental
 stuff going directly into a branch that is destined for stable.
 Unstable should be for items that are relatively finalized in
 terms of design and agreement that the concept is to be
 eventually incorporated into stable, i.e., moving a new feature
 into unstable starts the refinement process towards a stable
 release of that feature.


 Totally agreed. In the development branch only already finalized things
 should be merged.

 Having official experimental branch(es) is a good idea.  I think the
 things people are working on should be easily accessible. So other
 people can contribute and test the stuff. These branches should then
 also be included in dpaste.dzfl.pl. Maybe a dmd-experimental project,
 where people can get access to, very easily. So they can push their
 branches there. It should be as easy for people to try out experimental
 things as to try out things from the development branch, to get as much
 early testing as possible. Automatic creation of binary releases would
 also be cool.

 So the workflow could be something like:

 1. Document on a dedicated wiki page that you start working on feature X
 or bug fix Y.
 2. Get started on a private/semipublic feature branch.
 3. As soon as you got something push it to dmd-experimental
 4. Continue to work and improve things there
 5. Experimental branches are considered for inclusion in devel.


I think you would end up targeting experimental to prevent clashes with 
other stuff that has also yet to be merged.  From what I see, whatever 
you call it, upstream should remain upstream.  Maybe its a good Idea, 
but I would consider that out of our hands.

A Testing branch that new features are pulled to after inclusion in 
upstream would be nice, and allow Testing to handle it's own releases 
and have it's own guarantees.  That would enable the short term releases 
and early testing.  But I do not want to interfere with devel.


 6. Things are tested in an integrated way in devel, with binary releases
 every two months or so. (Much like we have now)
 7. At predefined intervals you branch of a release branch and stabilize
 things further.
 8. Release branch is merged in dmd-stable/master


 Someone posted this, as why not to use feature branches:

 http://www.youtube.com/watch?v=xzstASOvqNc&feature=youtu.be


Fixin to sleep, I'll watch it in the morning and respond.

 I personally don't think that feature branches are the problem, but more
 a lack of communication. If people work on the same stuff you get merge
 conflicts, that is granted, so you should know on what people are
 working before starting to work. A wiki page where you add a link to
 your feature branch and what you are currently working on and
 dmd-experimental could help in this regard.


This is a a question for Walter et al to answer.

I don't think we should define their workflow, In fact I'd prefer that 
the devel remain completely under Walter's domain.  Testing branch could 
be useful, though.
Nov 30 2012
prev sibling next sibling parent reply "dnewbie" <run3 myopera.com> writes:
Wait.. what happened to dlang-stable?
http://forum.dlang.org/thread/op.whi33qsp707hn8 invictus.skynet.com
Nov 29 2012
next sibling parent reply r_m_r <r_m_r mailinator.com> writes:
On 11/30/2012 12:24 PM, dnewbie wrote:

 Wait.. what happened to dlang-stable?
 http://forum.dlang.org/thread/op.whi33qsp707hn8 invictus.skynet.com


https://github.com/dlang-stable/dmd/commits/master shows no commits 
since July 29, 2012. I don't think any bug-fixes from upstream got 
merged into this repository (plz correct me if I'm wrong).

Regards,
r_m_r
Nov 29 2012
parent reply 1100110 <0b1100110 gmail.com> writes:
On 11/30/2012 01:07 AM, r_m_r wrote:

 On 11/30/2012 12:24 PM, dnewbie wrote:

 Wait.. what happened to dlang-stable?
 http://forum.dlang.org/thread/op.whi33qsp707hn8 invictus.skynet.com


 https://github.com/dlang-stable/dmd/commits/master shows no commits
 since July 29, 2012. I don't think any bug-fixes from upstream got
 merged into this repository (plz correct me if I'm wrong).

 Regards,
 r_m_r


Oooh, I forgot about that.

Raid it for ideas!
Nov 29 2012
parent r_m_r <r_m_r mailinator.com> writes:
On 11/30/2012 12:48 PM, 1100110 wrote:

 Raid it for ideas!


Since we're raiding for _ideas_, I guess we can have a look at the 
development process used by other languages.

Here's what the cPython mercurial repository looks like 
(http://hg.python.org/cpython/branches):

branch 		
------		
2.7 	 	
default  	
3.3 	 	
3.2 	 	
2.6 	 	
3.1 	 	
2.5 		
3.0 		
legacy-trunk 	
2.4 		
2.3 		
2.2 		
2.1 		
2.0 		

and here's the revision graph: http://hg.python.org/cpython/graph

This is what Wikipedia had to tell about Python's development process 
(http://en.wikipedia.org/wiki/Python_%28programming_language%29#Development):

--------
CPython's public releases come in three types, distinguished by which 
part of the version number is incremented:

*    **Backwards-incompatible versions**, where code is expected to 
break and must be manually ported. The first part of the version number 
is incremented. These releases happen infrequently—for example, version 
3.0 was released 8 years after 2.0.
*    **Major or "feature" releases**, which are largely compatible but 
introduce new features. The second part of the version number is 
incremented. These releases are scheduled to occur roughly every 18 
months, and each major version is supported by bugfixes for several 
years after its release.
*    **Bugfix releases**, which introduce no new features but fix bugs. 
The third and final part of the version number is incremented. These 
releases are made whenever a sufficient number of bugs have been fixed 
upstream since the last release, or roughly every 3 months. Security 
vulnerabilities are also patched in bugfix releases.

A number of alpha, beta, and release-candidates are also released as 
previews and for testing before the final release is made. Although 
there is a rough schedule for each release, this is often pushed back if 
the code is not ready. The development team monitor the state of the 
code by running the large unit test suite during development, and using 
the BuildBot _continuous integration system_.
--------

Regards,
r_m_r
Nov 30 2012
prev sibling parent 1100110 <0b1100110 gmail.com> writes:
On 11/30/2012 12:54 AM, dnewbie wrote:

 Wait.. what happened to dlang-stable?
 http://forum.dlang.org/thread/op.whi33qsp707hn8 invictus.skynet.com


No idea, looks dead.  Hasn't been updated for 4 months.

I like their idea though.  =P
Nov 29 2012
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
OK, first debian system is not suitable for a programing language 
IMO. They have to solve the exact opposite problem than ours : 
debian relies on programs, programs rely on programming languages.

Second doing that in a separate project, with people volunteering 
in it is a bad idea. This increase the workload instead of 
decreasing it. It is beneficial for D users, but not beneficial 
for D devellopers, and as it is a open source project where 
people participate on their free time, I don't think this will 
work. Anyway, I don't want to discourage you because if it does 
work, this is awesome. I'd love to be proven wrong on that one, 
so if you believe in it, go for it !

Secondly, some people were talking about roadmap, people in 
charge and everything. This is required for very important task, 
but likely to fail again on a project where people participate on 
their free time.

It would be much more beneficial to improve what occasional dev 
on D can do to help. We have to allow people to work on the stuff 
they moticate them ATM : fix a bug that occurs in their programs, 
learn some new area of programming, or whatever.

Such thing is easier to do on something stable. Currently, to 
work on D, you need to know what is the current state of thing, 
what is the intended state, why isn't it tat way (historical 
reasons, difficulties of implementations, etc . . .) and new 
feature addition tend to continue this situation (as new bugs are 
introduced hen other are removed, and real profound issue get 
harder to solve).

This is important because even if you don't use the new 
functionality, you don't get rid of the bugs. They'll manifest 
themselves because 3rd party code will use such feature.
Nov 30 2012
parent reply 1100110 <0b1100110 gmail.com> writes:
On 11/30/2012 02:22 AM, deadalnix wrote:

 OK, first debian system is not suitable for a programing language IMO.
 They have to solve the exact opposite problem than ours : debian relies
 on programs, programs rely on programming languages.

 Second doing that in a separate project, with people volunteering in it
 is a bad idea. This increase the workload instead of decreasing it. It
 is beneficial for D users, but not beneficial for D devellopers, and as
 it is a open source project where people participate on their free time,
 I don't think this will work. Anyway, I don't want to discourage you
 because if it does work, this is awesome. I'd love to be proven wrong on
 that one, so if you believe in it, go for it !

 Secondly, some people were talking about roadmap, people in charge and
 everything. This is required for very important task, but likely to fail
 again on a project where people participate on their free time.

 It would be much more beneficial to improve what occasional dev on D can
 do to help. We have to allow people to work on the stuff they moticate
 them ATM : fix a bug that occurs in their programs, learn some new area
 of programming, or whatever.

 Such thing is easier to do on something stable. Currently, to work on D,
 you need to know what is the current state of thing, what is the
 intended state, why isn't it tat way (historical reasons, difficulties
 of implementations, etc . . .) and new feature addition tend to continue
 this situation (as new bugs are introduced hen other are removed, and
 real profound issue get harder to solve).

 This is important because even if you don't use the new functionality,
 you don't get rid of the bugs. They'll manifest themselves because 3rd
 party code will use such feature.


Debian relies on third-party code.

One of the major draws of a programming language is third-party code.
The more libraries we support, and the easier we make D to target for 
stable code, the better.
Sure, there are practical differences, I'm not going to deny that.

But there are practical similarities as well. We should use the metaphor 
only as far as it works.  If you want to suggest another successful 
system currently in use, please do.  I don't want to repeat anyone 
else's mistakes.

The most important thing right now is to come up with a system that 
works, and isn't a hassle for anyone.  DMD developers should find it 
easy and useful, D users should find it easy and helpful.

I'm not going to suggest that D Stable take the Debian route of 
requiring all third-party code be forked by us for inclusion.  That's 
not what this should be about. As so a (very) large part of their system 
is currently being ignored by me.

That is a task that a D package manager should deal with.  We would just 
greatly simplify their job of making sure that the packages work where 
they say they should.  They can make their own requirements for the 
actual third-party code.

Walter's support is a key part of this.  Scheduled releases are a must, 
even if there are no new features or important changes. IMO Version bump 
releases are fine because it is expected.

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.

Equally important is third party code.  If code claims to target the 
current stable version of D, it should work as expected.(excepting Bugs 
of course, I'm not that crazy)  It should be easy to tell exactly what 
needs to be changed in order to make it work.  There should be tools 
that assist this process.

And yes, it should be as easy as possible to contribute.  One-off 
commits should be completely welcome, and encouraged.

I would love to hear advice on how to simplify that process.  Look at 
Dlang.org  You can click a button, edit the file online, and create a 
pull request.  I noticed a typo.  I was curious as to how easy it would 
be to fix. I was done approximately 2 minutes later (I dawdled on the 
commit message).  The pull was accepted a few hours later.  It was 
beautiful.

Now how can we make everything else that easy?
Nov 30 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Nov 30 2012
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Nov 30 2012
parent reply "Rob T" <rob ucora.com> writes:
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
Nov 30 2012
parent reply "Rob T" <rob ucora.com> writes:
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
Nov 30 2012
parent "Rob T" <rob ucora.com> writes:
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
Nov 30 2012
prev sibling next sibling parent reply 1100110 <0b1100110 gmail.com> writes:
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.
Nov 30 2012
parent "Rob T" <rob ucora.com> writes:
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
Dec 02 2012
prev sibling parent reply 1100110 <0b1100110 gmail.com> writes:
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


Andrei, How would you organize this?

If the process is lagging behind, what can be done to get it up-to-speed?
Dec 02 2012
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 3 December 2012 02:26, 1100110 <0b1100110 gmail.com> 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



 Andrei, How would you organize this?

 If the process is lagging behind, what can be done to get it up-to-speed?


Isn't lagging behind the point of stable? ;-)


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Dec 04 2012
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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
Nov 30 2012
prev sibling parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
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...
Nov 30 2012