On Sun, Apr 15, 2012 at 8:23 AM, Simon Riggs wrote:
> On Sat, Apr 7, 2012 at 9:51 PM, Robert Haas 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 t
Jay Levitt 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
or xapian.
-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 em
Alex wrote:
Jay Levitt 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 been painfu
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 wort
Alvaro Herrera 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).
Same story here, still
On Sun, Apr 15, 2012 at 11:31 PM, Greg Smith 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 something usefu
Excerpts from Alex's message of dom abr 15 01:52:16 -0300 2012:
>
> Jay Levitt 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 sta
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 is
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 ju
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 Sun, Apr 15, 2012 at 4:50 PM, Tom Lane 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 who did not th
Simon Riggs 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 the large patches b
Simon Riggs 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 different. It was not
> cl
On Tue, Apr 10, 2012 at 3:26 PM, Kevin Grittner
wrote:
> Christopher Browne wrote:
>> Robert Haas 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
On Sat, Apr 7, 2012 at 9:51 PM, Robert Haas 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 LOT of patches to
On Sat, Apr 7, 2012 at 10:20 PM, Tom Lane wrote:
> Robert Haas 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 opinion, not much of a solution.
On Wed, Apr 11, 2012 at 6:59 PM, Robert Haas wrote:
> On Wed, Apr 11, 2012 at 1:39 PM, Joshua Berkus 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, He
On Fri, Apr 6, 2012 at 8:19 AM, Tom Lane wrote:
> Greg Smith 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 thing off as rejected with
On Sat, Apr 14, 2012 at 2:28 PM, Jay Levitt wrote:
> Christopher Browne wrote:
>>
>> On Thu, Apr 12, 2012 at 6:11 PM, Jay Levitt 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 relu
Jay Levitt 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 been painful.
On Tue, Apr 10, 2012 at 8:43 PM, 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 people w
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 depr
Christopher Browne wrote:
On Thu, Apr 12, 2012 at 6:11 PM, Jay Levitt 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 not
Alex writes:
> Greg Smith 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
Greg Smith 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 maybe it is time to
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 Baltimore,
Peter Eisentraut 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.
>
> Well,
On tor, 2012-04-12 at 18:19 -0400, Christopher Browne wrote:
> On Thu, Apr 12, 2012 at 6:11 PM, Jay Levitt 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 com
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 actu
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 cont
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 fo
Robert Haas 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 could have been avoide
Tom Lane writes:
> Andres Freund 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, that means they
> were not se
Robert Haas 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 process when it was
On Thu, Apr 12, 2012 at 6:11 PM, Jay Levitt 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.
The existence of git
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
*ple
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 work
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 in
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
> 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 wor
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 peop
-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 com
> 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 tool
On 04/11/2012 10:24 AM, Tom Lane wrote:
Greg Smith 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 not sound like a chang
On 12 April 2012 13:45, Bruce Momjian 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 our community p
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 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
On Thu, Apr 12, 2012 at 05:49, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Apr 11, 2012 at 5:36 PM, Peter Eisentraut 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, a
Robert Haas writes:
> On Wed, Apr 11, 2012 at 5:36 PM, Peter Eisentraut 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 bookkeeping.
> Well, I am not averse
On Wed, Apr 11, 2012 at 5:36 PM, Peter Eisentraut 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 to commi
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 y
Peter Eisentraut 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 "suggestion"
>
On Wed, Apr 11, 2012 at 1:39 PM, Joshua Berkus 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 agreed on
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 will
> 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 t
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
> -
On Wed, Apr 11, 2012 at 11:49 AM, Alvaro Herrera
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
>> clear to those people
Joshua Berkus 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 kicking
> a pa
On Wed, Apr 11, 2012 at 18:29, Josh Kupershmidt wrote:
> On Wed, Apr 11, 2012 at 8:59 AM, Peter Geoghegan
> wrote:
>> On 11 April 2012 15:35, Magnus Hagander 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
On Wed, Apr 11, 2012 at 8:59 AM, Peter Geoghegan wrote:
> On 11 April 2012 15:35, Magnus Hagander 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 multiple commits and then submitti
Robert Haas writes:
> On Wed, Apr 11, 2012 at 11:38 AM, Tom Lane 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 know well.
>> I don't have any p
Tom Lane 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 changed insertions
On 11 April 2012 15:35, Magnus Hagander 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 regularly me
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 commitf
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 everyon
On Wed, Apr 11, 2012 at 11:38 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Apr 11, 2012 at 10:35 AM, Magnus Hagander
>> 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 ca
Robert Haas writes:
> On Wed, Apr 11, 2012 at 10:35 AM, Magnus Hagander 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 to
> bundling lots of unrelated
On Wed, Apr 11, 2012 at 10:35 AM, Magnus Hagander 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" somewhere wher
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
> multipl
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
t
On Wed, Apr 11, 2012 at 16:24, Tom Lane wrote:
> Greg Smith 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 a
On 11 April 2012 03:26, Tom Lane 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 adornments. This parti
Greg Smith 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,
>> so how much
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?
On Tue, Apr 10, 2012 at 8:12 PM, Robert Haas 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 it goes
> back a lo
On Wednesday, April 11, 2012, Robert Haas wrote:
> On Tue, Apr 10, 2012 at 10:05 PM, Peter Geoghegan
> >
> wrote:
> > On 11 April 2012 02:14, 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 submi
On Tue, Apr 10, 2012 at 10:05 PM, Peter Geoghegan wrote:
> On 11 April 2012 02:14, 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.
>
> That is just not true. See the attached graph (
On Tue, Apr 10, 2012 at 9:32 PM, Andres Freund wrote:
> 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...
Yeah, I noticed. People other than committers can do design reviews,
of cour
Peter Geoghegan writes:
> That is just not true. See the attached graph (couldn't produce one
> with better resolution at short notice) - I've just eyeballed the
> graph, but it looks like an upward trend to me.
[ scratches head... ] That's supposed to be total lines of code in our
source tree?
On 11 April 2012 02:14, 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.
That is just not true. See the attached graph (couldn't produce one
with better resolution at short notice) - I'
Andres Freund 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 boring release
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 rea
On Tue, Apr 10, 2012 at 10:28 AM, Robert Haas 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 consider "booting
On Tue, Apr 10, 2012 at 8:43 PM, Greg Smith 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
> feels like I'm wast
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 revoked
On Tue, Apr 10, 2012 at 11:53:23AM -0500, Kevin Grittner wrote:
> Tom Lane wrote:
> > "Kevin Grittner" 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,
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 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 Tue, Apr 10, 2012 at 2:49 PM, Peter Geoghegan 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 committer", partic
Peter Geoghegan writes:
> On 10 April 2012 18:28, Robert Haas 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 have been doing
>> consistently excelle
On 10 April 2012 18:28, Robert Haas 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 handing down
> punishmen
On Tue, Apr 10, 2012 at 1:27 PM, Greg Smith 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. And
> the community
On Tue, Apr 10, 2012 at 12:28 PM, Peter Geoghegan 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 patch forward at th
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 co
Tom Lane wrote:
> "Kevin Grittner" 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 functional
Robert Haas 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
> be explained by
"Kevin Grittner" 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 functionality claimed for the pat
On 10 April 2012 16:51, Robert Haas 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) I'm not really stil
On Tue, Apr 10, 2012 at 11:24 AM, Peter Geoghegan wrote:
> On 10 April 2012 15:26, Kevin Grittner 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 "pl
1 - 100 of 161 matches
Mail list logo
