On 2015-01-16 21:44, Andrei Alexandrescu wrote:
Look for a champion after $(X) days? It looks like once a pull request
is open it's impossible to close it. There's got to be some garbage
collection somehow :o). -- Andrei
It's always possible to add a label to the pull request.
--
/Jacob
On 2015-01-16 18:49, Andrei Alexandrescu wrote:
I agree that a hamfisted policy would do more harm than good. That's why
it's so hard to define!
I'm thinking of something like: if there's $(legitimate) request for
changes but the author is dormant for more than $(X) days, then close.
Does
On 2015-01-16 20:23, Walter Bright wrote:
Arbitrarily closing them means they get lost forever.
How so?
--
/Jacob Carlborg
On 2015-01-17 00:49, H. S. Teoh via Digitalmars-d wrote:
Does github have that option? If so, can somebody who has the rights
make this change?
Not as far as I can see. The settings page for a project doesn't contain
much.
--
/Jacob Carlborg
On 2015-01-16 19:50, deadalnix wrote:
It is better to have some kind of bot that comment on the PR after a
while. Like hey, this PR is hanging, can someone make thing go forward
or I'll close in 2 more month. That generate activity on the PR and is
often a wake up call for people.
Ruby on
On Saturday, 17 January 2015 at 11:52:03 UTC, Jacob Carlborg
wrote:
On 2015-01-16 19:50, deadalnix wrote:
It is better to have some kind of bot that comment on the PR
after a
while. Like hey, this PR is hanging, can someone make thing
go forward
or I'll close in 2 more month. That generate
Informative is fine. Basing decisions on metrics unleavened by
contextual judgement isn't going to work well.
It isn't just one metric. I've personally seen it multiple
times with various metrics, and regularly read in the news
about counterproductive results obtained by using metrics
On Friday, 16 January 2015 at 04:20:37 UTC, Walter Bright wrote:
http://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/
Most are intuitive, but 10. Avoid thrashing is worthy.
On Thu, Jan 15, 2015 at 08:20:32PM -0800, Walter Bright via Digitalmars-d wrote:
http://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/
I agree with pretty much everything in this article.
tl,dr:
The more you make your reviewer work, the greater the risk is that
your Pull
On 1/16/15 7:50 AM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Jan 15, 2015 at 08:20:32PM -0800, Walter Bright via Digitalmars-d wrote:
http://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/
I agree with pretty much everything in this article.
tl,dr:
The more you make your
-for-better-pull-requests/
I agree with pretty much everything in this article.
tl,dr:
The more you make your reviewer work, the greater the risk is that
your Pull Request will be rejected.
In the case of D, the more you make your reviewer(s) work, the greater
the risk is that your
Bright via
Digitalmars-d wrote:
http://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/
I agree with pretty much everything in this article.
tl,dr:
The more you make your reviewer work, the greater the risk
is that
your Pull Request will be rejected.
In the case of D
, Jan 15, 2015 at 08:20:32PM -0800, Walter Bright via
Digitalmars-d wrote:
http://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/
I agree with pretty much everything in this article.
tl,dr:
The more you make your reviewer work, the greater the risk is
that
your Pull Request
On Fri, Jan 16, 2015 at 05:16:38PM +, Tobias Pankrath via Digitalmars-d
wrote:
On Friday, 16 January 2015 at 16:22:13 UTC, ketmar via Digitalmars-d wrote:
On Fri, 16 Jan 2015 08:10:50 -0800
Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com
wrote:
[...]
I think it would be
wrote:
On 1/16/15 7:50 AM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Jan 15, 2015 at 08:20:32PM -0800, Walter Bright via
Digitalmars-d wrote:
http://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/
I agree with pretty much everything in this article.
tl,dr
Bad idea. Take for example this one of mine
https://github.com/D-Programming-Language/phobos/pull/2793
that sits
there for more than 20 days. I've addressed all concerns and
now it's
waiting for someone who feels responsible for std.container to
pull it.
Now four things can happen:
1.
On 1/16/15 9:41 AM, Tobias Pankrath wrote:
That reply was not about my pull request specifically. Since it
basically consists of two new files, it can stay there for months
without generating any additional work for me. But it is a good
counterexample to the »just close old stuff«-policy.
I
I agree that a hamfisted policy would do more harm than good.
That's why it's so hard to define!
I'm thinking of something like: if there's $(legitimate)
request for changes but the author is dormant for more than
$(X) days, then close.
Andrei
Macros:
legitimate=?
X=?
legitimate=
On Friday, 16 January 2015 at 16:22:13 UTC, ketmar via
Digitalmars-d wrote:
it sits in queue without any comments more than 20 days? reject
and
close it.
It is better to have some kind of bot that comment on the PR
after a while. Like hey, this PR is hanging, can someone make
thing go
On 1/16/2015 9:49 AM, Andrei Alexandrescu wrote:
I'm thinking of something like: if there's $(legitimate) request for changes but
the author is dormant for more than $(X) days, then close.
That's also a hamfisted policy. I've seen PR's that were good, but needed a bit
of work, but the author
On Friday, 16 January 2015 at 18:50:29 UTC, deadalnix wrote:
On Friday, 16 January 2015 at 16:22:13 UTC, ketmar via
Digitalmars-d wrote:
it sits in queue without any comments more than 20 days?
reject and
close it.
It is better to have some kind of bot that comment on the PR
after a while.
On 1/16/15 11:23 AM, Walter Bright wrote:
On 1/16/2015 9:49 AM, Andrei Alexandrescu wrote:
I'm thinking of something like: if there's $(legitimate) request for
changes but
the author is dormant for more than $(X) days, then close.
That's also a hamfisted policy. I've seen PR's that were good,
On Friday, 16 January 2015 at 19:23:06 UTC, Walter Bright wrote:
On 1/16/2015 9:49 AM, Andrei Alexandrescu wrote:
I'm thinking of something like: if there's $(legitimate)
request for changes but
the author is dormant for more than $(X) days, then close.
That's also a hamfisted policy. I've
On Fri, 16 Jan 2015 11:23:02 -0800
Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote:
On 1/16/2015 9:49 AM, Andrei Alexandrescu wrote:
I'm thinking of something like: if there's $(legitimate) request for
changes but
the author is dormant for more than $(X) days, then
On 1/16/2015 12:44 PM, Andrei Alexandrescu wrote:
On 1/16/15 11:23 AM, Walter Bright wrote:
On 1/16/2015 9:49 AM, Andrei Alexandrescu wrote:
I'm thinking of something like: if there's $(legitimate) request for
changes but
the author is dormant for more than $(X) days, then close.
That's also
On 1/16/2015 12:48 PM, Vladimir Panteleev wrote:
On Friday, 16 January 2015 at 19:23:06 UTC, Walter Bright wrote:
On 1/16/2015 9:49 AM, Andrei Alexandrescu wrote:
I'm thinking of something like: if there's $(legitimate) request for changes but
the author is dormant for more than $(X) days,
On 1/16/15 2:17 PM, Walter Bright wrote:
I've worked at companies that would rate engineers based on the bug
count. That ended very badly, it was so bad it was comical, how working
that number actually wrecked the quality of the product. I've seen
similar disasters with use of metrics on
On 1/16/2015 2:28 PM, Andrei Alexandrescu wrote:
On 1/16/15 2:17 PM, Walter Bright wrote:
I've worked at companies that would rate engineers based on the bug
count. That ended very badly, it was so bad it was comical, how working
that number actually wrecked the quality of the product. I've
On Fri, Jan 16, 2015 at 02:17:02PM -0800, Walter Bright via Digitalmars-d wrote:
On 1/16/2015 12:48 PM, Vladimir Panteleev wrote:
[...]
Add an abandoned label, and assign it when closing? Then they won't
get lost, but also won't clutter the list.
What should happen is the list of PRs should
On 1/16/2015 2:59 PM, H. S. Teoh via Digitalmars-d wrote:
Github already has a feature for sorting the PR list by most recently
updated, least recently updated, oldest, newest, etc., etc..
It's just a matter of setting the *default* sorting order. I don't know
if github supports that, but for a
On Fri, Jan 16, 2015 at 03:33:00PM -0800, Walter Bright via Digitalmars-d wrote:
On 1/16/2015 2:59 PM, H. S. Teoh via Digitalmars-d wrote:
Github already has a feature for sorting the PR list by most recently
updated, least recently updated, oldest, newest, etc., etc..
It's just a matter of
On Friday, 16 January 2015 at 23:51:40 UTC, H. S. Teoh via
Digitalmars-d wrote:
It may not directly impact the quality of the product, but it
*could* affect morale (potential contributor looks at the PR
list, sees it's 90+, and feels that it's unlikely his
contributions
will ever get accepted,
http://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/
I agree with pretty much everything in this article.
tl,dr:
The more you make your reviewer work, the greater the risk is that your Pull
Request will be rejected.
33 matches
Mail list logo
