On Wednesday, 18 April 2012 at 09:00:59 UTC, Trass3r wrote:
>> I think the problem of ~100 open pull requests needs to be faced better. People that see their patches rot in that list probably don't feel rewarded enough to submit more patches.
>
> So true. I won't do any further work if it's in vain anyway.
> Also I regularly have to rebase my one cause of conflicts, which is annoying.
>
> I really wonder what Walter's doing. Is he still running the whole testsuite instead of relying on the autotester?

Well, I've seen at least one regression in D.learn from 2.058 to 2.059 and that doesn't give me much confidence in what random people are doing when they are submitting their patches.

So instead of bitching about what Walter's doing, people should be more careful what THEY are doing.

On Wednesday, 18 April 2012 at 10:39:26 UTC, Don Clugston wrote:
> One problem is github. IMHO github's pull requests are quite ridiculous, there is no way to prioritize them.

You can't blame GitHub for something we are not using it for – pull request, as far as we are using them, are just a tool to keep patches close to the source so that they can conveniently be reviewed and merged. Issue tracking, prioritization, etc. all happens on Bugzilla, and every pull request should have an accompanying »pull«-tagged Bugzilla entry.

The infrastructure is already there, Walter (and the rest of us) just need to use it more aggressively – and if not, determine what exactly is wrong with it in terms of productivity, instead of just randomly blaming our tools.

David

On 19/04/12 16:58, David Nadlinger wrote:
> On Wednesday, 18 April 2012 at 10:39:26 UTC, Don Clugston wrote:
>> One problem is github. IMHO github's pull requests are quite
>> ridiculous, there is no way to prioritize them.
>
> You can't blame GitHub for something we are not using it for – pull
> request, as far as we are using them, are just a tool to keep patches
> close to the source so that they can conveniently be reviewed and
> merged.

If that is so, then this thread is invalid -- the number of open pull requests is not a useful metric.

Issue tracking, prioritization, etc. all happens on Bugzilla,
> and every pull request should have an accompanying »pull«-tagged
> Bugzilla entry.
>
> The infrastructure is already there,

Is it? I can't see any method for dealing with patches that aren't merged immediately.
We have bugzilla as a priority system for bugs without patches, github works for submitting patches, and a great infrastructure for testing the compiler after patches are merged (thanks Brad!) but the patch evaluation step (specifically, the "code review" part) is missing.

On Monday, 23 April 2012 at 11:46:50 UTC, Don Clugston wrote:

>>
>> The infrastructure is already there,
>
> Is it? I can't see any method for dealing with patches that aren't merged immediately.
> We have bugzilla as a priority system for bugs without patches, github works for submitting patches, and a great infrastructure for testing the compiler after patches are merged (thanks Brad!) but the patch evaluation step (specifically, the "code review" part) is missing.

There is an open source code review tool that integrates with git called Gerrit. It is used by Google for Android and other large code bases comprised of several git repositories. I think it's closer to Walter's way of managing code.