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

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

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!

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.

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?

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.

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

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.

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.

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.