[dmd-internals] To consume pull requests for trivial bugs

Don Clugston dclugston at gmail.com
Tue Aug 21 00:43:52 PDT 2012


On 20 August 2012 23:09, David Nadlinger <code at klickverbot.at> 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.


More information about the dmd-internals mailing list