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?
