-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
If the feature set is desirable, though, I wonder if Postgres is
big/high profile enough for them to figure out some sort of better
arrangement. They *love* it when big open-source projects use GitHub
as their public repo - they'll email
Jay Levitt jay.lev...@gmail.com writes:
No meaningful search, eh? Works for me.
Redmine searches return partial-word matches, and there's no way to
disable that. Searching for test finds latest. To me, that's
broken.
Well, I believe one can plug in a different search engine, like lucene
On Sun, Apr 15, 2012 at 8:23 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Sat, Apr 7, 2012 at 9:51 PM, Robert Haas robertmh...@gmail.com wrote:
I think this basically just boils down to too many patches and not
enough people. I was interested in Command Triggers from the
beginning of this
On Sun, Apr 15, 2012 at 11:31 PM, Greg Smith g...@2ndquadrant.com wrote:
On 04/15/2012 05:46 AM, Simon Riggs wrote:
Our problem is not lack of resource, it is ineffective
delegation. As Hannu points out, he didn't know the patch would be
rejected, so he didn't know help was needed to save
Alvaro Herrera alvhe...@commandprompt.com writes:
I've used Redmine a lot, as you know, and I only keep using it because
it's a requirement at work. It is certainly not close to usable for
general pgsql stuff. (Trac, which we used to use prior to Redmine, was
certainly much worse, though).
On 04/15/2012 12:01 PM, Tom Lane wrote:
Where I think we have been fooling ourselves is in failing to tell
the difference between a patch that is committable in the current fest,
versus one that is still WIP and is going to need more development time.
I wonder if this bit of state might be
Alex wrote:
Jay Levittjay.lev...@gmail.com writes:
Alex wrote:
I didn't follow this whole thread, but have we considered Redmine[1]?
As the resident Ruby is shiny, let's do everything in Rails on my
MacBook guy, I'd like to make a statement against interest: I've
tried Redmine a few times
On Sat, Apr 14, 2012 at 2:28 PM, Jay Levitt jay.lev...@gmail.com wrote:
Christopher Browne wrote:
On Thu, Apr 12, 2012 at 6:11 PM, Jay Levittjay.lev...@gmail.com wrote:
Rather than extend the CF app into a trivial-patch workflow app, it might
be
worth looking at integrating it with github.
On Fri, Apr 6, 2012 at 8:19 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Smith g...@2ndquadrant.com writes:
On 04/05/2012 04:27 PM, Simon Riggs wrote:
It's shocking since after months of work and an especially extended
edition CF, we expect people to deliver something, not just shunt the
whole
On Wed, Apr 11, 2012 at 6:59 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Apr 11, 2012 at 1:39 PM, Joshua Berkus j...@agliodbs.com wrote:
Ultimately, we're herding cats here. I don't think you're going to
get
the community to suddenly be willing to march in lockstep instead.
If you,
On Sat, Apr 7, 2012 at 10:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
[ among other good points ]
... On a related note, letting CommitFests go on for three
months because there's insufficient reviewer activity to get them done
in one or two is, in my
On Sat, Apr 7, 2012 at 9:51 PM, Robert Haas robertmh...@gmail.com wrote:
I think this basically just boils down to too many patches and not
enough people. I was interested in Command Triggers from the
beginning of this CommitFest, and I would have liked to pick it up
sooner, but there were a
On Tue, Apr 10, 2012 at 3:26 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Christopher Browne cbbro...@gmail.com wrote:
Robert Haas robertmh...@gmail.com wrote:
CommitFests are a time for patches that are done or very nearly
done to get committed, and a time for other patches to get
Simon Riggs si...@2ndquadrant.com writes:
I completely agree that somebody has to be willing to say No, since we
all agree that the default for any patch is non-acceptance.
My first observation is that if No is received early enough for
something to be done, then the outcome could be
Simon Riggs si...@2ndquadrant.com writes:
If we can do Triage Week at the beginning, that will keep out the ones
that aren't ready and allow us to focus our attention on the ones we
really care about.
I think there's some merit in this idea, but there needs to be time
allocated to examine all
On Sun, Apr 15, 2012 at 4:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think this is a rather unfair summary of the history. It was clear
very early in the CF that people thought Command Triggers had major
design problems, and Dimitri was doing significant rewrites to try to
fix that. Anyone
On 04/14/2012 06:03 PM, Robert Haas wrote:
If someone's work is going to require substantial
revision, it is much better and much less work to do that revision
before the code goes into our repository (and particularly, before it
gets released) rather than after.
I would think one of the major
On 04/14/2012 05:28 PM, Jay Levitt wrote:
I see now that the Reviewing a Patch wiki page explains this, but
maybe this info should be pushed higher into the docs and web site; a
How can I contribute page, open calls for reviewers on the non-hackers
mailing lists, things like that. Or maybe just
On 04/15/2012 05:46 AM, Simon Riggs wrote:
Our problem is not lack of resource, it is ineffective
delegation. As Hannu points out, he didn't know the patch would be
rejected, so he didn't know help was needed to save something useful.
I considered that the job of the CF manager, but perhaps it
Excerpts from Alex's message of dom abr 15 01:52:16 -0300 2012:
Jay Levitt jay.lev...@gmail.com writes:
Alex wrote:
I didn't follow this whole thread, but have we considered Redmine[1]?
As the resident Ruby is shiny, let's do everything in Rails on my
MacBook guy, I'd like to make
Peter Eisentraut pete...@gmx.net writes:
On ons, 2012-04-11 at 23:30 -0400, Robert Haas wrote:
Now what would be sort of neat is if we had a way to keep all the
versions of patch X plus author and reviewer information, links to
reviews and discussion, etc. in some sort of centralized place.
On 04/14/2012 03:02 AM, Alex wrote:
I didn't follow this whole thread, but have we considered Redmine[1]?
It comes up every couple of years in contexts near this one, such as
http://wiki.postgresql.org/wiki/TrackerDiscussion
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com
Greg Smith g...@2ndquadrant.com writes:
On 04/14/2012 03:02 AM, Alex wrote:
I didn't follow this whole thread, but have we considered Redmine[1]?
It comes up every couple of years in contexts near this one, such as
http://wiki.postgresql.org/wiki/TrackerDiscussion
Oh, I see. I wonder
Alex a...@commandprompt.com writes:
Greg Smith g...@2ndquadrant.com writes:
On 04/14/2012 03:02 AM, Alex wrote:
I didn't follow this whole thread, but have we considered Redmine[1]?
It comes up every couple of years in contexts near this one, such as
Christopher Browne wrote:
On Thu, Apr 12, 2012 at 6:11 PM, Jay Levittjay.lev...@gmail.com wrote:
Rather than extend the CF app into a trivial-patch workflow app, it might be
worth looking at integrating it with github.
There's a reluctance to require a proprietary component that could
Alex wrote:
I didn't follow this whole thread, but have we considered Redmine[1]?
As the resident Ruby is shiny, let's do everything in Rails on my MacBook
guy, I'd like to make a statement against interest: I've tried Redmine a few
times and it's been painful. Much of the codebase is
On Tue, Apr 10, 2012 at 8:43 PM, Greg Smith g...@2ndquadrant.com wrote:
The main reason I worry about this is because of a very real chicken/egg
problem here that I keep banging into. Since the commit standards for so
many other open-source projects are low, there are a non trivial number of
Jay Levitt jay.lev...@gmail.com writes:
Alex wrote:
I didn't follow this whole thread, but have we considered Redmine[1]?
As the resident Ruby is shiny, let's do everything in Rails on my
MacBook guy, I'd like to make a statement against interest: I've
tried Redmine a few times and it's
Robert Haas robertmh...@gmail.com writes:
Even before this CommitFest, it's felt to me like this hasn't been a
great cycle for reviewing. I think we have generally had fewer people
doing reviews than we did during the 9.0 and 9.1 cycles. I think we
had a lot of momentum with the CommitFest
Tom Lane t...@sss.pgh.pa.us writes:
Andres Freund and...@anarazel.de writes:
They might have been half-baked. But several of those didn't get design-level
review for several weeks which makes it rather hard to fully bake them in
time...
But if they didn't already have design-level review,
Robert Haas robertmh...@gmail.com writes:
The real problem with the command triggers patch is that we got a
blizzard of code. It's unrealistic to expect anyone to devote serious
review time to a patch that's under constant development. It also
strikes me that a tremendous amount of pain
On tor, 2012-04-12 at 10:12 -0500, Joshua Berkus wrote:
Well actually, the other advantage of using branches is that it would
encourage committers to bounce a patch back to the submitter for
modification *instead of* doing it themselves. This would both have
the advantage of saving time for
On ons, 2012-04-11 at 23:30 -0400, Robert Haas wrote:
Now what would be sort of neat is if we had a way to keep all the
versions of patch X plus author and reviewer information, links to
reviews and discussion, etc. in some sort of centralized place.
Well, a properly linked email thread
On tor, 2012-04-12 at 07:59 +0200, Magnus Hagander wrote:
It might be helpful (if the CF app had a trivial API) with a small
tool that could run from a git hook (or manual script or alias) that
would prompt for which cf entry, if any, did this commit close?
An API for the CF app would actually
On tor, 2012-04-12 at 18:19 -0400, Christopher Browne wrote:
On Thu, Apr 12, 2012 at 6:11 PM, Jay Levitt jay.lev...@gmail.com wrote:
Rather than extend the CF app into a trivial-patch workflow app, it might be
worth looking at integrating it with github.
There's a reluctance to require a
On Thu, Apr 12, 2012 at 05:49, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Apr 11, 2012 at 5:36 PM, Peter Eisentraut pete...@gmx.net wrote:
I'd still review it, but I'd be able to spend say 3 minutes on review
and 30 seconds on committing it, versus 3
On Tue, Apr 10, 2012 at 08:43:12PM -0400, Greg Smith wrote:
The main reason I worry about this is because of a very real
chicken/egg problem here that I keep banging into. Since the commit
standards for so many other open-source projects are low, there are
a non trivial number of business
Excerpts from Tom Lane's message of jue abr 12 00:49:38 -0300 2012:
At the other end of the scale, I think it's true that the CF app could
be more helpful than it is for tracking the state of complex patches.
I don't really have any concrete suggestions, other than that I've
seen far too
On 12 April 2012 13:45, Bruce Momjian br...@momjian.us wrote:
I want to caution against adjusting things to improve funding
possibilities. There is nothing wrong with increasing funding
possibilities, per say, but such changes often distort behavior in
unforeseen ways that adversely affect
On 04/11/2012 10:24 AM, Tom Lane wrote:
Greg Smithg...@2ndquadrant.com writes:
I'd like to dump around 50 pages of new material into the docs as a
start, but I don't want to take so much time away from the code oriented
committers to chew on that much.
Well, with all due respect, that does
If we were actually using git branches for it, the CF app could
automatically close entries when they were committed. But that
requires them to be committed *unmodified*, and I'm not sure that's
reasonable. I also think requiring a git branch for the *simple*
changes is adding more tooling
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I want to caution against adjusting things to improve funding
possibilities. There is nothing wrong with increasing funding
possibilities, per say, but such changes often distort behavior in
unforeseen ways that adversely affect our
On Thu, Apr 12, 2012 at 03:34:31PM +0100, Peter Geoghegan wrote:
Something that I would suggest is that those that are receiving
funding be transparent about it. It isn't essential of course, but to
do any less might lead to the perception of there being a conflict of
interests in some
I think the big take-away, education-wise, is that for our project,
committer == grunt work. Remember, I used to be the big committer of
non-committer patches --- need I say more. ;-) LOL
Well, promoting several people to committer specifically and publically because
of their review work
On Thu, Apr 12, 2012 at 11:34:48AM -0400, Bruce Momjian wrote:
On Thu, Apr 12, 2012 at 03:34:31PM +0100, Peter Geoghegan wrote:
Something that I would suggest is that those that are receiving
funding be transparent about it. It isn't essential of course, but to
do any less might lead to the
On 04/12/2012 11:34 AM, Bruce Momjian wrote:
The specific suggestion that vendors are not taking contributors
seriously unless they have commit-bits is perhaps something that
requires education of vendors, or perhaps my blogging about this will
help.
I'm glad I managed to vent my frustration
On Wed, Apr 11, 2012 at 12:00:39PM -0300, Alvaro Herrera wrote:
remote in their main PG tree, and so changesets could be pulled into the
same clone and cherry-picked into the master branch.
If you're talking about a way of using git to support reviewing, the
Gerrit tool has an interesting
Alvaro Herrera wrote:
Now what would be sort of neat is if we had a way to keep all the
versions of patch X plus author and reviewer information, links to
reviews and discussion, etc. in some sort of centralized place.
FWIW: y'all might have discussed to death during the git migration, so
On Thu, Apr 12, 2012 at 6:11 PM, Jay Levitt jay.lev...@gmail.com wrote:
Rather than extend the CF app into a trivial-patch workflow app, it might be
worth looking at integrating it with github.
There's a reluctance to require a proprietary component that could
disappear on us without notice.
On Wednesday, April 11, 2012, Robert Haas wrote:
On Tue, Apr 10, 2012 at 10:05 PM, Peter Geoghegan
pe...@2ndquadrant.comjavascript:;
wrote:
On 11 April 2012 02:14, Robert Haas robertmh...@gmail.comjavascript:;
wrote:
My perception of what's going on here is dramatically different from
On Tue, Apr 10, 2012 at 8:12 PM, Robert Haas robertmh...@gmail.com wrote:
However exactly
the list turns out, there is no question that non-committers have been
quite successful in getting significant feature enhancements committed
in each of the last three releases, and I'm pretty confident
On 04/10/2012 09:14 PM, Robert Haas wrote:
I wouldn't object to creating some doc-only committers. OTOH, I would
object to anyone making non-trivial documentation enhancements without
posting their patches first and having a second person look it over,
so how much difference is there, really?
Greg Smith g...@2ndquadrant.com writes:
On 04/10/2012 09:14 PM, Robert Haas wrote:
I wouldn't object to creating some doc-only committers. OTOH, I would
object to anyone making non-trivial documentation enhancements without
posting their patches first and having a second person look it over,
On 11 April 2012 03:26, Tom Lane t...@sss.pgh.pa.us wrote:
[ scratches head... ] That's supposed to be total lines of code in our
source tree? What's the big drop in late 2009, then?
I had wondered about that myself - all I can tell you is that I used
the tool as advertised, without any
On Wed, Apr 11, 2012 at 16:24, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Smith g...@2ndquadrant.com writes:
On 04/10/2012 09:14 PM, Robert Haas wrote:
I wouldn't object to creating some doc-only committers. OTOH, I would
object to anyone making non-trivial documentation enhancements without
On 04/10/2012 08:43 PM, Greg Smith wrote:
On 04/10/2012 01:28 PM, Robert Haas wrote:
The fact is that we have no shortage of committers - there are 19
people who have access to push code into our master git repository. A
handful of those people have basically completely left the project and
Excerpts from Magnus Hagander's message of mié abr 11 11:35:10 -0300 2012:
For example, Thom (and others) could collect a number of typo fixes in
their own repo and then just ask for a merge.The advantage over just
staging multiple commits and then submitting a patch would be that
multiple
On Wed, Apr 11, 2012 at 10:35 AM, Magnus Hagander mag...@hagander.net wrote:
Since the topic is somewhat drifting here anyway.. :-)
Might it be worthwhile to allow some sort of staging repository and
actually start using the git stuff a bit more around this? E.g. we
could have a docs repo
Robert Haas robertmh...@gmail.com writes:
On Wed, Apr 11, 2012 at 10:35 AM, Magnus Hagander mag...@hagander.net wrote:
Might it be worthwhile to allow some sort of staging repository and
actually start using the git stuff a bit more around this?
... As far as I can see, this basically amounts
On Wed, Apr 11, 2012 at 11:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Apr 11, 2012 at 10:35 AM, Magnus Hagander mag...@hagander.net
wrote:
Might it be worthwhile to allow some sort of staging repository and
actually start using the git stuff a
Excerpts from Robert Haas's message of mié abr 11 12:44:02 -0300 2012:
Me neither, but I don't know how far it scales. Having certain people
who are defined as, say, doc-only committers will not only make it
clear to those people what they're expected to commit, but also clear
to everyone
All,
From my observation, the CF process ... in fact, all development processes
we've had in Postgres ... have suffered from only one problem: lack of
consensus on how the process should work. For example, we've *never* had
consensus around the criteria for kicking a patch out of a
On 11 April 2012 15:35, Magnus Hagander mag...@hagander.net wrote:
Might it be worthwhile to allow some sort of staging repository and
actually start using the git stuff a bit more around this? E.g. we
could have a docs repo somewhere where more people have commit bits,
and then they are just
Tom Lane t...@sss.pgh.pa.us wrote:
What I'd be interested to see is number of lines changed per unit
time; that would be a much better measure of patch rate IMHO.
Based on `git diff --shortstat` between tags, for the whole tree,
this is what shows up:
files
git tag
Robert Haas robertmh...@gmail.com writes:
On Wed, Apr 11, 2012 at 11:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
We've frequently had, and still have today, committers who are
understood to have limited areas of expertise and are given commit
bits on the honor system to not break what they don't
On Wed, Apr 11, 2012 at 8:59 AM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 11 April 2012 15:35, Magnus Hagander mag...@hagander.net wrote:
For example, Thom (and others) could collect a number of typo fixes in
their own repo and then just ask for a merge.The advantage over just
staging
On Wed, Apr 11, 2012 at 18:29, Josh Kupershmidt schmi...@gmail.com wrote:
On Wed, Apr 11, 2012 at 8:59 AM, Peter Geoghegan pe...@2ndquadrant.com
wrote:
On 11 April 2012 15:35, Magnus Hagander mag...@hagander.net wrote:
For example, Thom (and others) could collect a number of typo fixes in
Joshua Berkus j...@agliodbs.com writes:
From my observation, the CF process ... in fact, all development
processes we've had in Postgres ... have suffered from only one
problem: lack of consensus on how the process should work. For
example, we've *never* had consensus around the criteria for
On Wed, Apr 11, 2012 at 11:49 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mié abr 11 12:44:02 -0300 2012:
Me neither, but I don't know how far it scales. Having certain people
who are defined as, say, doc-only committers will not only make it
On ons, 2012-04-11 at 06:04 -0400, Greg Smith wrote:
Compare with:
-Submitter suggests doc change
-No one has a strong opinion on it, may not be picked up at all
-Submitter adds to the next CF
-Wait for review
-[Possible repost update with reviewer changes]
-Ready for committer
Ultimately, we're herding cats here. I don't think you're going to
get
the community to suddenly be willing to march in lockstep instead.
If you, Peter, Simon, Robert, Heikki, Magnus, Peter G., Greg, Bruce and Andrew
agreed on a calendar-driven, mostly unambiguous process and adhered to
On ons, 2012-04-11 at 12:48 -0400, Tom Lane wrote:
However, the real criteria don't matter as much as coming up with a
set of criteria we're all willing to obey, whatever they are.
Ultimately, we're herding cats here. I don't think you're going to
get the community to suddenly be willing
On Wed, Apr 11, 2012 at 1:39 PM, Joshua Berkus j...@agliodbs.com wrote:
Ultimately, we're herding cats here. I don't think you're going to
get
the community to suddenly be willing to march in lockstep instead.
If you, Peter, Simon, Robert, Heikki, Magnus, Peter G., Greg, Bruce and
Andrew
Peter Eisentraut pete...@gmx.net writes:
Just as a personal view, if people were to send me doc or trivial
patches in git-am format, with proper commit message, and Acked or
Signed-off etc. lines from recognized contributors, and proper
References: mail header linked to the discussion or
On ons, 2012-04-11 at 14:29 -0400, Tom Lane wrote:
I hear you ... but, given that the source material is a mailing-list
thread, *somebody* has to do all that work to produce an acceptable
commit. And if you're just going to commit what that somebody sends
you without further review, then you
On Wed, Apr 11, 2012 at 5:36 PM, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2012-04-11 at 14:29 -0400, Tom Lane wrote:
I hear you ... but, given that the source material is a mailing-list
thread, *somebody* has to do all that work to produce an acceptable
commit. And if you're just going
Robert Haas robertmh...@gmail.com writes:
On Wed, Apr 11, 2012 at 5:36 PM, Peter Eisentraut pete...@gmx.net wrote:
I'd still review it, but I'd be able to spend say 3 minutes on review
and 30 seconds on committing it, versus 3 minutes on review, 3 minutes
on research, and 8 minutes on
Christopher Browne cbbro...@gmail.com wrote:
Robert Haas robertmh...@gmail.com wrote:
CommitFests are a time for patches that are done or very nearly
done to get committed, and a time for other patches to get
reviewed if they haven't been already. If we make it clear that
the purpose of
On 6 April 2012 01:19, Noah Misch n...@leadboat.com wrote:
On Thu, Apr 05, 2012 at 02:34:30PM -0400, Robert Haas wrote:
On Thu, Apr 5, 2012 at 2:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The FK arrays one I'm kind of queasy about. ?It's a cool-sounding idea
but I'm not convinced that all the
On 10 April 2012 15:26, Kevin Grittner kevin.gritt...@wicourts.gov wrote:
A patch on which the author is continuing to work even in the absence of
review
should be considered a WIP want feedback submission; it should not
be allowed to constitute a placeholder for inclusion in the
release.
On Tue, Apr 10, 2012 at 11:24 AM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 10 April 2012 15:26, Kevin Grittner kevin.gritt...@wicourts.gov wrote:
A patch on which the author is continuing to work even in the absence of
review
should be considered a WIP want feedback submission; it
On 10 April 2012 16:51, Robert Haas robertmh...@gmail.com wrote:
When these things are pointed out to the people who are doing them,
the response is often either (a) this feature is so important we're
all going to die if it's not in the release how can you even think
about bouncing it or (b)
Kevin Grittner kevin.gritt...@wicourts.gov writes:
One other sort of mechanical test which I think can and should be
applied to patches submitted to the last CF is that if *at the start
of the CF* the patch doesn't apply, compile, pass regression tests,
and demonstrably provide the
Robert Haas robertmh...@gmail.com writes:
... It's surprisingly easy to hoodwink even
experienced contributors into thinking that your patch is really,
really almost done, honest, it just needs a couple more tweaks when in
fact it's nowhere close. I try not to attribute to bad faith what can
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
One other sort of mechanical test which I think can and should be
applied to patches submitted to the last CF is that if *at the
start of the CF* the patch doesn't apply, compile, pass
regression tests, and
On 04/09/2012 11:12 PM, Christopher Browne wrote:
It seems as though we need to have a bad guy that will say, that
sure isn't ready to COMMIT, so we'd better step back from imagining
that it ought to be completed as part of this COMMITfest.
There's no reward for anyone in the PostgreSQL
On Tue, Apr 10, 2012 at 12:28 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
I think that you may be missing the greater point here. The people
that do this are kind of like the defectors in prisoner's dilemma - at
a certain point, some people cannot resist the temptation to push
their own
On Tue, Apr 10, 2012 at 1:27 PM, Greg Smith g...@2ndquadrant.com wrote:
There's no reward for anyone in the PostgreSQL community to be a bad guy.
If you're too aggressive about it, submitters get mad; too loose, and you
get both committers and people worried about the release schedule mad.
On 10 April 2012 18:28, Robert Haas robertmh...@gmail.com wrote:
If we accept your argument that some
people simply cannot help themselves, then the only solution is to
make it cease to be a prisoner's dilemma, and that can only be done by
changing the incentives, which presumably means
Peter Geoghegan pe...@2ndquadrant.com writes:
On 10 April 2012 18:28, Robert Haas robertmh...@gmail.com wrote:
I don't agree with that. I think that there are a few people who
don't now have commit bits who should be given them - in particular,
Fujii Masao and Kevin Grittner, both of whom
On Tue, Apr 10, 2012 at 2:49 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
Well, I was really pointing out that people are somewhat forced into a
corner by the current state of affairs, because committers are not
typically able to look at anything in sufficient detail that isn't
ready for
On Mon, 2012-04-09 at 23:12 -0400, Christopher Browne wrote:
But there is also a flip side to that, namely that if we do so, there
ought to be some aspect to the process to help guide those items that
*aren't* particularly close to being committable.
I have benefited immensely from review of
On 04/10/2012 01:33 PM, Robert Haas wrote:
I also think that people were more receptive to my reviews before I
got a commit bit.
That's not true; many people were just as annoyed at you back then.
(Robert knows I'm kidding. I hope.)
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com
On Tue, Apr 10, 2012 at 11:53:23AM -0500, Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
One other sort of mechanical test which I think can and should be
applied to patches submitted to the last CF is that if *at the
start of
On 04/10/2012 01:28 PM, Robert Haas wrote:
The fact is that we have no shortage of committers - there are 19
people who have access to push code into our master git repository. A
handful of those people have basically completely left the project and
their commit rights should probably be
On Tue, Apr 10, 2012 at 8:43 PM, Greg Smith g...@2ndquadrant.com wrote:
To use a personal example I don't think is unique, I would set aside more
time to hack on the documentation if I didn't have to bug one of the
existing committers each time I wanted to work on something there. It really
On Tue, Apr 10, 2012 at 10:28 AM, Robert Haas robertmh...@gmail.com wrote:
It's feasible to think that we might be able to streamline the process
of booting patches that are not close to committable at the start of a
CommitFest, and especially at the start of the final CommitFest.
I'd usually
On Wednesday, April 11, 2012 03:14:41 AM Robert Haas wrote:
I'm somewhat oddly pleased at how the overflow of incoming submissions
for 9.2 has raised questions around not having enough active committers.
I hope decisions about adding more recognizes that distributing that
power really
Andres Freund and...@anarazel.de writes:
On Wednesday, April 11, 2012 03:14:41 AM Robert Haas wrote:
My perception of what's going on here is dramatically different from
yours. I don't think there was any overflow of submissions for 9.2.
For the most part I would describe it as a slow and
On 11 April 2012 02:14, Robert Haas robertmh...@gmail.com wrote:
My perception of what's going on here is dramatically different from
yours. I don't think there was any overflow of submissions for 9.2.
That is just not true. See the attached graph (couldn't produce one
with better resolution
1 - 100 of 161 matches
Mail list logo
