www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Should we try and make some sort of schedule or todo-list for the

reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
The 2.063 release got me thinking, all of those features that were
implemented and mentioned in the changelog were basically features
which contributors picked to contribute to at a random point in time.

While Phobos has a proposal/review/voting process for new modules,
other features or changes are largely unpredictable.

So I was thinking, how about we create a table of big tasks on dwiki
for upcoming releases (meaning they could apply to 2.064 or any future
version), categorize them according to difficulty, and then pick and
order them in a separate table for the 2.064 release, leaving any
unpicked ones for a future release.

We could also have a column where people can put their names in so we
know if and who is working on implementing a feature.

Another thing we might recommend doing is to create a page for each
task where the person(s) currently in charge of implementing a feature
can document their implementation process (for features that are hard
to implement), and provide links to their branches where their work is
stored.

At least that way if someone stops working on a feature, someone else
can take over without having to wonder what the state of things are.

Some big features that come to mind, just off the top of my head (and
these are language-oriented):

- Fixing property rewrites: "prop +=3D 1" =3D=3D "prop(prop + 1)", this
should be doable without interfering with any other property DIPs

- Fixing associative arrays (H.S. Teoh has worked on this already, but
that work got stalled for almost a year)

- Implementing DIP 37 - "Importing Packages as if They Were Modules"

- rvalue references

-----

Now, the current way we work isn't bad at all. We're constantly
increasing our contributons throughput with each release. But I think
if we had a nice and maintained task list we could encourage both
newcomers and existing contributors to contribute more code
(newcommers could pick a task off the "easy" list of bugs or
features).

Having a task list also has a psychological impact on existing
contributors (I'm just taking the example of my view of it on myself
here). For example, if I want to fix some compiler bug, what I usually
do is read the list of current bugs[1] and then almost completely
randomly(!) pick one bug, try fixing it for a few minutes, and if it's
too hard to fix I usually give up and try the next one because the
list of bugs is long and there's plenty to chose from.

But if it was a bug that was on a task list for an upcoming release
(and the reason it would be there is because the community decided
it's important enough), then I'd definitely have more incentive to fix
such a bug, and there would be a greater feeling of achievement when
the bug is fixed, much more than when a randomly picked bug is fixed.

-----

Anyway, either process is currently fine. But I'd like us to work more
as a team, rather than as a disconnected group of individuals that
"aims and shoots". You could label this as the next "evolutionary
step", if you will.

One thing's for sure, D is currently growing at an unprecedented rate.
Just a few years back the future of D didn't look so bright, what with
all the broken features, bugs, and poor documentation, not to mention
the lack of books and tutorials. But things have changed, and now we
have a constantly growing number of contributions and contributors.
Pretty awesome, I'd say.

[1] : http://d.puremagic.com/issues/buglist.cgi?bug_status=3DUNCONFIRMED&bu=
g_status=3DNEW&bug_status=3DASSIGNED&bug_status=3DREOPENED&bug_status=3DVER=
IFIED&component=3Dcoffimplib&component=3DDMD&component=3Ddruntime&component=
=3Ddstress&component=3Dgeneral&component=3Dglue%20layer&component=3Dhtod&co=
mponent=3Dinstaller&component=3Dmake&component=3Dobj2asm&component=3DOptlin=
k&component=3DPhobos&component=3DTestComponent&component=3Dwebsites&product=
=3DD&product=3DDGCC%20aka%20GDC&product=3DDStress&product=3Dpuremagic.com&p=
roduct=3DTestProduct&query_format=3Dadvanced&version=3D2.000&version=3D2.00=
1&version=3D2.002&version=3D2.003&version=3D2.004&version=3D2.005&version=
=3D2.006&version=3D2.007&version=3D2.008&version=3D2.009&version=3D2.010&ve=
rsion=3D2.011&version=3D2.012&version=3D2.013&version=3D2.014&version=3D2.0=
15&version=3D2.016&version=3D2.017&version=3D2.018&version=3D2.019&version=
=3D2.020&version=3D2.021&version=3D2.022&version=3D2.023&version=3D2.024&ve=
rsion=3D2.025&version=3D2.026&version=3D2.027&version=3D2.028&version=3D2.0=
29&version=3D2.030&version=3D2.031&version=3D2.032&version=3Dfuture&version=
=3D2.033&version=3D2.034&version=3D2.035&version=3D2.036&version=3D2.037&ve=
rsion=3D2.038&version=3D2.039&version=3D2.040&version=3D2.041&version=3DD2&=
version=3DD1%20%26%20D2&order=3Dbug_id%20DESC&query_based_on=3D
May 31 2013
parent "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
Another thought for a task: the build scripts. The manual labour 
needed to build and install DMD, druntime and Phobos is 
frustrating. Ideally it'd be nice to have a solution like LDC, 
where druntime and Phobos are git submodules and they get built 
and installed via one simple script (for LDC you just need to 
call cmake to configure and then make && make install).
May 31 2013