On Sunday, 6 October 2013 at 09:37:18 UTC, ilya-stromberg wrote:
> Maybe we should wait at least 1-2 weeks from last review before start a new voting? Maybe we should announce upcoming voting for one week prior to start a new voting thread? I belive that it pays additional attention to the new module and helps avoid situations like this.

There were more than 1 week of time between last comment in review thread and start of voting. If you needed more time for review, you should have mentioned it. In current situation I simply have waited until Brian makes post-review changes he personally wanted and moved forward as it was pretty clear no further input is incoming.

Any formal review may potentially result in short voting after if no critical issues are found so I don't think it makes sense in making any additional announcements. There are no special points of attention - if review was declared and you want to make some input, it should be done right there.

Of course, review process is as much community-defined as anything else here. You can always define an alternative one and propose it for discussion. Right now though I am sticking to one mentioned in wiki + some of personal common sense for undefined parts (because I am lazy :)).

Also you can lend a helping hand and manage next review on your own in a way you find reasonable :P

On 10/6/13 9:57 AM, David Nadlinger wrote:
> On Saturday, 5 October 2013 at 00:24:22 UTC, Andrei Alexandrescu wrote:
>> 2. I do vote for inclusion in the /etc/ package for the time being.
>
> What is your vision for the future of etc.*, assuming that we are also
> going to promote DUB (or another package manager) to "official" status
> soon as well?

I think /etc/ should be a stepping stone to std, just like in C++ boost is for std (and boost's sandbox is for boost).

Andrei

On 10/6/13 10:10 AM, David Nadlinger wrote:
> On Sunday, 6 October 2013 at 17:08:25 UTC, Joseph Rushton Wakeling wrote:
>> isn't this really what has just been discussed under the proposed name
>> of stdx?
>>
>> ... and if so, why isn't it being used?
>
> This is exactly why I'm not too thrilled to make another attempt at
> establishing something like that. ;)

We could improve things on our end by featuring etc documentation more prominently etc. I don't think there's a need to reboot things with stdx. Just improve etc.

Andrei

On 10/6/13 1:41 PM, Andrei Alexandrescu wrote:
> On 10/6/13 10:10 AM, David Nadlinger wrote:
>> On Sunday, 6 October 2013 at 17:08:25 UTC, Joseph Rushton Wakeling wrote:
>>> isn't this really what has just been discussed under the proposed name
>>> of stdx?
>>>
>>> ... and if so, why isn't it being used?
>>
>> This is exactly why I'm not too thrilled to make another attempt at
>> establishing something like that. ;)
>
> We could improve things on our end by featuring etc documentation more prominently etc. I don't
> think there's a need to reboot things with stdx. Just improve etc.
>
> Andrei

I'm largely staying out of this conversation, but there's one area that I think is pretty important, speed of development.

By having a less official, more readily committable to, repository it stands to reason that it'll evolve faster and fluidly than the phobos code base docs or should.  Some of it is just that phobos pull requests lanquish too long, but that's not ALL it is.  The bar should be different, not that phobos' bar should be lower.

My 2 cents,
Brad

On 2013-10-06 22:40, Andrei Alexandrescu wrote:

> I think /etc/ should be a stepping stone to std, just like in C++ boost
> is for std (and boost's sandbox is for boost).

Currently "etc" seems like where C bindings are placed.

-- 
/Jacob Carlborg

On Monday, October 07, 2013 08:36:16 Jacob Carlborg wrote:
> On 2013-10-06 22:40, Andrei Alexandrescu wrote:
> > I think /etc/ should be a stepping stone to std, just like in C++ boost is for std (and boost's sandbox is for boost).
> 
> Currently "etc" seems like where C bindings are placed.

That's what I thought that it was for. I don't remember etc ever really being discussed before, and all it has are C bindings, so the idea that it would hold anything other than C bindings is news to me, though I think that we should probably shy away from putting C bindings in Phobos in general.

- Jonathan M Davi

On Sunday, 6 October 2013 at 20:40:50 UTC, Andrei Alexandrescu wrote:
> On 10/6/13 9:57 AM, David Nadlinger wrote:
>> On Saturday, 5 October 2013 at 00:24:22 UTC, Andrei Alexandrescu wrote:
>>> 2. I do vote for inclusion in the /etc/ package for the time being.
>>
>> What is your vision for the future of etc.*, assuming that we are also
>> going to promote DUB (or another package manager) to "official" status
>> soon as well?
>
> I think /etc/ should be a stepping stone to std, just like in C++ boost is for std (and boost's sandbox is for boost).
>
> Andrei

Please consider the stdx proposal instead. etc was always used for C bindings...

On Sunday, 6 October 2013 at 21:32:25 UTC, Brad Roberts wrote:
> On 10/6/13 1:41 PM, Andrei Alexandrescu wrote:
>> On 10/6/13 10:10 AM, David Nadlinger wrote:
>>> On Sunday, 6 October 2013 at 17:08:25 UTC, Joseph Rushton Wakeling wrote:
>>>> isn't this really what has just been discussed under the proposed name
>>>> of stdx?
>>>>
>>>> ... and if so, why isn't it being used?
>>>
>>> This is exactly why I'm not too thrilled to make another attempt at
>>> establishing something like that. ;)
>>
>> We could improve things on our end by featuring etc documentation more prominently etc. I don't
>> think there's a need to reboot things with stdx. Just improve etc.
>>
>> Andrei
>
> I'm largely staying out of this conversation, but there's one area that I think is pretty important, speed of development.
>
> By having a less official, more readily committable to, repository it stands to reason that it'll evolve faster and fluidly than the phobos code base docs or should.  Some of it is just that phobos pull requests lanquish too long, but that's not ALL it is.  The bar should be different, not that phobos' bar should be lower.
>
> My 2 cents,
> Brad

This.

The very point of such category is to provide more flexible and still officially approved source for not-yet-there modules. Whatever the reason is that prevents it from straightforward inclusion, it is likely to be reason for plenty of commits to the module. Limiting its polishing to Phobos release model hinders core rationale for having such semi-official module list - ability of module author to polish it in his own tempo using more extensive field test results.

I actually kind of think "etc." should be deprecated and eventually removed from Phobos at all. For C bindings we now have Deimos, for experimental packages it simply does not work that good.

On Sunday, 6 October 2013 at 18:54:55 UTC, Dicebot wrote:
> Any formal review may potentially result in short voting after if no critical issues are found so I don't think it makes sense in making any additional announcements. There are no special points of attention - if review was declared and you want to make some input, it should be done right there.

Yes, but people are lazy. I don't talk about all of us, but most of people are lazy.
Somebody of us will vote because it's interesting, but will not read/write review tread because it requests a time.
So, additional announce of upcoming voting can help: "Guys, if you want to vote, it's time to read documentation and write your really cool idea before voting".

On Monday, 7 October 2013 at 13:29:30 UTC, ilya-stromberg wrote:
> On Sunday, 6 October 2013 at 18:54:55 UTC, Dicebot wrote:
>> Any formal review may potentially result in short voting after if no critical issues are found so I don't think it makes sense in making any additional announcements. There are no special points of attention - if review was declared and you want to make some input, it should be done right there.
>
> Yes, but people are lazy. I don't talk about all of us, but most of people are lazy.
> Somebody of us will vote because it's interesting, but will not read/write review tread because it requests a time.
> So, additional announce of upcoming voting can help: "Guys, if you want to vote, it's time to read documentation and write your really cool idea before voting".

This is the reason I've not cast any votes for standard modules - I haven't had the time, or don't have the competence, to cast a valid vote. It would be like voting for a political party without knowing where all parties stands in all cases.