• dsimcha (34/34) Mar 27 2011 From observing the review processes for std.parallelism and
• Jonathan M Davis (12/51) Mar 27 2011 Overall, your suggestions are good. Personally, my problem with reviews ...
• Walter Bright (9/38) Mar 28 2011 I know that reviews can be frustratingly slow. It's mainly because we ha...
• dsimcha (12/15) Mar 28 2011 Please clarify "release". If you mean making the code and documentation...
• Walter Bright (5/20) Mar 28 2011 I have thought in the past about putting such modules into another packa...
• bearophile (5/9) Mar 28 2011 It's a nice idea. Possible names: "std.experimental", "std.unstable" or ...
• Graham Fawcett (11/24) Mar 28 2011 Personally I like the experimental/incubator idea (though it had better
• bearophile (4/7) Mar 28 2011 But the end result is the same: if they find troubles in a feature prese...
• KennyTM~ (9/16) Mar 28 2011 I disagree.
• bearophile (5/13) Mar 28 2011 You are right, there are important differences.
• spir (8/14) Mar 28 2011 std.experimental is better than std.foo, because 'foo' is far too useful...
• Jonas Drewsen (7/40) Mar 28 2011 Please do! I would love to put in the libcurl wrapper in for early
• spir (7/46) Mar 28 2011 This idea seems to find large support very fast...
• Bruno Medeiros (10/43) Apr 01 2011 Hum, this seems like an very interesting idea, it should definitely be
• spir (8/23) Mar 28 2011 Anyway,n this is far better than premature adoption (mainly because late...

dsimcha <dsimcha yahoo.com> writes:

 From observing the review processes for std.parallelism and 
std.net.isemail, I think our review process needs some tweaking.  There 
are two key issues:

1.  The pace of reviews is glacial unless there's a vote date near. 
Only 4 people have reviewed std.net.isemail, and that's counting any 
participation in the discussion as "review".  This module doesn't have a 
vote date yet.  IIRC only two people reviewed std.parallelism during its 
first two weeks of review.  Furthermore, it took some time after I 
requested review for the "official" review period to start.  As a 
solution all requests for review should come with a tentative vote date 
to prevent the module from being held in limbo indefinitely and move the 
review queue along.

2.  Reviews that prompt major changes right before the vote date are 
stressful.  A looming deadline is not conducive to careful discussion 
and consideration of suggestions, especially those that are non-trivial 
to understand and/or implement.

I propose that all review periods last one week for small modules or two 
weeks for large modules, subject to extension if the review process is 
still yielding good discussion near the vote date or "stashing" if the 
author needs time to discuss specific issues that were raised and/or 
design and implement changes.  When a module is stashed, it is no longer 
officially in review and the next item in the review queue, if any, can 
begin the process.  As soon as this item is done, review of the stashed 
item is resumed.  Right now, std.parallelism is stashed until 
std.net.isemail is finished.

To prevent the community from being overwhelmed, multiple reviews may 
not take place concurrently but a review may take place concurrently 
with a vote.  Contention for the review queue is an issue in theory, but 
that's a problem we'd like to have and can work out on an ad-hoc basis 
should it arise.

More specifically, the pace of reviews for std.net.isemail has been 
glacial.  If everyone who intends to review it has done so, we should 
move on to a vote.  If anyone intends to review this module but hasn't 
yet, please do so or at least state your intention to do so.

Jonathan M Davis <jmdavisProg gmx.com> writes:

On 2011-03-27 20:53, dsimcha wrote:
  From observing the review processes for std.parallelism and
 std.net.isemail, I think our review process needs some tweaking.  There
 are two key issues:
 
 1.  The pace of reviews is glacial unless there's a vote date near.
 Only 4 people have reviewed std.net.isemail, and that's counting any
 participation in the discussion as "review".  This module doesn't have a
 vote date yet.  IIRC only two people reviewed std.parallelism during its
 first two weeks of review.  Furthermore, it took some time after I
 requested review for the "official" review period to start.  As a
 solution all requests for review should come with a tentative vote date
 to prevent the module from being held in limbo indefinitely and move the
 review queue along.
 
 2.  Reviews that prompt major changes right before the vote date are
 stressful.  A looming deadline is not conducive to careful discussion
 and consideration of suggestions, especially those that are non-trivial
 to understand and/or implement.
 
 I propose that all review periods last one week for small modules or two
 weeks for large modules, subject to extension if the review process is
 still yielding good discussion near the vote date or "stashing" if the
 author needs time to discuss specific issues that were raised and/or
 design and implement changes.  When a module is stashed, it is no longer
 officially in review and the next item in the review queue, if any, can
 begin the process.  As soon as this item is done, review of the stashed
 item is resumed.  Right now, std.parallelism is stashed until
 std.net.isemail is finished.
 
 To prevent the community from being overwhelmed, multiple reviews may
 not take place concurrently but a review may take place concurrently
 with a vote.  Contention for the review queue is an issue in theory, but
 that's a problem we'd like to have and can work out on an ad-hoc basis
 should it arise.
 
 More specifically, the pace of reviews for std.net.isemail has been
 glacial.  If everyone who intends to review it has done so, we should
 move on to a vote.  If anyone intends to review this module but hasn't
 yet, please do so or at least state your intention to do so.

Overall, your suggestions are good. Personally, my problem with reviews is 
that I have enough going on and they take enough time and concentration to do 
that I end up setting them aside to do later and then have trouble getting 
around to them. I've been intending to look at both std.parallelism and 
std.net.isemail (Am I the only one who thinks Ishmael when I see that? LOL), 
but I've been busy. Shorter review periods are both good and bad, because they 
force you to take the time to review them rather than putting it off, thereby 
actually encouraging reviews, but if they're too short, some folks will miss 
them entirely or not have the time to come up with solid feedback.

Overall, I think that what you're suggesting is solid.

- Jonathan M Davis

Walter Bright <newshound2 digitalmars.com> writes:

On 3/27/2011 8:53 PM, dsimcha wrote:
  From observing the review processes for std.parallelism and std.net.isemail, I
 think our review process needs some tweaking. There are two key issues:

 1. The pace of reviews is glacial unless there's a vote date near. Only 4
people
 have reviewed std.net.isemail, and that's counting any participation in the
 discussion as "review". This module doesn't have a vote date yet. IIRC only two
 people reviewed std.parallelism during its first two weeks of review.
 Furthermore, it took some time after I requested review for the "official"
 review period to start. As a solution all requests for review should come with
a
 tentative vote date to prevent the module from being held in limbo indefinitely
 and move the review queue along.

I know that reviews can be frustratingly slow. It's mainly because we have a 
smallish community.


 2. Reviews that prompt major changes right before the vote date are stressful.
A
 looming deadline is not conducive to careful discussion and consideration of
 suggestions, especially those that are non-trivial to understand and/or
implement.

 I propose that all review periods last one week for small modules or two weeks
 for large modules, subject to extension if the review process is still yielding
 good discussion near the vote date or "stashing" if the author needs time to
 discuss specific issues that were raised and/or design and implement changes.
 When a module is stashed, it is no longer officially in review and the next
item
 in the review queue, if any, can begin the process. As soon as this item is
 done, review of the stashed item is resumed. Right now, std.parallelism is
 stashed until std.net.isemail is finished.

 To prevent the community from being overwhelmed, multiple reviews may not take
 place concurrently but a review may take place concurrently with a vote.
 Contention for the review queue is an issue in theory, but that's a problem
we'd
 like to have and can work out on an ad-hoc basis should it arise.

 More specifically, the pace of reviews for std.net.isemail has been glacial. If
 everyone who intends to review it has done so, we should move on to a vote. If
 anyone intends to review this module but hasn't yet, please do so or at least
 state your intention to do so.

Different people have interests in different things. I don't think a person 
interested in std.parallelism would necessarily have any interest in 
std.net.isemail, and vice versa, so those can be done in parallel (!).

A further issue with the review process is that the bulk of people won't look
at 
something until it is actually released. I think the only way to deal with this 
is to be willing to correct deficiencies found after release.

dsimcha <dsimcha yahoo.com> writes:

== Quote from Walter Bright (newshound2 digitalmars.com)'s article
 A further issue with the review process is that the bulk of people won't look
at
 something until it is actually released. I think the only way to deal with this
 is to be willing to correct deficiencies found after release.

Please clarify "release".  If you mean making the code and documentation public
and conveniently accessible, that's the point of the review process.  If you
mean
actually including it with the DMD distribution, then maybe we need an
"incubator"
package as others have suggested.  Things would get in incubator after
abbreviated
review.  While in incubator we'd make no guarantees about their stability or
even
their continued inclusion.  The "real" review would take place over a release
cycle or two, while the module was in incubator.  After each release cycle, we'd
make a three-way decision.  A module can:

1.  Be declared stable and promoted to std.

2.  Be declared not worthwhile and removed.

3.  Kept in incubator pending further review and improvements.

Walter Bright <newshound2 digitalmars.com> writes:

On 3/28/2011 12:18 PM, dsimcha wrote:
 == Quote from Walter Bright (newshound2 digitalmars.com)'s article
 A further issue with the review process is that the bulk of people won't look
at
 something until it is actually released. I think the only way to deal with this
 is to be willing to correct deficiencies found after release.

 Please clarify "release".  If you mean making the code and documentation public
 and conveniently accessible, that's the point of the review process.  If you
mean
 actually including it with the DMD distribution, then maybe we need an
"incubator"
 package as others have suggested.  Things would get in incubator after
abbreviated
 review.  While in incubator we'd make no guarantees about their stability or
even
 their continued inclusion.  The "real" review would take place over a release
 cycle or two, while the module was in incubator.  After each release cycle,
we'd
 make a three-way decision.  A module can:

 1.  Be declared stable and promoted to std.

 2.  Be declared not worthwhile and removed.

 3.  Kept in incubator pending further review and improvements.

I have thought in the past about putting such modules into another package,
call 
it "foo" for lack of a better name, and put it in the dmd distribution. If the 
package pans out in real life, then move it to std. So, yes, I think your idea 
is a good one.

bearophile <bearophileHUGS lycos.com> writes:

Walter:

 I have thought in the past about putting such modules into another package,
call 
 it "foo" for lack of a better name, and put it in the dmd distribution. If the 
 package pans out in real life, then move it to std. So, yes, I think your idea 
 is a good one.

It's a nice idea. Possible names: "std.experimental", "std.unstable" or
"std.minefield" :-)

In Python there is kind of built-in namespace named "future" that you import as
module, it contains even new basic language features in testing (like integer
division!). I'd like the same in D2 too, for experimental features.

Bye,
bearophile

Graham Fawcett <fawcett uwindsor.ca> writes:

On Mon, 28 Mar 2011 15:32:44 -0400, bearophile wrote:

 Walter:
 
 I have thought in the past about putting such modules into another
 package, call it "foo" for lack of a better name, and put it in the dmd
 distribution. If the package pans out in real life, then move it to
 std. So, yes, I think your idea is a good one.

 
 It's a nice idea. Possible names: "std.experimental", "std.unstable" or
 "std.minefield" :-)

Personally I like the experimental/incubator idea (though it had better 
not get a 'std' prefix!). I'm not sure the D community is large enough to 
support a more formal review process (yet).

 In Python there is kind of built-in namespace named "future" that you
 import as module, it contains even new basic language features in
 testing (like integer division!). I'd like the same in D2 too, for
 experimental features.

I don't see the connection. '__future__' in Python isn't for experimental 
features, nor is it for introducing stdlib changes. It's a way to 'import' 
language features which become standard in later releases.

For example, as you know, the 'print' statement becomes a function in 
Python 3.0, but you can disable the print statement in Python 2.6+ via 
'from __future__ import print_function'.

Graham

bearophile <bearophileHUGS lycos.com> writes:

Graham Fawcett:

 I don't see the connection. '__future__' in Python isn't for experimental 
 features, nor is it for introducing stdlib changes. It's a way to 'import' 
 language features which become standard in later releases.

But the end result is the same: if they find troubles in a feature present just
in __future__, then I am sure they fix them before the feature becomes standard.

Bye,
bearophile

KennyTM~ <kennytm gmail.com> writes:

On Mar 29, 11 04:04, bearophile wrote:
 Graham Fawcett:

 I don't see the connection. '__future__' in Python isn't for experimental
 features, nor is it for introducing stdlib changes. It's a way to 'import'
 language features which become standard in later releases.

 But the end result is the same: if they find troubles in a feature present
just in __future__, then I am sure they fix them before the feature becomes
standard.

 Bye,
 bearophile

I disagree.

Python's future statement provides features that will certainly be 
enabled. It's a feature to provide smoother code compatibility with 
earlier versions. Every decision is pretty much settled when it is 
available in __future__, and the only step left is to enable it by default.

This is not the case for incubator/foo/experimental. There is no 
guarantee that the module must be voted in, nor the interface will be 
the same when transitioning to std.

bearophile <bearophileHUGS lycos.com> writes:

KennyTM~:

 Python's future statement provides features that will certainly be 
 enabled. It's a feature to provide smoother code compatibility with 
 earlier versions. Every decision is pretty much settled when it is 
 available in __future__, and the only step left is to enable it by default.
 
 This is not the case for incubator/foo/experimental. There is no 
 guarantee that the module must be voted in, nor the interface will be 
 the same when transitioning to std.

You are right, there are important differences.

Beside a Phobos module like std.experimental, I'd like a way to activate
experimental features in D too. There is a similar feature in Haskell too, and
it's used a lot.

Bye,
bearophile

spir <denis.spir gmail.com> writes:

On 03/28/2011 09:32 PM, bearophile wrote:
 Walter:

 I have thought in the past about putting such modules into another package,
call
 it "foo" for lack of a better name, and put it in the dmd distribution. If the
 package pans out in real life, then move it to std. So, yes, I think your idea
 is a good one.

 It's a nice idea. Possible names: "std.experimental", "std.unstable" or
"std.minefield" :-)

std.experimental is better than std.foo, because 'foo' is far too useful as 
variable name ;-)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

Jonas Drewsen <jdrewsen nospam.com> writes:

On 28/03/11 21.19, Walter Bright wrote:
 On 3/28/2011 12:18 PM, dsimcha wrote:
 == Quote from Walter Bright (newshound2 digitalmars.com)'s article
 A further issue with the review process is that the bulk of people
 won't look at
 something until it is actually released. I think the only way to deal
 with this
 is to be willing to correct deficiencies found after release.

 Please clarify "release". If you mean making the code and
 documentation public
 and conveniently accessible, that's the point of the review process.
 If you mean
 actually including it with the DMD distribution, then maybe we need an
 "incubator"
 package as others have suggested. Things would get in incubator after
 abbreviated
 review. While in incubator we'd make no guarantees about their
 stability or even
 their continued inclusion. The "real" review would take place over a
 release
 cycle or two, while the module was in incubator. After each release
 cycle, we'd
 make a three-way decision. A module can:

 1. Be declared stable and promoted to std.

 2. Be declared not worthwhile and removed.

 3. Kept in incubator pending further review and improvements.

 I have thought in the past about putting such modules into another
 package, call it "foo" for lack of a better name, and put it in the dmd
 distribution. If the package pans out in real life, then move it to std.
 So, yes, I think your idea is a good one.

Please do! I would love to put in the libcurl wrapper in for early 
feedback. Libcurl supports many other protocols that just HTTP, and it 
would be very nice to try out the wrapper design initially by 
implementing HTTP only support. Based on the feedback of that the rest 
of the protocols could be implemented.

/Jonas

spir <denis.spir gmail.com> writes:

On 03/28/2011 10:32 PM, Jonas Drewsen wrote:
 On 28/03/11 21.19, Walter Bright wrote:
 On 3/28/2011 12:18 PM, dsimcha wrote:
 == Quote from Walter Bright (newshound2 digitalmars.com)'s article
 A further issue with the review process is that the bulk of people
 won't look at
 something until it is actually released. I think the only way to deal
 with this
 is to be willing to correct deficiencies found after release.

 Please clarify "release". If you mean making the code and
 documentation public
 and conveniently accessible, that's the point of the review process.
 If you mean
 actually including it with the DMD distribution, then maybe we need an
 "incubator"
 package as others have suggested. Things would get in incubator after
 abbreviated
 review. While in incubator we'd make no guarantees about their
 stability or even
 their continued inclusion. The "real" review would take place over a
 release
 cycle or two, while the module was in incubator. After each release
 cycle, we'd
 make a three-way decision. A module can:

 1. Be declared stable and promoted to std.

 2. Be declared not worthwhile and removed.

 3. Kept in incubator pending further review and improvements.

 I have thought in the past about putting such modules into another
 package, call it "foo" for lack of a better name, and put it in the dmd
 distribution. If the package pans out in real life, then move it to std.
 So, yes, I think your idea is a good one.

 Please do! I would love to put in the libcurl wrapper in for early feedback.
 Libcurl supports many other protocols that just HTTP, and it would be very nice
 to try out the wrapper design initially by implementing HTTP only support.
 Based on the feedback of that the rest of the protocols could be implemented.

This idea seems to find large support very fast...

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:

On 28/03/2011 20:19, Walter Bright wrote:
 On 3/28/2011 12:18 PM, dsimcha wrote:
 == Quote from Walter Bright (newshound2 digitalmars.com)'s article
 A further issue with the review process is that the bulk of people
 won't look at
 something until it is actually released. I think the only way to deal
 with this
 is to be willing to correct deficiencies found after release.

 Please clarify "release". If you mean making the code and
 documentation public
 and conveniently accessible, that's the point of the review process.
 If you mean
 actually including it with the DMD distribution, then maybe we need an
 "incubator"
 package as others have suggested. Things would get in incubator after
 abbreviated
 review. While in incubator we'd make no guarantees about their
 stability or even
 their continued inclusion. The "real" review would take place over a
 release
 cycle or two, while the module was in incubator. After each release
 cycle, we'd
 make a three-way decision. A module can:

 1. Be declared stable and promoted to std.

 2. Be declared not worthwhile and removed.

 3. Kept in incubator pending further review and improvements.

 I have thought in the past about putting such modules into another
 package, call it "foo" for lack of a better name, and put it in the dmd
 distribution. If the package pans out in real life, then move it to std.
 So, yes, I think your idea is a good one.

Hum, this seems like an very interesting idea, it should definitely be 
considered (perhaps, especially so if the number of people participating 
in the review process remains low?).
So, a kind of incubator/experimental package. The modules here should be 
fairly stable (in terms of bugs), but the API would not be stable, it 
would change as people used the lib, feedback was received, changes were 
made, etc.

-- 
Bruno Medeiros - Software Engineer

spir <denis.spir gmail.com> writes:

On 03/28/2011 09:18 PM, dsimcha wrote:
 == Quote from Walter Bright (newshound2 digitalmars.com)'s article
 A further issue with the review process is that the bulk of people won't look
at
 something until it is actually released. I think the only way to deal with this
 is to be willing to correct deficiencies found after release.

 Please clarify "release".  If you mean making the code and documentation public
 and conveniently accessible, that's the point of the review process.  If you
mean
 actually including it with the DMD distribution, then maybe we need an
"incubator"
 package as others have suggested.  Things would get in incubator after
abbreviated
 review.  While in incubator we'd make no guarantees about their stability or
even
 their continued inclusion.  The "real" review would take place over a release
 cycle or two, while the module was in incubator.  After each release cycle,
we'd
 make a three-way decision.  A module can:

 1.  Be declared stable and promoted to std.

 2.  Be declared not worthwhile and removed.

 3.  Kept in incubator pending further review and improvements.

Anyway,n this is far better than premature adoption (mainly because later found 
issues often reveal design bugs that require major modification).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com