[D-runtime] Speeding up integration

Sean Kelly sean at invisibleduck.org
Wed Feb 1 11:35:53 PST 2012


On Jan 29, 2012, at 11:52 AM, Martin Nowak wrote:

> Sean, what can we do to help you keeping up with the amount of pull requests?

Find me some free time :-/  To be more constructive though, it's worth noting that I'm a more particular about changes code I originally authored, largely because I want to continue to be able to know how it works without much inspection, and maintain it easily.  Also, I'm very careful with any changes to core.thread, because the implementation has a lot of non-obvious requirements that tend to result in race conditions when violated.  With my limited time, anything that I feel needs an extensive review isn't likely to be handled in a timely manner unless it's a top priority.

In general I think the most important thing is just to model the existing approach of the current or similar modules as closely as possible.  For core.sys.posix, I start with the spec here http://pubs.opengroup.org/onlinepubs/009695399/ and build the file out in comments based on the docs, then search for the definitions on each platform and fill out any section I define completely, though I tend to only fill out the ones that are actually needed at the time.  This is mostly for my own sanity.  It's a system I've found that works for me, and makes it easy for me to maintain the modules.  Beyond that, simply make sure that the pull tester proves that the change works everywhere.  And if it's a structural change, make a strong case for it.

Personally, I'm going to try and set aside regular time for reviewing pull requests.  And more importantly, when I have an issue with a pull request I'm going to say as much in a comment instead of putting it off for later.  Regardless of how busy I am, I know I could use the time I have for D more productively, so hopefully that will help too.


More information about the D-runtime mailing list