>On Fri, Aug 29, 2014 at 3:59 PM, Michael Raskin <7c6f4...@mail.ru> wrote: >> >> I would say that ZHF has some progress specifically because it is about >> reasonable efforts to improve signal-to-noise. >> >> If we want packages to get updated, we need to merge pull requests >> faster and not let pull requests linger in limbo. That would make >> sending PRs for updates look like a good idea (so less burden on >> maintainers to monitor updates). For complex questions, we should Cc: >> the maintainers of the packages in question (or of the most similar >> packages with maintainers) — but the idea is that more people should >> read pull requests. Once in a couple of weeks I find time to reduce the >> amount of pending PRs by a page. Five more people among committers to do >> the same and we'll have no pending PRs without good reason for >> a detailed discussion, I hope… >> > >Well, I'm not the committer. But I think the problem with looking to >PR, is that there are 110 unsorted PRs. It's hard to look them all in >one go. And it's useless that all committers look at them all. If >there would be 11 groups of 10 PRs, it's easier to look at 10 PRs >several times a week.
This is not how you solve the problem! You look at 20 random PRs, merge or ask someone to merge 10 of them, propose rejection of a couple, and CC a couple people you think could know something for eah of the rest… After fifteen passes the problem gets reduced to a manageable size. Look at ZHF: there was nothing bout division, ther was just a plea for attention to a problem. When the problem got reduced, some natural groups of broken packages emerged that were dispatched by those who understood them. Most of pull requests are simple to review as net-positive… _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
