On 20 August 2012 23:09, David Nadlinger <[email protected]> wrote: > On 20 Aug 2012, at 22:40, Jason House wrote: >> >> I'm not particularly familiar with Linux kernel development, but my >> understanding is that smaller commits are aggregated by select helpers, and >> then the larger changsets are merged by the BDFL. Maybe something similar >> would work for DMD? > > > The problem is to attract enough contributors so that at some point a > sufficiently large number of them become "core contributors" who are > familiar enough with an area of the codebase to review patches. > > Of course, this is unlikely to happen as long as everyone is discouraged > after the first few pull request by a queue of 100 open pull request, and so > we are back at the start again. ;) > > David
On the matter of the 100 open pull requests -- I don't have any idea how we can deal with this. More people would help with the issue mentioned in the original post (which is basically that Kenji is a prolific author!), but wouldn't reduce the number of open pull requests in general. It seems to me to be an inevitable consequence of GitHub, where we're using a single list for both 'work in progress' and 'ready for review'. Fundamentally, I have no idea of how a sensible development methodology can be constructed using GitHub pull requests. When your only way to contribute code is via a pull request, and when the only way to closing a pull request are *merge it OR *reject it, it seems inevitable that the number of pull requests will increase indefinitely. If it is mostly OK but needs a bit more work, it stays open. If it is deferred to the next cycle, it stays open. If it needs discussion, it stays open. If it is OK but has a merge conflict with another pull request, it stays open. An alternative would be to close it whenever any kind of issue is found, but then we lose the 'work in progress' information and reduce the number of people looking at the code. The more I use git, the more I like it; the more I use github, the more I hate it. It seems to promote an organization which doesn't make any sense. As far as I can tell, you can't even get the single most important piece of information: which pull requests have I made (for all projects), and how many are still open? Which branches can I safely remove, now? You can however trivially change a pull request, even after it's been reviewed, by accidentally pushing to the same branch! To me, github is a giant WTF. Now everyone raves about how good github is, so I must be missing something. Presumable, we are using it horribly wrongly. In any case, I am certain that we need to change something, not just add extra manpower. I went through the old pull requests (those of number 650 or less), especially the yebblies ones, and merged everything I could. Almost all of the remaining ones have some problem. But you can't tell this, by just looking at the open pull requests. And since you cannot mark the pull requests in any searchable way, you cannot see which have been triaged and which have not. AFAIK you can't even see which have been commented on most recently. _______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
