Formal Review Process

Steven Schveighoffer schveiguy at yahoo.com
Mon Jun 10 19:46:03 PDT 2013


On Mon, 10 Jun 2013 22:04:46 -0400, Jesse Phillips  
<Jesse.K.Phillips+D at gmail.com> wrote:

> On Tuesday, 11 June 2013 at 00:47:56 UTC, Jonathan M Davis wrote:
>> I thought that it was clear that anything being submitted for review  
>> for inclusion in Phobos actually had to be in a state where a pull  
>> request for Phobos could be created for it.
>
> There was no defining conclusion that I recall. There certainly were  
> such opinions expressed, but as we don't have any review process for  
> processes I don't see how a claim to clarity can exist for such matters.
>
> I have provided my reason, the community is not providing the help  
> contributers need during RFC.

While I don't pretend to have been active at reviewing submissions, I have  
to agree with Jonathan.

Any code ready for review must have a clear indication of how the API will  
look when it's pulled into Phobos.  If it's not to that state, the code  
cannot really be reviewed as a possible contribution to Phobos.

I understand that there is some apprehension from Jacob on whether it's  
worth the effort of porting the code to be "phobos ready", but I can't see  
how anyone can possibly review the code based on the "merits" of the  
code.  The API is the most important part for code reviews!  We can fix  
implementation details later.

I have been in that position also, and it's not a fun place to be.

>> We certainly can't possibly vote it in if it's
>> not in such a state, because we wouldn't even know what it would look  
>> like when it was merged in.
>>
>> - Jonathan M Davis
>
> Sure you can, if the modifications are simple to understand then it is  
> clear what it will be like in the long run. For those who feel the  
> unknowns are too great, "No" is an appropriate vote. On the more  
> important side, during review many times the issues are resolved prior  
> to voting.

"Just imagine what the API would be like if it was in Phobos" isn't good  
enough.  Especially for this library, it looks like there are quite a few  
modules.  Where do those go?  What changes are made?  Standing out right  
away is

We need an API document of what it would be in Phobos, and how the API  
works.

I would recommend suspending this review, putting together a strawman API  
of how you think it will look under phobos, post that as an RFC, and then  
judge whether it's worth porting from that response.  If there's only a  
subset of the API we should be looking at that, show me that subset.

We simply cannot have a formal review on software that isn't ready for  
inclusion - by definition we would have to have another review later when  
it's ready for inclusion.

-Steve


More information about the Digitalmars-d mailing list