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 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
parent 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/

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.

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.

 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
prev sibling 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 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
next sibling 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 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.

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

 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.

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 parent 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
prev sibling 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 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 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
prev sibling parent 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
prev sibling next sibling parent 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
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 next 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 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 "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 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