View mode: basic / threaded / horizontal-split · Log in · Help
November 30, 2012
Re: D Stable Proposal
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
November 30, 2012
Re: D Stable Proposal
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
November 30, 2012
Re: D Stable Proposal
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!
November 30, 2012
Re: D Stable Proposal
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.
November 30, 2012
Re: D Stable Proposal
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?
November 30, 2012
Re: D Stable Proposal
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.
November 30, 2012
Re: D Stable Proposal
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
November 30, 2012
Re: D Stable Proposal
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.
November 30, 2012
Re: D Stable Proposal
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.
November 30, 2012
Re: D Stable Proposal
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.
1 2 3 4
Top | Discussion index | About this forum | D home