digitalmars.D - Should we try and make some sort of schedule or todo-list for the
- Andrej Mitrovic <andrej.mitrovich gmail.com> May 31 2013
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 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.  : 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
"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