persistent byLine

[Brad Anderson]

On Thursday, 25 July 2013 at 01:57:45 UTC, H. S. Teoh wrote:
> On Wed, Jul 24, 2013 at 08:17:08PM -0400, Jonathan M Davis 
> wrote:
>> On Wednesday, July 24, 2013 17:45:53 Nick Treleaven wrote:
>> > Also is there any info on std.io? I assume it's still 
>> > worthwhile to
>> > update std.stdio docs and fix issues?
>> 
>> It is unknown when std.io will be ready for review, and the 
>> person
>> working on it is quite busy. We certainly want to continue to 
>> fix
>> issues in std.stdio.  What is more questionable is adding a 
>> lot of
>> functionality to it. But bug fixes and the like should be 
>> fine, and
>> I'm sure that some new functionality would be fine as well. We
>> definitely don't want to make major changes to it though, 
>> since we intend to replace it.
> [...]
>
> This makes me wonder if we should adopt a convention of using a 
> public
> fork/branch on GitHub when working on a new feature. That way, 
> if the
> person who started it can't work on it for whatever reason (too 
> busy
> IRL, working on other things, etc.), somebody else can step up 
> and
> continue the work, instead of the work being stalled without any
> definite target completion time.
>
> With GitHub, something like this is not only practical, but 
> probably
> also beneficial. For example, recently, I started working on a 
> D port of
> gdc's gdmd wrapper. After I got the initial functionality 
> working, I got
> busy with other stuff, but thanks to the code being available 
> on github,
> somebody else could step in and contribute pull requests. So 
> development
> continues in spite of me being unable to work on it at the 
> moment.  And
> sometimes, receiving pull requests on your branch is a big 
> motivation
> for you to get cracking on the code again. :)
>
> For something as crucial as std.io (or other key Phobos 
> components, in
> general), I think this kind of approach is probably necessary. 
> It
> doesn't help our public image at all if people take a look at 
> our
> situation and say, "what's up with these D people, why is there 
> only one
> person working on key feature X and no progress is made because 
> that
> person is too busy". To improve our professionalism, this 
> situation
> ought to be improved.
>
> Not to mention, like this also helps improve our bus factor 
> when it
> comes to key pieces of new functionality.
>
>
> T

https://github.com/schveiguy/phobos/blob/new-io/std/io.d

(which I amusingly found the URL of by Googling "std.io github 
site:dlang.org" and found a reply I made to you [1] with this URL 
back in February).

I wonder if Steve could be convinced to write up a TODO for 
std.io of where he left off.

1. 
http://forum.dlang.org/post/sbmntkiwhnmpcrfypvpw@forum.dlang.org