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

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.

On Wed, 01 Feb 2012 20:35:53 +0100, Sean Kelly <sean at invisibleduck.org> wrote:

> 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.

Yeah I've seen that when trying to break it apart. I'd really be glad if
we could get
rid of using signals for suspending (it's causing another deadlock with
std.parallelism).

The current motivation for the core.thread pimpl is to add shared library
support,
which is rottening in my tree for almost 2 month. Fiddling that into the
API file would be a mess.

On Wed, Feb 1, 2012 at 5:35 PM, Sean Kelly <sean at invisibleduck.org> wrote:
> 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.
>

This would be nice to have so we can start the std.log review process: https://github.com/D-Programming-Language/druntime/pull/141/files

Thanks!