Andrew Dunstan wrote:
> Now we could certainly make this quite a bit slicker. Apart from
> anything else, we should change the indent source code tarball so it
> unpacks into its own directory. Having it unpack into the current
Yes, done.
> directory is ugly and unfriendly. And we should get r
Andrew Dunstan wrote:
> Attached are two patches, one to remove some infelicity in the entab
> makefile, and the other to allow skipping specifying the typedefs file
I have applied the 'entab' Makefile fix.
--
Bruce Momjian http://momjian.us
EnterpriseDB
Kevin Barnard wrote:
> A ticketing system with work flow could help with transparency.
> If it's setup correctly the work flow could help document where
> the item is in the review process. As another idea maybe have a
> status to indicate that the patch has been reviewed for
> formatting. It
On May 9, 2011, at 12:53 PM, Josh Berkus wrote:
>
> 2) Our process for reviewing and approving patches, and what criteria
> such patches are required to meet, is *very* opaque to a first-time
> submitter (as in no documentation the submitter knows about), and does
> not become clearer as they go t
On Thu, May 12, 2011 at 11:55 AM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> Unfortunately, people often come into our community with incorrect
>> assumptions about how it works, including:
>>
>> - someone's in charge
>> - there's one right answer
>> - it's our job to fix your problem
>
> Wo
Heikki Linnakangas writes:
>> Anyway, I think the intro message should be "Don't submit a big patch to
>> PostgreSQL until you've done a small patch and some patch review"
>> instead though.
>
> Well, my first patch was two-phase commit. And I had never even used
> PostgreSQL before I dived into t
Robert Haas wrote:
> Unfortunately, people often come into our community with incorrect
> assumptions about how it works, including:
>
> - someone's in charge
> - there's one right answer
> - it's our job to fix your problem
Would it make sense to dispel such notions explicitly in the
Develop
On Tue, May 10, 2011 at 3:09 PM, Greg Stark wrote:
> The thing is, I think things are much better now than they were three
> or four years ago. At the time the project had grown much faster than
> the existing stable of developers and the rate at which patches were
> being submitted was much great
> The thing is, I think things are much better now than they were three
> or four years ago.
Oh, no question.
If you read above in this thread, I'm not really proposing a change in
the current process, just documenting the current process. Right now
there's a gap between how sumbitters expect t
On Tue, May 10, 2011 at 6:54 PM, Josh Berkus wrote:
> Of course, there are always idiots who won't learn anything no matter
> how good our process is. But if the whole submission process is
> perceived to be fair and understandible, those will be a tiny minority.
The thing is, I think things are
All,
> Part of the trouble is in the question. Having a patch rejected is not
> really a problem; it's something you should learn from. I know it can be
> annoying. I get annoyed when it happens to me too. But I try to get over
> it as quickly as possible, and either fix the patch, or find another
Heikki Linnakangas wrote:
Well, my first patch was two-phase commit. And I had never even used
PostgreSQL before I dived into the source tree and started to work on that
Well, everyone knows you're awesome. A small percentage of the people
who write patches end up having the combination of ba
On Tue, May 10, 2011 at 1:46 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> On 10.05.2011 04:43, Greg Smith wrote:
>
>> Josh Berkus wrote:
>>
>>> As I don't think we can change this, I think the best answer is to
>>> tell people
>>> "Don't submit a big patch to PostgreSQL u
On 10.05.2011 04:43, Greg Smith wrote:
Josh Berkus wrote:
As I don't think we can change this, I think the best answer is to
tell people
"Don't submit a big patch to PostgreSQL until you've done a few small
patches first. You'll regret it".
When I last did a talk about getting started writing
On 05/09/2011 09:43 PM, Greg Smith wrote:
When I last did a talk about getting started writing patches, I had a
few people ask me afterwards if I'd ever run into problems with having
patch submissions rejected. I said I hadn't.
Part of the trouble is in the question. Having a patch reject
Josh Berkus wrote:
As I don't think we can change this, I think the best answer is to tell people
"Don't submit a big patch to PostgreSQL until you've done a few small
patches first. You'll regret it".
When I last did a talk about getting started writing patches, I had a
few people ask me
Excerpts from Greg Stark's message of lun may 09 19:44:15 -0400 2011:
> Honestly it's not even that clear. It took me years to realize that
> when Tom says "There's problems x, y, z" he doesn't mean "give up now
> there are all these fatal flaws" but rather "think about these things
> and maybe th
On Mon, May 9, 2011 at 7:18 PM, Robert Haas wrote:
> Ah ha! Now we're getting somewhere. As was doubtless obvious from my
> previous responses, I don't agree that the process is as broken as I
> felt you were suggesting, and I think we've made a lot of
> improvements. However, I am in complete
On 05/09/2011 11:43 AM, Robert Haas wrote:
Interesting. You could argue that once 8.3 is our earliest supported
release that we could even shrink the support window because the
argument "I can't dump/reload my data" would be gone.
Personally, I think the support window is on the borderline of
Tom Lane wrote:
> Robert Haas writes:
> > On Mon, May 9, 2011 at 11:25 AM, Bruce Momjian wrote:
> >> Interesting. ?You could argue that once 8.3 is our earliest supported
> >> release that we could even shrink the support window because the
> >> argument "I can't dump/reload my data" would be gon
Robert Haas writes:
> On Mon, May 9, 2011 at 11:25 AM, Bruce Momjian wrote:
>> Interesting. You could argue that once 8.3 is our earliest supported
>> release that we could even shrink the support window because the
>> argument "I can't dump/reload my data" would be gone.
> Personally, I think
On Mon, May 9, 2011 at 2:41 PM, Josh Berkus wrote:
> Robert,
>
>> I can't disagree with this, either. I'm not sure where it would be
>> possible for us to document this that people would actually see and
>> read, and I think it's a tough to understand just from reading a wiki
>> page or a blog po
Greg Smith wrote:
> [There were complaints upthread about things like how Aster's patch
> submissions were treated. Those were WIP patches that half implemented
> some useful ideas. But they were presented as completed features, and
> they seemed to expect the community would pick those up and
Robert Haas wrote:
> > Interesting. ?You could argue that once 8.3 is our earliest supported
> > release that we could even shrink the support window because the
> > argument "I can't dump/reload my data" would be gone.
>
> Personally, I think the support window is on the borderline of being
> too
On Mon, May 9, 2011 at 11:25 AM, Bruce Momjian wrote:
> Greg Smith wrote:
>> On 04/21/2011 12:39 PM, Robert Haas wrote:
>> > In fact, I've been wondering if we shouldn't consider extending the
>> > support window for 8.2 past the currently-planned December 2011.
>> > There seem to be quite a lot o
Robert,
> I can't disagree with this, either. I'm not sure where it would be
> possible for us to document this that people would actually see and
> read, and I think it's a tough to understand just from reading a wiki
> page or a blog post:
Still, if we had a wiki page which was a really compre
On Mon, May 9, 2011 at 1:53 PM, Josh Berkus wrote:
> While the first was specific to the Aster submissions, I've seen the
> second problem with lots of first-time submissions to this list. Our
> feedback to submitters of big patches requires a lot of comprehension of
> project personalities and p
Greg,
>> [There were complaints upthread about things like how Aster's patch
>> submissions were treated. Those were WIP patches that half implemented
>> some useful ideas.
There are two reasons why I think we failed with the Aster patches:
1) I passed Aster along to Bruce, who said he would
On 05/09/2011 12:06 PM, Andrew Dunstan wrote:
The fact that we can do in place upgrades of the data only addresses
one pain point in upgrading. Large legacy apps require large retesting
efforts when upgrading, often followed by lots more work renovating
the code for backwards incompatibilities.
All,
> I agree that we should not reduce the support window. The fact that we
> can do in place upgrades of the data only addresses one pain point in
> upgrading. Large legacy apps require large retesting efforts when
> upgrading, often followed by lots more work renovating the code for
> backward
Greg Smith wrote:
> On 04/21/2011 12:39 PM, Robert Haas wrote:
> > In fact, I've been wondering if we shouldn't consider extending the
> > support window for 8.2 past the currently-planned December 2011.
> > There seem to be quite a lot of people running that release precisely
> > because the casti
On Mon, May 9, 2011 at 10:58 AM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Robert Haas writes:
>> > ... Maybe someone out there is under the impression
>> > that I get high off of rejecting patches; but the statistics you cite
>> > from the CF app don't exactly support the contention that I'm goi
Tom Lane wrote:
> Robert Haas writes:
> > ... Maybe someone out there is under the impression
> > that I get high off of rejecting patches; but the statistics you cite
> > from the CF app don't exactly support the contention that I'm going
> > around looking for reasons to reject things, or if I a
Andrew Dunstan wrote:
Personally, I want pgindent installed in /usr/local/ or similar. That
way I can have multiple trees and it will work in all of them without
my having to build it for each. What I don't want is for the installed
patched BSD indent to conflict with the system's indent, which
On the big picture of scheduling issues, I have never seen a major piece
of software ship every 6 months without being incredibly buggy. I'd
lose serious faith in this project if that happens here. Since I've
never seen a major operating system ship usefully more than about once
every two yea
On 04/21/2011 12:39 PM, Robert Haas wrote:
In fact, I've been wondering if we shouldn't consider extending the
support window for 8.2 past the currently-planned December 2011.
There seem to be quite a lot of people running that release precisely
because the casting changes in 8.3 were so painful,
On tor, 2011-04-21 at 13:39 -0400, Tom Lane wrote:
> Josh Berkus writes:
> > Better that someone should just focus on whipping Robert's (or was it
> > Greg's?) replace-the-missing-casts package into shape as an extension.
>
> I think Peter originated that, actually. My recollection is that there
On Thu, Apr 21, 2011 at 12:35 PM, Tom Lane wrote:
>
> But I'm still unclear on what would really be accomplished
> by extending support for it. Sooner or later we have to get people
> to migrate up from it, and I see no reason to think that supporting
> it for just a year more will change anythin
Josh Berkus writes:
> Better that someone should just focus on whipping Robert's (or was it
> Greg's?) replace-the-missing-casts package into shape as an extension.
I think Peter originated that, actually. My recollection is that there
didn't seem to be any way to extend it to a complete solutio
Dave Page writes:
> On Thu, Apr 21, 2011 at 5:59 PM, Tom Lane wrote:
>> I agree that the incremental effort would not be so large, but what
>> makes you think that the situation will change given another year?
> It would also make at least one packager very unhappy as the 8.2
> Windows build is
On Thu, Apr 21, 2011 at 12:59 PM, Tom Lane wrote:
> [ man, this thread has totally outlived its title, could we change that?
> I'll start with this subtopic ]
>
> Robert Haas writes:
>> In fact, I've been wondering if we shouldn't consider extending the
>> support window for 8.2 past the current
On Thu, Apr 21, 2011 at 06:04:09PM +0100, Dave Page wrote:
> On Thu, Apr 21, 2011 at 5:59 PM, Tom Lane wrote:
> > [ man, this thread has totally outlived its title, could we change that?
> > ?I'll start with this subtopic ]
> >
> > Robert Haas writes:
> >> In fact, I've been wondering if we shoul
All,
>>> In fact, I've been wondering if we shouldn't consider extending the
>>> support window for 8.2 past the currently-planned December 2011.
>>> There seem to be quite a lot of people running that release precisely
>>> because the casting changes in 8.3 were so painful, and I think the
>>> in
On Thu, Apr 21, 2011 at 11:05 AM, Robert Haas wrote:
> I agree. I am in favor of a shorter release cycle. But I think that
> a shorter release cycle won't work well if there is still four month
> long integration period at the end of each series of CommitFests. The
> problem is a bit circular h
On Thu, Apr 21, 2011 at 5:59 PM, Tom Lane wrote:
> [ man, this thread has totally outlived its title, could we change that?
> I'll start with this subtopic ]
>
> Robert Haas writes:
>> In fact, I've been wondering if we shouldn't consider extending the
>> support window for 8.2 past the currentl
On Thursday, April 21, 2011 06:39:44 PM Robert Haas wrote:
> On Thu, Apr 21, 2011 at 11:48 AM, Andres Freund wrote:
> > On Thursday, April 21, 2011 05:43:16 PM Robert Haas wrote:
> >> On Thu, Apr 21, 2011 at 11:37 AM, Ross J. Reedstrom
> >
> > wrote:
> >> > On Thu, Apr 21, 2011 at 11:16:45AM -04
[ man, this thread has totally outlived its title, could we change that?
I'll start with this subtopic ]
Robert Haas writes:
> In fact, I've been wondering if we shouldn't consider extending the
> support window for 8.2 past the currently-planned December 2011.
> There seem to be quite a lot of
On Thu, Apr 21, 2011 at 11:48 AM, Andres Freund wrote:
> One could argue that its causing bad PR for postgres. I have seen several
> parties planning to migrate away or not migrate to postgres because of
> performance evaluations they made. With 7.4, 8.0 and 8.2. In 2010.
Well evaluating based on
On Thu, Apr 21, 2011 at 11:48 AM, Andres Freund wrote:
> On Thursday, April 21, 2011 05:43:16 PM Robert Haas wrote:
>> On Thu, Apr 21, 2011 at 11:37 AM, Ross J. Reedstrom
> wrote:
>> > On Thu, Apr 21, 2011 at 11:16:45AM -0400, Tom Lane wrote:
>> >> Robert Haas writes:
>> >> > I agree. I am in f
On Thu, Apr 21, 2011 at 11:46 AM, Tom Lane wrote:
> But aren't those two sides of the same coin, ie, people's natural
> tendency to work to a deadline? If you approve of a lot of patches
> showing up just in time for a commitfest, why don't you approve of
> big patches showing up just in time for
On Thursday, April 21, 2011 05:43:16 PM Robert Haas wrote:
> On Thu, Apr 21, 2011 at 11:37 AM, Ross J. Reedstrom
wrote:
> > On Thu, Apr 21, 2011 at 11:16:45AM -0400, Tom Lane wrote:
> >> Robert Haas writes:
> >> > I agree. I am in favor of a shorter release cycle.
> >> I'm not. I don't think t
[ another thought on this topic ]
Robert Haas writes:
> I think that it's not too bad if the process of a release getting out
> the door results in effectively missing one CommitFest. ...
> But that isn't going to work if people do
> the same sort of throwing everything into the kitchen sink at t
On Thu, Apr 21, 2011 at 11:37 AM, Ross J. Reedstrom wrote:
> On Thu, Apr 21, 2011 at 11:16:45AM -0400, Tom Lane wrote:
>> Robert Haas writes:
>> > On Thu, Apr 21, 2011 at 2:43 AM, Peter Eisentraut wrote:
>> >> I think to really address that problem, you need to think about shorter
>> >> release
On Thu, Apr 21, 2011 at 11:16 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Apr 21, 2011 at 2:43 AM, Peter Eisentraut wrote:
>>> I think to really address that problem, you need to think about shorter
>>> release cycles overall, like every 6 months. Otherwise, the current 12
>>> to 14 mo
On Thu, Apr 21, 2011 at 11:16:45AM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Apr 21, 2011 at 2:43 AM, Peter Eisentraut wrote:
> >> I think to really address that problem, you need to think about shorter
> >> release cycles overall, like every 6 months. �Otherwise, the current 12
>
On 04/21/2011 11:16 AM, Tom Lane wrote:
Robert Haas writes:
On Thu, Apr 21, 2011 at 2:43 AM, Peter Eisentraut wrote:
I think to really address that problem, you need to think about shorter
release cycles overall, like every 6 months. Otherwise, the current 12
to 14 month horizon is just to
Robert Haas writes:
> On Thu, Apr 21, 2011 at 2:43 AM, Peter Eisentraut wrote:
>> I think to really address that problem, you need to think about shorter
>> release cycles overall, like every 6 months. Otherwise, the current 12
>> to 14 month horizon is just too long psychologically.
> I agree.
On Thu, Apr 21, 2011 at 2:43 AM, Peter Eisentraut wrote:
> On Wed, 2011-04-20 at 21:09 -0400, Robert Haas wrote:
>> But
>> even then I think we'd have this problem of people being unwilling to
>> give up on jamming stuff into a release, regardless of the scheduling
>> impact of doing so. I actual
On Thu, 2011-04-21 at 08:42 -0500, Kevin Grittner wrote:
> > you need to think about shorter release cycles overall, like every
> > 6 months.
>
> With the current time between feature freeze and release, that
> wouldn't leave a lot of time for development.
Presumably, one would aim to cut all th
On Thu, 2011-04-21 at 14:01 +0100, Simon Riggs wrote:
> We should be encouraging people to spend more time on more useful
> features, not an endless stream of trivial patches, integration and
> release processes.
Hence the proposal to cut that time down and make it count better.
Which direction w
Peter Eisentraut wrote:
> you need to think about shorter release cycles overall, like every
> 6 months.
With the current time between feature freeze and release, that
wouldn't leave a lot of time for development.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Wed, Apr 20, 2011 at 8:54 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> I would imagine one commit fest per month, but
>> it's only a week long.
>
> BTW, just as a thought experiment: what about a one-day CF once a week?
> "Patch Tuesdays", if you will. Spend all day reviewing/committing,
On Wed, 2011-04-20 at 21:09 -0400, Robert Haas wrote:
> But
> even then I think we'd have this problem of people being unwilling to
> give up on jamming stuff into a release, regardless of the scheduling
> impact of doing so. I actually think the problem of getting releases
> out on time is a *muc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Apr 20, 2011 at 11:39:47AM -0700, Josh Berkus wrote:
[...]
> Review of design concepts and WIP patches has *always* been a problem
> for this project [...]
> We tell people to submit a design concept, but then such submissions are
> often ig
On Wed, Apr 20, 2011 at 7:00 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mié abr 20 16:22:24 -0300 2011:
>
>> > If people PERCEIVE there is a problem, THERE IS A PROBLEM.
>>
>> Absolutely. And I am perfectly well aware that we have screwed this
>> up from time to time. But
On Wed, Apr 20, 2011 at 3:42 PM, Josh Berkus wrote:
> On 4/20/11 12:35 PM, Tom Lane wrote:
>> Well, no, that's not the whole story. To me, what the above idea
>> implies is shifting more of the burden of fixing up patches away from
>> the committer and back to the patch author. Instead of spendi
Excerpts from Robert Haas's message of mié abr 20 16:22:24 -0300 2011:
> > If people PERCEIVE there is a problem, THERE IS A PROBLEM.
>
> Absolutely. And I am perfectly well aware that we have screwed this
> up from time to time. But I also know that I have spent a very large
> amount of time o
On Wed, 2011-04-20 at 16:25 -0400, Tom Lane wrote:
> But ignoring scheduling difficulties, my point here is that
> it seems like the shorter the cycle, the better, for a lot of
> purposes. Can we do any better than once-a-month, or is that the
> limit given that people need flexible schedules with
On 04/20/2011 12:22 PM, Robert Haas wrote:
Well, you aren't fighting alone. We have significant problems in this area.
As you said, we always have. There is also a bizarre, almost insane
objection to using tools that "aren't invented here" to solve problems. The
problems you (Josh) present are
On Wed, 2011-04-20 at 15:09 -0400, Robert Haas wrote:
> This would amount to reducing the amount of time we spend
> in-CommitFest from 50% to slightly less than 25%. That would
> certainly be pleasant from my point of view, but for the average patch
> to get the same amount of attention, we'd need
Tom,
> True, and any fixed day of the week would let out X number of people
> anyway. But ignoring scheduling difficulties, my point here is that
> it seems like the shorter the cycle, the better, for a lot of purposes.
> Can we do any better than once-a-month, or is that the limit given that
> p
On Wed, 2011-04-20 at 11:39 -0700, Josh Berkus wrote:
> Maybe we don't want to use ReviewBoard specifically. Maybe we want
> to use bugzilla or Crucible or Redmine something more specific for
> patch/spec review. But I think it's time to try something else, maybe
> several other things.
I had s
Andrew Dunstan writes:
> On 04/20/2011 04:09 PM, Magnus Hagander wrote:
>> On Wed, Apr 20, 2011 at 21:54, Tom Lane wrote:
>>> BTW, just as a thought experiment: what about a one-day CF once a week?
>>> "Patch Tuesdays", if you will. Spend all day reviewing/committing,
>>> bounce back whatever is
On 04/20/2011 04:09 PM, Magnus Hagander wrote:
On Wed, Apr 20, 2011 at 21:54, Tom Lane wrote:
Peter Eisentraut writes:
I would imagine one commit fest per month, but
it's only a week long.
BTW, just as a thought experiment: what about a one-day CF once a week?
"Patch Tuesdays", if you will
On Wed, Apr 20, 2011 at 21:54, Tom Lane wrote:
> Peter Eisentraut writes:
>> I would imagine one commit fest per month, but
>> it's only a week long.
>
> BTW, just as a thought experiment: what about a one-day CF once a week?
> "Patch Tuesdays", if you will. Spend all day reviewing/committing,
>
Peter Eisentraut writes:
> I would imagine one commit fest per month, but
> it's only a week long.
BTW, just as a thought experiment: what about a one-day CF once a week?
"Patch Tuesdays", if you will. Spend all day reviewing/committing,
bounce back whatever is not ready, patch authors try again
On Wed, Apr 20, 2011 at 3:05 PM, Josh Berkus wrote:
> On 4/20/11 12:00 PM, Robert Haas wrote:
>> Please provide the evidence that this is a problem that exists now, as
>> opposed to seven years ago.
>
> Since you're clearly already made up your mind that no problem exists, I
> don't have the energ
Robert,
> Absolutely. And I am perfectly well aware that we have screwed this
> up from time to time. But I also know that I have spent a very large
> amount of time over the last few years trying to improve things. It
> would be nice to know whether that has had any impact. If it hasn't,
> th
On 4/20/11 12:35 PM, Tom Lane wrote:
> Well, no, that's not the whole story. To me, what the above idea
> implies is shifting more of the burden of fixing up patches away from
> the committer and back to the patch author. Instead of spending time
> fixing up not-quite-ready patches myself, I'd be
Robert Haas writes:
> On Wed, Apr 20, 2011 at 2:53 PM, Andres Freund wrote:
>> On Wednesday, April 20, 2011 08:50:04 PM Tom Lane wrote:
>>> Yeah, maybe. To do that, we'd have to strongly resist the temptation to
>>> spend a lot of time fixing up submitted patches --- if it's not pretty
>>> darn
On Wednesday, April 20, 2011 08:53:34 PM Andres Freund wrote:
> On Wednesday, April 20, 2011 08:50:04 PM Tom Lane wrote:
> > > I think we should put less temporal emphasis on the finishing part, but
> > > use the time better. I would imagine one commit fest per month, but
> > > it's only a week lo
On Wed, Apr 20, 2011 at 3:13 PM, Joshua D. Drake wrote:
> On 04/20/2011 12:05 PM, Josh Berkus wrote:
>>
>> On 4/20/11 12:00 PM, Robert Haas wrote:
>>>
>>> Please provide the evidence that this is a problem that exists now, as
>>> opposed to seven years ago.
>>
>> Since you're clearly already made
On Wednesday, April 20, 2011 09:09:48 PM Robert Haas wrote:
> On Wed, Apr 20, 2011 at 2:53 PM, Andres Freund wrote:
> > On Wednesday, April 20, 2011 08:50:04 PM Tom Lane wrote:
> >> Yeah, maybe. To do that, we'd have to strongly resist the temptation to
> >> spend a lot of time fixing up submitte
On 04/20/2011 12:05 PM, Josh Berkus wrote:
On 4/20/11 12:00 PM, Robert Haas wrote:
Please provide the evidence that this is a problem that exists now, as
opposed to seven years ago.
Since you're clearly already made up your mind that no problem exists, I
don't have the energy to fight it out wi
On Wednesday, April 20, 2011 08:39:47 PM Josh Berkus wrote:
> Robert,
>
> > Unfortunately, my memory of this project only goes back to about
> > September 2008, which isn't far enough to remember why CommitFests
> > were created in the first place. So Alvaro may be correct in saying
> > that thin
On Wed, Apr 20, 2011 at 2:53 PM, Andres Freund wrote:
> On Wednesday, April 20, 2011 08:50:04 PM Tom Lane wrote:
>> > I think we should put less temporal emphasis on the finishing part, but
>> > use the time better. I would imagine one commit fest per month, but
>> > it's only a week long. Then
On 4/20/11 12:00 PM, Robert Haas wrote:
> Please provide the evidence that this is a problem that exists now, as
> opposed to seven years ago.
Since you're clearly already made up your mind that no problem exists, I
don't have the energy to fight it out with you.
--
Josh Berkus
PostgreSQL Expert
On Wed, Apr 20, 2011 at 2:39 PM, Josh Berkus wrote:
> Review of design concepts and WIP patches has *always* been a problem
> for this project. Andrew Sullivan bitched about it at some length back
> in 2004 ("Why there is no traffic on pgsql-replicationhooks", but
> Andrew's blog is down now unfo
On Wednesday, April 20, 2011 08:50:04 PM Tom Lane wrote:
> > I think we should put less temporal emphasis on the finishing part, but
> > use the time better. I would imagine one commit fest per month, but
> > it's only a week long. Then everyone can really concentrate on the
> > commit fest, peop
Peter Eisentraut writes:
> I think we should put less temporal emphasis on the finishing part, but
> use the time better. I would imagine one commit fest per month, but
> it's only a week long. Then everyone can really concentrate on the
> commit fest, people get faster feedback, but there is ul
Robert,
> Unfortunately, my memory of this project only goes back to about
> September 2008, which isn't far enough to remember why CommitFests
> were created in the first place. So Alvaro may be correct in saying
> that things have mutated over time, but that isn't necessarily a bad
> thing. Ma
On Wed, 2011-04-20 at 12:21 -0400, Tom Lane wrote:
> Well, I absolutely think that we need to encourage people to get
> feedback at the design and prototype stages. The problem with the
> commitfest mechanism for that is that when you are trying to work out
> a patch, you don't want to wait around
On Wed, 2011-04-20 at 17:52 +0100, Greg Stark wrote:
> I admit though this whole concept of "finished patches" seems foreign
> to me. I always have additional stuff I want to do and if the patch
> sits on the shelf I'm essentially stuck unable to work on the next
> great thing that that patch enabl
On Wed, Apr 20, 2011 at 12:21 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> I think this is historical revisionism. ...
>> Somewhere down the line this seems to have been forgotten and we are now
>> using commitfests just to track finished patches.
>
>> So if we want to stick to the original pr
On Wed, Apr 20, 2011 at 5:21 PM, Tom Lane wrote:
> Well, I absolutely think that we need to encourage people to get
> feedback at the design and prototype stages. The problem with the
> commitfest mechanism for that is that when you are trying to work out a
> patch, you don't want to wait around
Alvaro Herrera writes:
> I think this is historical revisionism. ...
> Somewhere down the line this seems to have been forgotten and we are now
> using commitfests just to track finished patches.
> So if we want to stick to the original principles we should have some
> sort of "different set of r
Excerpts from Tom Lane's message of mar abr 19 03:34:34 -0300 2011:
> As Robert noted, the purpose of the commitfest mechanism is mostly to
> ensure that patches that *are* committable, or close to it, don't fall
> through the cracks. I'm not sure we're doing anybody any favors by
> trying to sho
Josh Berkus writes:
> I received a private offlist email from someone who didn't feel
> comfortable bringing up their issues with this list publicly. Let me
> quote from it, because I think it pins part of the issue:
> "I believe this is due to the current postgresql "commitfest" process
> where
On Mon, Apr 18, 2011 at 11:50 PM, Christopher Browne wrote:
> 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.
On Mon, Apr 18, 2011 at 11:15 PM, Alex Hunsaker wrote:
> On Mon, Apr 18, 2011 at 19:50, Josh Berkus 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
1 - 100 of 138 matches
Mail list logo
