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 rid
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 br...@momjian.ushttp://momjian.us
EnterpriseDB
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
On Thu, May 12, 2011 at 11:55 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com 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
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
Kevin Barnard kevinbarn...@mac.com 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
Robert Haas robertmh...@gmail.com 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
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 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 until you've done
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
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
On Tue, May 10, 2011 at 6:54 PM, Josh Berkus j...@agliodbs.com 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
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
On Tue, May 10, 2011 at 3:09 PM, Greg Stark gsst...@mit.edu 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
Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
On Mon, May 9, 2011 at 10:58 AM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
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 casting
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
backwards
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
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 Mon, May 9, 2011 at 1:53 PM, Josh Berkus j...@agliodbs.com 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
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
On Mon, May 9, 2011 at 11:25 AM, Bruce Momjian br...@momjian.us 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
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 short
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
On Mon, May 9, 2011 at 2:41 PM, Josh Berkus j...@agliodbs.com 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
Robert Haas robertmh...@gmail.com writes:
On Mon, May 9, 2011 at 11:25 AM, Bruce Momjian br...@momjian.us 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
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, May 9, 2011 at 11:25 AM, Bruce Momjian br...@momjian.us 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
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
On Mon, May 9, 2011 at 7:18 PM, Robert Haas robertmh...@gmail.com 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,
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 they're
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
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
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,
-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
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 *much*
On Wed, Apr 20, 2011 at 8:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net 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
Peter Eisentraut pete...@gmx.net 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
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
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 the
On Thu, Apr 21, 2011 at 2:43 AM, Peter Eisentraut pete...@gmx.net 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
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 21, 2011 at 2:43 AM, Peter Eisentraut pete...@gmx.net 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
On 04/21/2011 11:16 AM, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
On Thu, Apr 21, 2011 at 2:43 AM, Peter Eisentrautpete...@gmx.net wrote:
I think to really address that problem, you need to think about shorter
release cycles overall, like every 6 months. Otherwise, the
On Thu, Apr 21, 2011 at 11:16:45AM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 21, 2011 at 2:43 AM, Peter Eisentraut pete...@gmx.net wrote:
I think to really address that problem, you need to think about shorter
release cycles overall, like every 6 months.
On Thu, Apr 21, 2011 at 11:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 21, 2011 at 2:43 AM, Peter Eisentraut pete...@gmx.net wrote:
I think to really address that problem, you need to think about shorter
release cycles overall, like every 6
On Thu, Apr 21, 2011 at 11:37 AM, Ross J. Reedstrom reeds...@rice.edu wrote:
On Thu, Apr 21, 2011 at 11:16:45AM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 21, 2011 at 2:43 AM, Peter Eisentraut pete...@gmx.net wrote:
I think to really address that problem,
[ another thought on this topic ]
Robert Haas robertmh...@gmail.com 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
On Thursday, April 21, 2011 05:43:16 PM Robert Haas wrote:
On Thu, Apr 21, 2011 at 11:37 AM, Ross J. Reedstrom reeds...@rice.edu
wrote:
On Thu, Apr 21, 2011 at 11:16:45AM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
I agree. I am in favor of a shorter release cycle.
On Thu, Apr 21, 2011 at 11:46 AM, Tom Lane t...@sss.pgh.pa.us 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
On Thu, Apr 21, 2011 at 11:48 AM, Andres Freund and...@anarazel.de 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 reeds...@rice.edu
wrote:
On Thu, Apr 21, 2011 at 11:16:45AM -0400, Tom Lane wrote:
Robert Haas
On Thu, Apr 21, 2011 at 11:48 AM, Andres Freund and...@anarazel.de 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
[ man, this thread has totally outlived its title, could we change that?
I'll start with this subtopic ]
Robert Haas robertmh...@gmail.com 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
On Thursday, April 21, 2011 06:39:44 PM Robert Haas wrote:
On Thu, Apr 21, 2011 at 11:48 AM, Andres Freund and...@anarazel.de 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 reeds...@rice.edu
wrote:
On Thu, Apr 21,
On Thu, Apr 21, 2011 at 5:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
[ man, this thread has totally outlived its title, could we change that?
I'll start with this subtopic ]
Robert Haas robertmh...@gmail.com writes:
In fact, I've been wondering if we shouldn't consider extending the
support
On Thu, Apr 21, 2011 at 11:05 AM, Robert Haas robertmh...@gmail.com 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
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
incremental
On Thu, Apr 21, 2011 at 06:04:09PM +0100, Dave Page wrote:
On Thu, Apr 21, 2011 at 5:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
[ man, this thread has totally outlived its title, could we change that?
?I'll start with this subtopic ]
Robert Haas robertmh...@gmail.com writes:
In fact,
On Thu, Apr 21, 2011 at 12:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
[ man, this thread has totally outlived its title, could we change that?
I'll start with this subtopic ]
Robert Haas robertmh...@gmail.com writes:
In fact, I've been wondering if we shouldn't consider extending the
support
Dave Page dp...@pgadmin.org writes:
On Thu, Apr 21, 2011 at 5:59 PM, Tom Lane t...@sss.pgh.pa.us 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
Josh Berkus j...@agliodbs.com 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
On Thu, Apr 21, 2011 at 12:35 PM, Tom Lane t...@sss.pgh.pa.us 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
On tor, 2011-04-21 at 13:39 -0400, Tom Lane wrote:
Josh Berkus j...@agliodbs.com 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
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
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
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
Alvaro Herrera alvhe...@commandprompt.com 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
On Wed, Apr 20, 2011 at 5:21 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Apr 20, 2011 at 12:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
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 enables.
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
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. Maybe
Peter Eisentraut pete...@gmx.net 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
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, people get
On Wed, Apr 20, 2011 at 2:39 PM, Josh Berkus j...@agliodbs.com 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
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 Experts
On Wed, Apr 20, 2011 at 2:53 PM, Andres Freund and...@anarazel.de 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
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 things have
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
On Wednesday, April 20, 2011 09:09:48 PM Robert Haas wrote:
On Wed, Apr 20, 2011 at 2:53 PM, Andres Freund and...@anarazel.de 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
On Wed, Apr 20, 2011 at 3:13 PM, Joshua D. Drake j...@commandprompt.com 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
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 long. Then
Robert Haas robertmh...@gmail.com writes:
On Wed, Apr 20, 2011 at 2:53 PM, Andres Freund and...@anarazel.de 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
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,
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,
then
On Wed, Apr 20, 2011 at 3:05 PM, Josh Berkus j...@agliodbs.com 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
Peter Eisentraut pete...@gmx.net 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
On Wed, Apr 20, 2011 at 21:54, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net 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
On 04/20/2011 04:09 PM, Magnus Hagander wrote:
On Wed, Apr 20, 2011 at 21:54, Tom Lanet...@sss.pgh.pa.us wrote:
Peter Eisentrautpete...@gmx.net 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
Andrew Dunstan and...@dunslane.net writes:
On 04/20/2011 04:09 PM, Magnus Hagander wrote:
On Wed, Apr 20, 2011 at 21:54, Tom Lanet...@sss.pgh.pa.us 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,
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
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
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
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 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 within
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 over
On Wed, Apr 20, 2011 at 3:42 PM, Josh Berkus j...@agliodbs.com 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.
On Wed, Apr 20, 2011 at 7:00 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
Josh Berkus j...@agliodbs.com 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
Greg Smith g...@2ndquadrant.com writes:
The last time I tried to do this a few years ago I failed miserably and
never came back. I know way more about building software now though,
and just got this to work for the first time.
BTW, another thing that should be in the try-try-again category
On 04/18/2011 12:48 AM, Greg Smith wrote:
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
directory is ugly and
1 - 100 of 138 matches
Mail list logo
