Re: Pull requests processing issue
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.
Re: Pull requests processing issue
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.
Re: Pull requests processing issue
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
Re: Pull requests processing issue
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.
Re: Pull requests processing issue
On 18/04/12 12:19, Alex Rønne Petersen wrote: On 18-04-2012 11:00, 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? Just looking at the auto tester, there seems to be tons of stuff that can readily be merged... One problem is github. IMHO github's pull requests are quite ridiculous, there is no way to prioritize them. There are quite a lot of pull requests in there which are doubtful, high-risk, or require a lot of time to evaluate. Currently, we don't have a way to deal with them. But, the announce list is not the appropriate place for this discussion. Please move to the main list if you want to comment further.
Re: Pull requests processing issue
On 18-04-2012 11:00, 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? Just looking at the auto tester, there seems to be tons of stuff that can readily be merged... -- - Alex
Pull requests processing issue
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?
