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
