D Stable Proposal

[1100110]

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?