[Potlatch-dev] Outstanding pull requests (Attn Richard F)

[Steve Bennett]

On Tue, Jul 17, 2012 at 9:50 PM, Frederik Ramm <frederik at remote.org> wrote:
> May I, as a Potlatch outsider, offer
>
> 4) Carefully considered patches
>
> I think that the assumption that any patch deserves to be applied -
> especially if it adds a new feature, or a new preset, or changes appearance,
> or has a side effect - is difficult. It is possible that some patches are
> kept waiting because the maintainer is too polite to say "nice work but I
> don't like how it modifies my project".

A valid point, in general. I think in this case, the devs have usually
been upfront when that's been the case, and I've made further
iterations in several instances. I completely re-wrote the magic
roundabout patch once because of a disagreement about undo stack
protocols, and have partially rewritten it at least once since then
due to bitrot.

> On github, of course anyone can make their "dev build" and they can choose
> which features to accept.

Yeah, that's a feature of Git which sounds nice in theory, but in
practice (or at least in this instance) doesn't offer much value. I
don't write code so that I can have my own private editor with
features I like. I write code so that the broader community can
benefit - and the only way that happens is if it's deployed on
openstreetmap.org.

> However, again, expecting that any future
> development be based on a heap of auto-accepted not-maintainer-controlled
> pull requests would essentially mean going back to SVN where anybody could
> just dump their shit into the repository and leave the maintainer to
> separate the wheat from the chaff.

What you're describing is the current model: everyone proposes pull
requests, then Richard has to evaluate them all personally and decide
which ones to accept into production.

I'm proposing spreading the load: accept all the pull requests onto
some dev branch, so that at the least, all the devs are seeing them in
their local instances. Then we can all contribute to evaluating them,
spotting bugs, and discussing which ones to accept or reject.

Steve