<br><br><div class="gmail_quote">On Mon, Apr 20, 2009 at 1:59 PM, Gerhard Killesreiter <span dir="ltr"><<a href="mailto:gerhard@killesreiter.de">gerhard@killesreiter.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Earl Miles schrieb:<br>
</div><div><div></div><div class="h5">> Dries Buytaert wrote:<br>
>> As core matures, we might see more patches getting stale. I think the<br>
>> reason is (at least) two-fold:<br>
>><br>
>> 1) More patches compete for attention, but fewer of these patches are<br>
>> truly important. In this case, patches getting stale is not<br>
>> necessarily a bad thing because history has proven that important<br>
>> patches will eventually bubble to the top for the right reasons.<br>
><br>
> If the 'right reasons' are because the developers got frustrated with<br>
> the process and quit pushing their patch, whereas other developers are<br>
> extremely stubborn and managed to push their patch through anyway, then<br>
> sure. But just because some developer is bullheaded enough to wade<br>
> through the crap doesn't mean that's the right reasons.<br>
><br>
<br>
</div></div>Right or wrong: this is not new. You always had to be persistent (or<br>
stubborn) in order to push through larger changes.</blockquote><div> </div><div>I noted this wasn't new in a brief chat on irc. More its amplified. It sounds like some people feel things have changed procedurally in someway that has made things worse but its more we haven't grown in the way we do things in a way that's kept up with the size of our community.<br>
<br>When the community was smaller it was easier for you to just hope on IRC and talk out a concern with someone about an issue before derailing things. Now there are so many people discussing and so many people with a stake in core these derailing discussions become more and more common place and harder to get around.<br>
<br>The way we seem to have delt with this for some crucial systems in the D7 is with numerous code sprints. I don't think this is going to pan out as an answer either since not everyone can pick up and travel or get time off to sit down and contribute to things they are interested in.<br>
<br>Another option that's happened is making little Drupal forks in external repositories where they can work on these larger problems. Without any policy or direction this is its own scary can of worms.<br><br>So, I definitely feel we need to take a look at how we develop core a bit. There seems to be a need to group core into systems and initiatives that people can direct their focus on. I don't think what we really want is to remove the core commiter role but we want to widen things directly below that.<br>
<br>Based on the external repositories, maybe the more distributed lieutenant model used in the linux kernel would work for us? That might have a heavy infrastructure cost but it might address the problem.<br><br>Another option might be just something clever in the d.o redesign that more closely tie issues with groups so issues are easier to find, follow and discuss. There might even be some sort of group/core component ownership that can help funnel better reviews into patches and by proxy better patches to the core committers. Either way, I think that we need something allows the community to scale a little better as we continue to grow.<br>
<br>--<br>James Gilliland<br></div></div>