On Mon, Apr 18, 2011 at 11:15 PM, Alex Hunsaker <bada...@gmail.com> wrote:
> On Mon, Apr 18, 2011 at 19:50, Josh Berkus <j...@agliodbs.com> wrote:
>> You'll notice that this has been a complaint of veteran contributors as
>> well; WIP patches either get no review, or get reviewed as if they were
>> expected to be committable.
>
> I don't see this changing anytime in the future. We have a hard enough
> time getting "finished" patches reviewed.

Sadly so.

As much as I think we have gotten a LOT of useful milage out of the
"commitfest" concept, it does, conceptually, have a strong bias
(including in its very name) towards the assumption that changes are
pretty much ready to commit.

Two items still undergoing work (collations, sync rep) weren't at that
level of readiness, needing some mere "dusting off" to make them
ready.  Rather, they needed substantial examination and modification
before they'd be ready.  And, while this has doubtless aroused some
ire, it doesn't intrinsically make those items "broken."

The Apache guys may be onto something in having the "incubator"
moniker, for things that aren't "so ready we're calling them
Commitable."

There may be merit to separating out "easy to commit" and "tougher to
commit" items, and having different kinds of pickiness for them, the
former being good fodder for "Easy CommitFest" and the latter being
"PG Incubation."

Though I'm not sure the latter makes it any easier to get tough
features like synchronous replication into place.

>> The person who e-mailed me suggests some form of PostgreSQL Incubator as
>> a solution.   I'm not sure about that, but it does seem to me that we
>> need somewhere or some way that people can submit patches, ideas, git
>> forks, etc., for discussion without that discussion needing to
>> immediately move to the cleanliness/maintainability/supportable status
>> of the patch.
>
> Reminds me a bit of what linux is doing with the "staging" tree. I
> don't see anyway for that to work with postgres (lower the bar for
> -contrib?).
>
> You can fork fairly easy with github nowdays. For example the replace
> GEQ with SA is on one of those git sites. Does that mean it gets any
> attention? *shrug*

Well, the project hasn't been on Git for all that spectacularly long a
time, so the comfort level with managing via forks maybe isn't quite
there yet.

Forking isn't as magically delicious as GitHub might make some
imagine; it's fine and useful to have a bunch of forks, and eventually
merge useful ones, when they are remaining pretty close together, and
don't conflict.  That's likely to work out happily for features that
are essentially independent.  If you and I are hacking on different
contrib modules, that's pretty "essentially independent."

Unfortunately, deeper features are more likely to be more
interdependent, and forks aren't so readily productive in that case.

If we hack around with formatting, that would muck with *everything*
else, as an even worse "for instance."
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to