On 28/03/2011 20:19, Walter Bright wrote:
On 3/28/2011 12:18 PM, dsimcha wrote:
== Quote from Walter Bright (newshou...@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
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
== Quote from Walter Bright (newshou...@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.
On 3/28/2011 12:18 PM, dsimcha wrote:
== Quote from Walter Bright (newshou...@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
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.
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
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
On 28/03/11 21.19, Walter Bright wrote:
On 3/28/2011 12:18 PM, dsimcha wrote:
== Quote from Walter Bright (newshou...@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
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.
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
On 03/28/2011 09:18 PM, dsimcha wrote:
== Quote from Walter Bright (newshou...@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
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
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 (newshou...@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
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
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
15 matches
Mail list logo
