primary key error message
Here is a small patch that changes the error message
duplicate key value violates unique constraint "%s"
into
duplicate key value violates primary key "%s"
when the constraint is in fact a primary key.
Comments?
PS: Yes, this would need a handful of regression test updates if
accepted.
Attachments:
pk-errmsg.patchtext/x-patch; charset=UTF-8; name=pk-errmsg.patchDownload
Index: src/backend/access/nbtree/nbtinsert.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/access/nbtree/nbtinsert.c,v
retrieving revision 1.176
diff -u -3 -p -r1.176 nbtinsert.c
--- src/backend/access/nbtree/nbtinsert.c 2 Jan 2010 16:57:35 -0000 1.176
+++ src/backend/access/nbtree/nbtinsert.c 20 Jan 2010 22:56:55 -0000
@@ -381,8 +381,11 @@ _bt_check_unique(Relation rel, IndexTupl
values, isnull);
ereport(ERROR,
(errcode(ERRCODE_UNIQUE_VIOLATION),
- errmsg("duplicate key value violates unique constraint \"%s\"",
- RelationGetRelationName(rel)),
+ (rel->rd_index->indisprimary
+ ? errmsg("duplicate key value violates primary key \"%s\"",
+ RelationGetRelationName(rel))
+ : errmsg("duplicate key value violates unique constraint \"%s\"",
+ RelationGetRelationName(rel))),
errdetail("Key %s already exists.",
BuildIndexValueDescription(rel,
values, isnull))));
On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
Here is a small patch that changes the error message
duplicate key value violates unique constraint "%s"
into
duplicate key value violates primary key "%s"
when the constraint is in fact a primary key.
Comments?
Why bother? And why bother now, when we're in the middle of the last
CommitFest and trying to move toward a release?
...Robert
Robert Haas <robertmhaas@gmail.com> writes:
On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
Here is a small patch that changes the error message
� �duplicate key value violates unique constraint "%s"
into
� �duplicate key value violates primary key "%s"
when the constraint is in fact a primary key.
Comments?
Why bother? And why bother now, when we're in the middle of the last
CommitFest and trying to move toward a release?
This patch fails to cover all cases (index build being the obvious
omission, but I think there might be other paths as well where the
information is not so readily available). And I agree with Robert
that the usefulness is at best highly debatable.
regards, tom lane
On tor, 2010-01-21 at 15:51 -0500, Tom Lane wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
Here is a small patch that changes the error message
duplicate key value violates unique constraint "%s"
into
duplicate key value violates primary key "%s"
when the constraint is in fact a primary key.
Comments?
Why bother? And why bother now, when we're in the middle of the last
CommitFest and trying to move toward a release?This patch fails to cover all cases (index build being the obvious
omission, but I think there might be other paths as well where the
information is not so readily available).
This is the user-visible error message, and that's the only place it's
generated.
And I agree with Robert that the usefulness is at best highly debatable.
The usefulness is that they are different kinds of objects that are
defined and listed in different ways and it would be slightly helpful if
the error message pointed in the righter direction.
On tor, 2010-01-21 at 15:47 -0500, Robert Haas wrote:
On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
Here is a small patch that changes the error message
duplicate key value violates unique constraint "%s"
into
duplicate key value violates primary key "%s"
when the constraint is in fact a primary key.
Comments?
Why bother?
Because unique constraints and primary keys are different things and it
would be slightly less confusing that way.
And why bother now, when we're in the middle of the last
CommitFest and trying to move toward a release?
Are you saying we can't discuss anything new during the commit fest?
Peter Eisentraut <peter_e@gmx.net> writes:
On tor, 2010-01-21 at 15:51 -0500, Tom Lane wrote:
This patch fails to cover all cases (index build being the obvious
omission, but I think there might be other paths as well where the
information is not so readily available).
This is the user-visible error message, and that's the only place it's
generated.
Hardly ...
regression=# create table foo (f1 int);
CREATE TABLE
regression=# insert into foo values(1),(1);
INSERT 0 2
regression=# alter table foo add primary key (f1);
NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "foo_pkey" for table "foo"
ERROR: could not create unique index "foo_pkey"
DETAIL: Key (f1)=(1) is duplicated.
And I agree with Robert that the usefulness is at best highly debatable.
The usefulness is that they are different kinds of objects that are
defined and listed in different ways and it would be slightly helpful if
the error message pointed in the righter direction.
It is not incorrect to refer to a primary key as a unique constraint.
Will you next be wanting the error messages about null values to
distinguish whether the NOT NULL constraint came from a primary key?
regards, tom lane
On tor, 2010-01-21 at 16:29 -0500, Tom Lane wrote:
regression=# alter table foo add primary key (f1);
NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "foo_pkey" for table "foo"
ERROR: could not create unique index "foo_pkey"
DETAIL: Key (f1)=(1) is duplicated.
He he, that one doesn't even refer to a "constraint". Might also need
fixing. ;-)
It is not incorrect to refer to a primary key as a unique constraint.
Some things need a primary key that is not only a unique constraint. So
having some clarity about that can be helpful.
Will you next be wanting the error messages about null values to
distinguish whether the NOT NULL constraint came from a primary key?
Hadn't thought of that, but it could actually become relevant when we
get named not null constraints.
But anyway, if there is no interest in this, then forget about it.
On Thu, Jan 21, 2010 at 4:24 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
Why bother?
Because unique constraints and primary keys are different things and it
would be slightly less confusing that way.
I don't really see why it would be any less confusing. You could
argue that someone might not know that the primary key acts like a
unique constraint, but if they don't, then they might be confused
about what it means to violate it.
Generally if the user is looking at something like \d they will see
the primary key as well as any unique indices. And the name of the
primary key will match the name from this error message. So I'm also
not sure how someone could get pointed in the wrong direction in the
first place.
And why bother now, when we're in the middle of the last
CommitFest and trying to move toward a release?Are you saying we can't discuss anything new during the commit fest?
Of course, I have no control over what anyone discusses. This is a
community and no one has a boss. But let me ask this. For which
release were you hoping to make this change? If 9.0, then it seems to
me that you've missed the deadline, which - according to my
understanding of the agreed-upon schedule - was six days ago. Or
perhaps you feel that that deadline should only apply to
non-committers? If so, we should be clear about that, because I have
a few things which I would have liked to submit but was unable to get
done before the start of the CommmitFest. I would be more than happy
to finish them up and propose them now, but my understanding is that
I'm not supposed to do that.
On the other hand, if you were hoping to make this change for 9.1,
then obviously there is no issue of a deadline. However, there is
still the issue of the CommitFest mandate, of which you are a
proponent, which, in your exact words, says that one should not "work
on new patches" during CommitFest and beta.
http://archives.postgresql.org/pgsql-hackers/2009-06/msg01514.php
I have previously expressed the view you might have been overreaching
a bit in that email, because I don't think it's realistic to say that
there is useful work for everyone to do during the entire time that we
are in beta, and if there is nothing someone can do to get the release
out sooner, then I think it's fine for them to work on their own
patches. But that certainly isn't the case right now.
...Robert
On tor, 2010-01-21 at 17:06 -0500, Robert Haas wrote:
But let me ask this. For which
release were you hoping to make this change? If 9.0, then it seems to
me that you've missed the deadline, which - according to my
understanding of the agreed-upon schedule - was six days ago.
By that logic, the next release must be called 8.5, because the deadline
for proposing changes was six days ago.
Or perhaps you feel that that deadline should only apply to
non-committers? If so, we should be clear about that, because I have
a few things which I would have liked to submit but was unable to get
done before the start of the CommmitFest. I would be more than happy
to finish them up and propose them now, but my understanding is that
I'm not supposed to do that.
My understanding is that the commit fest process is an offer or perhaps
even a promise to patch submitters that their stuff will be attended to
within 2 or 3 months, instead of the 10 months or infinity that might
have been the previous average. And in order to make that "attending"
happen, the development participants are encouraged to focus on
reviewing the submitted patches.
But I don't think that should mean everyone has to drop everything when
the clock strikes midnight and must now only look at things that the
magic commitfest page has pre-approved. Nobody does that anyway. It
just means what you submit now does not get the same "promise" of
attention. Of course if you start proposing new significant features
now then it might be obvious that the discussion and review process
cannot possibly be concluded by the time the release is scheduled, so
you might as well not bother. But if things have been discussed before
or are simple enough and you just didn't get the thing done in time, why
not finish it up. I don't think anyone could accuse you of neglecting
the CF, as you are known to do your share. So I personally encourage
you to try to finish what you have started. If no one wants to review
it and you don't want to take responsibility yourself, well then. And
if someone proposes something that might be as simple as the MySQL
compatibility thing, assuming a consensus, why not include it, instead
of bumping it to 2012-Next for the sake of the process.
Peter Eisentraut wrote:
But I don't think that should mean everyone has to drop everything when
the clock strikes midnight and must now only look at things that the
magic commitfest page has pre-approved.
Well, we used to have the idea of a feature freeze ... is that going to
apply at the end of the commitfest?
I generally agree that we need to have a bit of wiggle room at this
stage - small and non-controversial items can be allowed to creep in still.
cheers
andrew
On Jan 21, 2010, at 3:05 PM, Andrew Dunstan wrote:
Well, we used to have the idea of a feature freeze ... is that going to apply at the end of the commitfest?
I generally agree that we need to have a bit of wiggle room at this stage - small and non-controversial items can be allowed to creep in still.
Seems to me we can have discussion anytime, though a given patch might get more or less discussion at various times. But clearly something like this would just be entered for the first 9.1 commitfest, no?
Best,
David
Andrew Dunstan <andrew@dunslane.net> writes:
Peter Eisentraut wrote:
But I don't think that should mean everyone has to drop everything when
the clock strikes midnight and must now only look at things that the
magic commitfest page has pre-approved.
Well, we used to have the idea of a feature freeze ... is that going to
apply at the end of the commitfest?
Even a feature freeze would not IMO prevent considering the sort of
small adjustment Peter was suggesting. We will doubtless be making
far larger adjustments than that even quite late in the release cycle.
(Particularly in the new HS/SR code.)
I thought his patch wasn't a particularly good idea, but I didn't have
a problem with it from a schedule or process standpoint.
If you want an example of something I *do* have a process problem
with, it's Kevin Grittner's attempts to get people to put a
significant number of cycles into thinking about true serializability.
Right now is not the time for that to be happening. I've been
politely ignoring that thread, but ...
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> wrote:
If you want an example of something I *do* have a process problem
with, it's Kevin Grittner's attempts to get people to put a
significant number of cycles into thinking about true
serializability.
Right now is not the time for that to be happening. I've been
politely ignoring that thread, but ...
Not my motive, but if you think that'll be the effect of posting
milestone patches, I'll hold 'em back. Apologies if I caused a
disruption.
-Kevin
Tom Lane <tgl@sss.pgh.pa.us> wrote:
If you want an example of something I *do* have a process problem
with, it's Kevin Grittner's attempts
Hmmm.... Plural? I've made exactly one post on the subject since
the CF started, unless you count review of Markus's dtester code,
which he posted before the CF but didn't add to the CF page. Is
reviewing that a process violation? Or was discussing it before the
CF the process issue?
After looking at my emails, I'm honestly confused. If it was the
milestone patch, and your plural was a slip, I'll hold off on
further such posts. If it's something else, I want to understand
what.
-Kevin
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
Tom Lane <tgl@sss.pgh.pa.us> wrote:
If you want an example of something I *do* have a process problem
with, it's Kevin Grittner's attempts
Hmmm.... Plural? I've made exactly one post on the subject since
the CF started, unless you count review of Markus's dtester code,
which he posted before the CF but didn't add to the CF page. Is
reviewing that a process violation? Or was discussing it before the
CF the process issue?
I thought the whole topic should have been held off till after the CF,
probably till after the bulk of beta testing work is done. It's a
sufficiently large and difficult problem that nobody can really give you
any meaningful feedback without taking more time away from our current
set of problems than I think is appropriate.
Now your original posts back in December were okay, since you were just
letting people know that you intended to work on this over a long
period. But IIRC you've made more than one post with actual code in it
that you seemed to be hoping people would review, and that I thought
was a distraction at this late stage of the cycle.
regards, tom lane
On Thu, Jan 21, 2010 at 7:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
Tom Lane <tgl@sss.pgh.pa.us> wrote:
If you want an example of something I *do* have a process problem
with, it's Kevin Grittner's attemptsHmmm.... Plural? I've made exactly one post on the subject since
the CF started, unless you count review of Markus's dtester code,
which he posted before the CF but didn't add to the CF page. Is
reviewing that a process violation? Or was discussing it before the
CF the process issue?I thought the whole topic should have been held off till after the CF,
probably till after the bulk of beta testing work is done. It's a
sufficiently large and difficult problem that nobody can really give you
any meaningful feedback without taking more time away from our current
set of problems than I think is appropriate.Now your original posts back in December were okay, since you were just
letting people know that you intended to work on this over a long
period. But IIRC you've made more than one post with actual code in it
that you seemed to be hoping people would review, and that I thought
was a distraction at this late stage of the cycle.
I actually thought that was a good thing to do, versus developing
totally out of site, though I admit I have had zero time to read the
code, and probably won't for a while.
...Robert
On Thu, Jan 21, 2010 at 5:35 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
On tor, 2010-01-21 at 17:06 -0500, Robert Haas wrote:
But let me ask this. For which
release were you hoping to make this change? If 9.0, then it seems to
me that you've missed the deadline, which - according to my
understanding of the agreed-upon schedule - was six days ago.By that logic, the next release must be called 8.5, because the deadline
for proposing changes was six days ago.
Well, I was assuming we were talking about feature freeze rather than
"no one can ever commit anything", or we'd never get to a release,
which is the point of this exercise AIUI.
Or perhaps you feel that that deadline should only apply to
non-committers? If so, we should be clear about that, because I have
a few things which I would have liked to submit but was unable to get
done before the start of the CommmitFest. I would be more than happy
to finish them up and propose them now, but my understanding is that
I'm not supposed to do that.My understanding is that the commit fest process is an offer or perhaps
even a promise to patch submitters that their stuff will be attended to
within 2 or 3 months, instead of the 10 months or infinity that might
have been the previous average. And in order to make that "attending"
happen, the development participants are encouraged to focus on
reviewing the submitted patches.
Right. I agree.
But I don't think that should mean everyone has to drop everything when
the clock strikes midnight and must now only look at things that the
magic commitfest page has pre-approved. Nobody does that anyway. It
I don't believe that something being on the CommitFest page implies
any sort of approval. It just expresses the desire of the submitter
for it to be reviewed.
just means what you submit now does not get the same "promise" of
attention. Of course if you start proposing new significant features
now then it might be obvious that the discussion and review process
cannot possibly be concluded by the time the release is scheduled, so
you might as well not bother. But if things have been discussed before
or are simple enough and you just didn't get the thing done in time, why
not finish it up. I don't think anyone could accuse you of neglecting
the CF, as you are known to do your share. So I personally encourage
you to try to finish what you have started. If no one wants to review
it and you don't want to take responsibility yourself, well then. And
Well, that does seem to be endorsing a sort of two-tiered system. If
I submit a patch and nobody looks at it, I can decide that silence
means approval and commit it. If someone who is not a committer does
the same thing, it dies, no matter how technically excellent it is. I
am no longer in a position to be bothered by that, but I think if I
were not a committer I might be. I wonder what others think about
this.
There's another issue, too. If a committer submits a patch, everybody
else who cares about the issue has to drop what they're doing and look
at it. Because if they don't, there's a good chance that in 24 hours
plus or minus, it'll be in the tree. Several patches have blown by me
in the last month or two - already committed before I got around to
reading them, and I might have had an opinion on them, but it's too
late to do anything about it now. I mean, it's not, really: I could
still ask for something to be changed, but it's an uphill battle at
this point.
if someone proposes something that might be as simple as the MySQL
compatibility thing, assuming a consensus, why not include it, instead
of bumping it to 2012-Next for the sake of the process.
I agree to a certain extent, but if you are concerned about our
release cycle being too long, as indicated by your use of the name
2012-Next, proposing a whole series of changes for changes during the
last CommitFest may not be the best way to get there. Maybe they're
small enough that it doesn't matter much, but I still think it would
have been easier to deal with two weeks ago when we had a lot less
going on. Anyway, I just work here. It's certainly not the end of
the world... and there are certainly other things which are going to
delay the release by a lot more than this will.
...Robert
Tom Lane wrote:
Now your original posts back in December were okay, since you were
just letting people know that you intended to work on this over a
long period. But IIRC you've made more than one post with actual
code in it that you seemed to be hoping people would review, and
that I thought was a distraction at this late stage of the cycle.
Well, I've gotten to the first three milestones and have posted a
patch for each. The first two were before the start of the CF, but I
intentionally *didn't* add them to the CF and specifically asked
people *not* to let them divert efforts from the release, which has
apparently been respected. It wasn't a disingenuous request.
Robert, in particular, said before the CF that he would look at the
first patch when I had it ready, and has apparently not done so yet
because of other priorities, which is as I would wish.
I hit the third milestone after the start of the CF and posted it
"for the record". If people find that distracting, I'll hold off
until I get some indication that it won't be. I think it's a bit
unfair to single me out because of that one post, but I think I can
handle it. :-) I just want to make sure I'm not missing some gaff I
didn't realize I was making. Given how small a portion of each year
is actually officially open for feedback, I'd hate to think that
posting a couple WIP patches during that narrow window was considered
a breach of protocol.
-Kevin
Import Notes
Resolved by subject fallback
On tor, 2010-01-21 at 18:05 -0500, Andrew Dunstan wrote:
Well, we used to have the idea of a feature freeze ... is that going
to apply at the end of the commitfest?
Feature freeze was used to discourage the submission of very big patches
shortly before beta. The commit fest process has IMO alleviated this
concern. Beta is still the definite cutoff; and the closer we get to
beta, the smaller the acceptable changes become. I think that formula
basically applies throughout the entire cycle.
On tor, 2010-01-21 at 19:45 -0500, Robert Haas wrote:
Well, that does seem to be endorsing a sort of two-tiered system.
In those words, yes, it's a multi-tiered system. The aim of the commit
fests is to make the "lower" tier more effective, but not necessarily to
bring the "upper" tier to a near halt.
If I submit a patch and nobody looks at it, I can decide that silence
means approval and commit it. If someone who is not a committer does
the same thing, it dies, no matter how technically excellent it is. I
am no longer in a position to be bothered by that, but I think if I
were not a committer I might be. I wonder what others think about
this.
Well, you have worked hard to get to that position, so those are the
perks.
There's another issue, too. If a committer submits a patch, everybody
else who cares about the issue has to drop what they're doing and look
at it. Because if they don't, there's a good chance that in 24 hours
plus or minus, it'll be in the tree. Several patches have blown by me
in the last month or two - already committed before I got around to
reading them, and I might have had an opinion on them, but it's too
late to do anything about it now. I mean, it's not, really: I could
still ask for something to be changed, but it's an uphill battle at
this point.
That would seem to ask that all committers funnel their patches through
the commit fest process. That might technically and morally be the
right thing, but it would probably not be a popular or realistic
proposal.
On Fri, Jan 22, 2010 at 8:40 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
On tor, 2010-01-21 at 18:05 -0500, Andrew Dunstan wrote:
Well, we used to have the idea of a feature freeze ... is that going
to apply at the end of the commitfest?Feature freeze was used to discourage the submission of very big patches
shortly before beta. The commit fest process has IMO alleviated this
concern. Beta is still the definite cutoff; and the closer we get to
beta, the smaller the acceptable changes become. I think that formula
basically applies throughout the entire cycle.
I'm not sure whether you're stating a position that's been agreed to
by -core or some other group, or just expressing your own opinion, but
I think feature freeze should be the beginning of the last CommitFest,
not the end.
...Robert
On Thu, 2010-01-21 at 23:22 +0200, Peter Eisentraut wrote:
On tor, 2010-01-21 at 15:51 -0500, Tom Lane wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
Here is a small patch that changes the error message
duplicate key value violates unique constraint "%s"
into
duplicate key value violates primary key "%s"
when the constraint is in fact a primary key.
Comments?
Why bother? And why bother now, when we're in the middle of the last
CommitFest and trying to move toward a release?This patch fails to cover all cases (index build being the obvious
omission, but I think there might be other paths as well where the
information is not so readily available).This is the user-visible error message, and that's the only place it's
generated.
In general, I agree that some error messages could be better.
OTOH this kind of gradual and minor creep between releases is very
annoying for our users, since you cannot rely on things remaining the
same between releases. That costs people lots of money and isn't worth
the marginal benefit, or alternatively prevents upgrades because of the
need for application and admin tool recoding and retesting. "Stable
software" isn't just software that doesn't break, it requires IIABDFI as
well.
--
Simon Riggs www.2ndQuadrant.com
Robert Haas wrote:
On Fri, Jan 22, 2010 at 8:40 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
On tor, 2010-01-21 at 18:05 -0500, Andrew Dunstan wrote:
Well, we used to have the idea of a feature freeze ... is that going
to apply at the end of the commitfest?Feature freeze was used to discourage the submission of very big patches
shortly before beta. The commit fest process has IMO alleviated this
concern. Beta is still the definite cutoff; and the closer we get to
beta, the smaller the acceptable changes become. I think that formula
basically applies throughout the entire cycle.I'm not sure whether you're stating a position that's been agreed to
by -core or some other group, or just expressing your own opinion, but
I think feature freeze should be the beginning of the last CommitFest,
not the end.
The commitfest is a useful procedural tool, but I think attempts to turn
it into something more prescriptive are likely to meet significant
resistance. Even the old feature freeze was a bit porous, especially
early on during the freeze, when small, low impact patches were not met
with cries of "you're six days past the deadline".
cheers
andrew
On Fri, 2010-01-22 at 09:10 -0500, Robert Haas wrote:
I'm not sure whether you're stating a position that's been agreed to
by -core or some other group, or just expressing your own opinion, but
I think feature freeze should be the beginning of the last CommitFest,
not the end.
Was is declared somewhere before commitfests began? If not, I would
agree with Peter here: Beta is the feature freeze. IIRC it has always
been so.
--
Devrim GÜNDÜZ, RHCE
Command Prompt - http://www.CommandPrompt.com
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
On Fri, Jan 22, 2010 at 9:22 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
On Thu, 2010-01-21 at 23:22 +0200, Peter Eisentraut wrote:
On tor, 2010-01-21 at 15:51 -0500, Tom Lane wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
Here is a small patch that changes the error message
duplicate key value violates unique constraint "%s"
into
duplicate key value violates primary key "%s"
when the constraint is in fact a primary key.
Comments?
Why bother? And why bother now, when we're in the middle of the last
CommitFest and trying to move toward a release?This patch fails to cover all cases (index build being the obvious
omission, but I think there might be other paths as well where the
information is not so readily available).This is the user-visible error message, and that's the only place it's
generated.In general, I agree that some error messages could be better.
OTOH this kind of gradual and minor creep between releases is very
annoying for our users, since you cannot rely on things remaining the
same between releases. That costs people lots of money and isn't worth
the marginal benefit, or alternatively prevents upgrades because of the
need for application and admin tool recoding and retesting. "Stable
software" isn't just software that doesn't break, it requires IIABDFI as
well.
Well put.
...Robert
2010/1/22 Devrim GÜNDÜZ <devrim@gunduz.org>:
On Fri, 2010-01-22 at 09:10 -0500, Robert Haas wrote:
I'm not sure whether you're stating a position that's been agreed to
by -core or some other group, or just expressing your own opinion, but
I think feature freeze should be the beginning of the last CommitFest,
not the end.Was is declared somewhere before commitfests began? If not, I would
agree with Peter here: Beta is the feature freeze. IIRC it has always
been so.
I don't know. I'm not trying to fabricate positions out of whole
cloth; I'm just saying what I thought we were doing. Obviously at
least some other people have a different understanding. We don't
really have much of this documented, to my knowledge, so there's
nothing that I can go read and say, ok, this is what the procedure is.
Which is kind of unfortunate, actually...
...Robert
On fre, 2010-01-22 at 14:22 +0000, Simon Riggs wrote:
"Stable software" isn't just software that doesn't break, it requires
IIABDFI as well.
Yeah, I don't buy that. That would mean that you can never do
maintenance, refactoring, or polishing. You basically just wait for the
system to die a death somewhere between unmaintainability and ugliness.
On Fri, 2010-01-22 at 16:50 +0200, Peter Eisentraut wrote:
On fre, 2010-01-22 at 14:22 +0000, Simon Riggs wrote:
"Stable software" isn't just software that doesn't break, it requires
IIABDFI as well.Yeah, I don't buy that. That would mean that you can never do
maintenance, refactoring, or polishing. You basically just wait for the
system to die a death somewhere between unmaintainability and ugliness.
I merely ask that you consider the non-zero cost of such changes as well
as the benefit. Not all change is worthwhile, even if the change can be
made quickly and with little effect on the stability of the software.
--
Simon Riggs www.2ndQuadrant.com
On fre, 2010-01-22 at 15:10 +0000, Simon Riggs wrote:
I merely ask that you consider the non-zero cost of such changes as
well
as the benefit. Not all change is worthwhile, even if the change can
be
made quickly and with little effect on the stability of the software.
Right, that's why I asked for comments, and the comments were clear. :)
Robert Haas <robertmhaas@gmail.com> writes:
I'm not sure whether you're stating a position that's been agreed to
by -core or some other group, or just expressing your own opinion, but
I think feature freeze should be the beginning of the last CommitFest,
not the end.
I think traditionally we understood "feature freeze" to be the point at
which we stopped *committing* new features, not the point at which it
was too late to *submit* them. So by that definition feature freeze
starts at the end of the last CF.
I agree with Peter that things are a bit different in the CF process.
Rather than a binary frozen-or-not state, we now have a gradual
congealing (if you will), where the size of an acceptable new feature
gets smaller as we get towards the end of the development cycle.
regards, tom lane
On Fri, Jan 22, 2010 at 11:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
I'm not sure whether you're stating a position that's been agreed to
by -core or some other group, or just expressing your own opinion, but
I think feature freeze should be the beginning of the last CommitFest,
not the end.I think traditionally we understood "feature freeze" to be the point at
which we stopped *committing* new features, not the point at which it
was too late to *submit* them. So by that definition feature freeze
starts at the end of the last CF.
OK, fair enough.
I agree with Peter that things are a bit different in the CF process.
Rather than a binary frozen-or-not state, we now have a gradual
congealing (if you will), where the size of an acceptable new feature
gets smaller as we get towards the end of the development cycle.
Yeah, and I have no problem with that. I think I've already beaten
this horse to death, though, so I won't re-explain what I do think.
...Robert
Robert Haas <robertmhaas@gmail.com> writes:
I think feature freeze should be the beginning of the last CommitFest,
not the end.
So you still want 3 CF per cycle rather than 4?
http://archives.postgresql.org/pgsql-hackers/2009-12/msg02355.php
3 CF and a FixFest… -1 from me, if there's an open vote to be made here.
Regards,
--
dim
On Fri, Jan 22, 2010 at 5:15 PM, Dimitri Fontaine
<dfontaine@hi-media.com> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
I think feature freeze should be the beginning of the last CommitFest,
not the end.So you still want 3 CF per cycle rather than 4?
http://archives.postgresql.org/pgsql-hackers/2009-12/msg02355.php3 CF and a FixFest… -1 from me, if there's an open vote to be made here.
What I really want is for people to be able to get their patches and
committed in a reasonably timely fashion. That means I'd like
releases to be reasonably frequent - like annually - and I'd like the
time for which nobody can get anything committed to be relatively
short. Between the start of the last CommitFest for 8.4 and the first
CommitFest for 8.5, 8 months went by. That is a darn long time, and I
think it's hurting the project. It's certainly annoying me, if that
counts for anything.
It appeared to me that Hot Standby, Streaming Replication, and
SE-PostgreSQL basically made no progress (or negative progress, in the
case of the third one) during that time. While I don't want to
venture too far into the realm of speculation, I believe that this may
be partly because (1) there was no chance they'd get committed and (2)
nobody was reviewing them and providing feedback. And I think there
are a lot of other people who just didn't really start to get serious
about finishing their patches until after they got some feedback from
the July CommitFest - a lot of what got marked RWF in July got
committed in September. I think those people were totally right to
blow off trying to get anything done from whenever they wrote the
patch until July, but I also think that it stinks that we ask people
to work that way.
And then there's the actual release schedule. Let's think about what
will happen if 9.0 isn't released until September. First of all,
patches that I wrote in February or March of 2009 will be show up in a
released version 18 months later. That is quite a long time.
Secondly, if the 9.1 cycle turns out to be the same length as the 9.0
cycle, then 9.1 will be released in November or December of 2011,
which means that any patches I write now will wait almost 2 years to
make a released version. That is a REALLY long time, and I'm
skeptical that releasing around the holidays is going to be a success
anyhow. Admittedly, this is all speculative - and just for the
record, if we're able to put out a release in early July as we did for
8.4, I'll be quite happy.
I understand that the majority of the community (or at least a
majority of the vocal community) is not in favor of the relatively
rigid time-based releases for which I am advocating. But I don't
think I am alone in the above-stated frustrations, either. What I'd
really like is to stop arguing about the number of CommitFests per
cycle and the exact charter of each CommitFest and start talking about
how we can create an environment where patch authors can get their
work committed reasonably quickly (assuming it's good, of course) and
released within some reasonable time frame after that (like, say,
within a year from commit) - because I think those things are
important to the health of the project, and even though FWIH things
are much better than in pre-CommitFest days, I still think there's
quite a bit of room for improvement.
Any ideas?
...Robert
On fre, 2010-01-22 at 18:05 -0500, Robert Haas wrote:
and start talking about
how we can create an environment where patch authors can get their
work committed reasonably quickly (assuming it's good, of course) and
released within some reasonable time frame after that (like, say,
within a year from commit) - because I think those things are
important to the health of the project, and even though FWIH things
are much better than in pre-CommitFest days, I still think there's
quite a bit of room for improvement.Any ideas?
The lower bound on the release cycle is about 12 months right now
because we intend to support old versions for 5 years, and 5 or 6
branches at once is about the most anyone can handle. That formula is
tough to change.
Peter Eisentraut <peter_e@gmx.net> writes:
On fre, 2010-01-22 at 18:05 -0500, Robert Haas wrote:
Any ideas?
The lower bound on the release cycle is about 12 months right now
because we intend to support old versions for 5 years, and 5 or 6
branches at once is about the most anyone can handle. That formula is
tough to change.
Another problem is that it's very debatable whether users (as opposed
to developers) want a fast release cycle. Some of that reluctance to
update might dissipate if we had a better upgrade-in-place story, but
by no means all of it. People don't want to have to retest their
applications every six months.
I agree with trying to cut down the submission-to-commit delay, but
the release cycle length is not primarily determined by what patch
authors would like ...
regards, tom lane
Tom Lane wrote:
Another problem is that it's very debatable whether users (as opposed
to developers) want a fast release cycle. Some of that reluctance to
update might dissipate if we had a better upgrade-in-place story, but
by no means all of it. People don't want to have to retest their
applications every six months.
Or even more than once every few years. This is a consideration that is
often ignored in our discussions, unfortunately.
cheers
andrew
On Fri, Jan 22, 2010 at 7:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
On fre, 2010-01-22 at 18:05 -0500, Robert Haas wrote:
Any ideas?
The lower bound on the release cycle is about 12 months right now
because we intend to support old versions for 5 years, and 5 or 6
branches at once is about the most anyone can handle. That formula is
tough to change.Another problem is that it's very debatable whether users (as opposed
to developers) want a fast release cycle. Some of that reluctance to
update might dissipate if we had a better upgrade-in-place story, but
by no means all of it. People don't want to have to retest their
applications every six months.
I didn't mean to imply that we should try to release every 6 months,
if that's what it sounded like. I think annual release cycles are
fine. I don't like the idea of letting it slip to 15 or 18 months,
though.
I agree with trying to cut down the submission-to-commit delay, but
the release cycle length is not primarily determined by what patch
authors would like ...
It seems to me that the CommitFest process is pretty darn effective at
reducing the submission-to-commit delay, except when you miss the last
one for the release - then it sucks hard.
I prefer annual release cycles as a user, not just as a developer. If
I start a new project now, it'll be based on 8.4.2. If 8.4 had never
happened and 8.3 were still the current release, any new project I
started would have to be based on 8.3. Of course, I still have
several systems running 8.3 (and I think even 8.2) that are chugging
along just fine; they lose nothing from 8.4 having been released.
...Robert
Robert Haas <robertmhaas@gmail.com> writes:
I agree with trying to cut down the submission-to-commit delay, but
It seems to me that the CommitFest process is pretty darn effective at
reducing the submission-to-commit delay, except when you miss the last
one for the release - then it sucks hard.
Too bad we can't have a release management team (with committers,
testers, advocacy, doc writers, etc) taking care of the beta to release
road while the first commit fest(s) for next release happen in parallel.
It would move the primary goal of a commit fest from committing patches
to reviewing them (return with feedback or stamp ready for a committer),
reducing the chances that anyone will have some time to handle the last
step.
But that would allow say 6 commit fests per year, even if 2 of them
would in fact be (almost) review-only fests.
You could say that those 2 extra fests will only pile up more work to do
for committers once they're back from release management, but actually
that's already what happens:
- the first 8.5 commit fest had a lot of patches never reviewed
- the 3rd commit fest for 9.1 would instead have plenty of ready to
commit patches
- authors that happen to have the bad luck of only having time to
devote to PostgreSQL between beta and release would still enjoy a
timely patch review, if not commit.
Regards,
--
dim
2010/1/23 Dimitri Fontaine <dfontaine@hi-media.com>:
Robert Haas <robertmhaas@gmail.com> writes:
I agree with trying to cut down the submission-to-commit delay, but
It seems to me that the CommitFest process is pretty darn effective at
reducing the submission-to-commit delay, except when you miss the last
one for the release - then it sucks hard.Too bad we can't have a release management team (with committers,
testers, advocacy, doc writers, etc) taking care of the beta to release
road while the first commit fest(s) for next release happen in parallel.It would move the primary goal of a commit fest from committing patches
to reviewing them (return with feedback or stamp ready for a committer),
reducing the chances that anyone will have some time to handle the last
step.
It seems to me that recent discussions pass over this point. At least
for me, the commit fest is to review patches and give authors feedback
in not-so-long time after posting them. I like this idea.
Regards,
--
Hitoshi Harada
--On 22. Januar 2010 15:40:58 +0200 Peter Eisentraut <peter_e@gmx.net>
wrote:
Beta is still the definite cutoff; and the closer we get to
beta, the smaller the acceptable changes become. I think that formula
basically applies throughout the entire cycle.
For someone like me it's hard to guess, what "small" means in that context.
For example, i delayed my work on improving the representation of NOT NULL
constraints in favor of the pg_table_size() patch (my time was too limited
to work on both), since i always thought submitting beyond CF start would
be a non-starter for such a thing.
--
Thanks
Bernd
Bernd Helmle wrote:
--On 22. Januar 2010 15:40:58 +0200 Peter Eisentraut <peter_e@gmx.net>
wrote:Beta is still the definite cutoff; and the closer we get to
beta, the smaller the acceptable changes become. I think that formula
basically applies throughout the entire cycle.For someone like me it's hard to guess, what "small" means in that
context. For example, i delayed my work on improving the
representation of NOT NULL constraints in favor of the pg_table_size()
patch (my time was too limited to work on both), since i always
thought submitting beyond CF start would be a non-starter for such a
thing.
It's a judgement call. I know that bothers the heck out of some people,
but hard and fast rules bug the heck out of others, so someone is going
to get bugged either way. As Ricky Nelson sang, "You can't please everyone."
cheers
andrew
Robert Haas <robertmhaas@gmail.com> wrote:
That means I'd like releases to be reasonably frequent - like
annually - and I'd like the time for which nobody can get anything
committed to be relatively short.
Yeah, the current approach seems to be to develop a schedule around
a one-year cycle, with an implicit assumption that the date will
never actually be hit, so the release cycle will really be 15 months
or more. Just don't say it out loud [oops]. Close to half of that
is effectively closed to submissions from non-committers.
if we're able to put out a release in early July as we did for
8.4, I'll be quite happy.
Well, six months from the start of the last CF to release seems like
it would leave a lot of room for improvement in project management
techniques, but at this point July would be a happy thing just
because I currently get the sense that we're actually on track for a
release well past that.
What I'd really like is to stop arguing about the number of
CommitFests per cycle and the exact charter of each CommitFest and
start talking about how we can create an environment where patch
authors can get their work committed reasonably quickly (assuming
it's good, of course) and released within some reasonable time
frame after that
Dimitri's reply with the "Too bad we can't have" portion makes me
wonder whether we really can't. Does it really take the concerted
efforts of the whole community five months to take things from the
deadline for patch commits (end of last CF) to release? Is it that
nobody would volunteer to take the burden of that effort so that
others could code? Perhaps it isn't that five months is outrageous,
but that it doesn't really benefit from an unorganized swarm of
activity by all the developers, and we've not worked out a
reasonable framework for who should do what during that time to best
benefit the project while giving all these volunteer and sponsored
developers something they are willing to put effort into.
At the risk of hanging a big "slacker" bulls-eye on my chest, I will
say that while I've managed to get approval from management here to
test prior releases during their beta periods "on the clock", with
the justification that it would catch bugs which affect our "unique"
environment before have to try to bring it in for production use,
that is simply not an option this time. Any such contribution would
have to be off-hours (like today), because they have become
convinced of the need for a particular PostgreSQL feature that
nobody else is addressing and authorized time for that; and there's
no way they're going to pay for both this year. I don't know how
many other find themselves in such binds, but I'm sure it happens.
-Kevin
On Sat, Jan 23, 2010 at 10:47 AM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
What I'd really like is to stop arguing about the number of
CommitFests per cycle and the exact charter of each CommitFest and
start talking about how we can create an environment where patch
authors can get their work committed reasonably quickly (assuming
it's good, of course) and released within some reasonable time
frame after thatDimitri's reply with the "Too bad we can't have" portion makes me
wonder whether we really can't. Does it really take the concerted
efforts of the whole community five months to take things from the
deadline for patch commits (end of last CF) to release?
No.
Is it that
nobody would volunteer to take the burden of that effort so that
others could code?
No.
Perhaps it isn't that five months is outrageous,
but that it doesn't really benefit from an unorganized swarm of
activity by all the developers, and we've not worked out a
reasonable framework for who should do what during that time to best
benefit the project while giving all these volunteer and sponsored
developers something they are willing to put effort into.
I think that's pretty close.
...Robert
Robert Haas wrote:
Perhaps it isn't that five months is outrageous,
but that it doesn't really benefit from an unorganized swarm of
activity by all the developers, and we've not worked out a
reasonable framework for who should do what during that time to best
benefit the project while giving all these volunteer and sponsored
developers something they are willing to put effort into.I think that's pretty close.
I think it's pretty close to 100% BS. Who constitutes this legion of
sponsored developers in desperate need of organization? And what are
they sponsored for? I can't speak for others, but with one exception the
only sponsorship I have received is for actual development work, not
release finishing (and the exception ended up being mostly development
anyway). Sponsors almost always want to provide money for actual
features. And as for volunteers, they have a fantastic resistance to
being organized in some prescriptive way. We need to achieve what we can
by persuasion. It's sometimes a pain in the neck, but it's the reality.
The real problem is that we take a long time between the end of the
development phase and the release. That is often not something you can
just throw bodies at ("Nine women can't make a baby in a month.").
Sadly, some things do just take time to work out. It's frustrating, but
shortening the time could simply result in our making less polished
releases. The problem is likely to grow with our increasing emphasis on
enterprise level features. But I don't think that sacrificing quality
for timeliness is a good trade.
That is not to say that we can't make some improvements in process, but
expecting them magically to solve this problem is a bit cargo cultish.
cheers
andrew
Kevin Grittner wrote:
Does it really take the concerted efforts of the whole community five months to take things from the
deadline for patch commits (end of last CF) to release?
The idea is that it takes five months of complete lockdown to give the
code enough testing time to hopefully reach stability. I don't think
that part is particularly controversial--reduce it, and quality drops,
period. And as pointed out by a couple of people, even one release per
year of a database is more than many users really want to consume, as
evidenced by the number of 7.X installs still going because "we don't
want to touch the working app" we still hear about.
The question then is what else you could be doing during that period.
Let's say that the day 9.0 beta 1 came out, a new 9.1 branch was created
and CommitFests against it started, during what right now would be time
exclusively devoted to beta testing. Completely feasible idea. There
would be some forward/backporting duplication of work while those were
running in parallel, and that would be harder than it needs to be until
something like a git transition happens. But you certainly could do it.
So why not do that? Developing new features is fun and tends to attract
sponsorship dollars. Testing a frozen release, finding bugs, and
resolving them is boring, and no one sponsors it. Therefore, if you let
both things go on at once, I guarantee you almost all of the community
attention will be diverted toward new development during any period
where both are happening at the same time. Give developers a choice
between shiny and profitable vs. dull and unpaid, and they'll focus on
the former every time. That means that there's no possible way you can
keep new development open without hurting the dreary work around
stabilizing the beta in the process. You have to put all the fun toys
away in order to keep focus on the painful parts.
Plenty of other projects don't work this way, with a beta drop being a
kick off to resume full-on development. There's a reason why PostgreSQL
has a better reputation for quality releases than they do. It's an
enterprise-class database; you don't just throw code in there, release
the result every quarter, and expect the result to be stable. If
developers are turned away because they want more instant gratification
for their development efforts, they're working on the wrong type of
project for them.
--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.com
Greg Smith <greg@2ndquadrant.com> writes:
... if you let
both things go on at once, I guarantee you almost all of the community
attention will be diverted toward new development during any period
where both are happening at the same time.
Yes. This is the big problem that would have to be solved before we
could have commitfests occurring in parallel with beta. There simply
isn't a pool of (qualified) talent that can go off and do beta testing
and stabilization in parallel with new development. It's pretty much
the same people who do both tasks; so if we try to do that, one of two
things is going to happen: beta takes even longer, or release quality
goes down.
We already heard a lot of complaints that 8.4 should have gotten more
testing than it did. Proposing to continue development in parallel
with beta is a good way to ensure that that will get worse not better.
regards, tom lane
Tom Lane wrote:
We already heard a lot of complaints that 8.4 should have gotten more
testing than it did. Proposing to continue development in parallel
with beta is a good way to ensure that that will get worse not better.
Right. If we really want to improve matters we'll spend our efforts on
finding more resources, not diverting those we have or making new rules.
cheers
andrew
Tom Lane <tgl@sss.pgh.pa.us> writes:
There simply isn't a pool of (qualified) talent that can go off and
do beta testing and stabilization in parallel with new development.
It's pretty much the same people who do both tasks; so if we try to do
that, one of two things is going to happen: beta takes even longer, or
release quality goes down.
I was under the illusion than we had some RRR people not talented enough
to be full-speed contributors to release management that we could have
this team run one or two ReviewFest while the "serious" guys were
working.
Goal being to continue being responsive to authors in a way that will
not compromise our stability, but if that means *all* qualified talents
of the community get assigned to release management team… I stop seeing
the point.
Regards,
--
dim
On Saturday 23 January 2010 22:24:41 Dimitri Fontaine wrote:
I was under the illusion than we had some RRR people not talented enough
to be full-speed contributors to release management that we could have
this team run one or two ReviewFest while the "serious" guys were
working.
I find "not talented" enough quite a bit too harsh...
Andres
Dimitri Fontaine <dfontaine@hi-media.com> writes:
Goal being to continue being responsive to authors in a way that will
not compromise our stability, but if that means *all* qualified talents
of the community get assigned to release management team… I stop seeing
the point.
There seems to be some weird notion abroad in this thread that the
primary time sink during beta is unspecified low-skill "release
management" tasks. There really isn't all that much of that.
What I find takes up a lot of time is post-commit patch review, fixing
reported bugs, and documentation cleanup. Now we could doubtless find
other people to do the purely copy-editing aspects of doc cleanup, like
fixing less-than-stellar English, but what I'm really looking for is
factually incorrect or obsolete statements. It takes someone who's
pretty much familiar top-to-bottom with the whole product to do a decent
job of spotting things that were true awhile ago but aren't any longer.
We just don't have many people who (a) can and (b) will do that work.
What I think we really need for beta, and could reasonably hope to get,
is a larger and better-organized beta testing effort. But we are not
going to get that if people are thinking about new development and
commit fests instead of testing what's already there.
regards, tom lane
Andres Freund <andres@anarazel.de> writes:
I find "not talented" enough quite a bit too harsh...
Ok sorry about the term choice: RRR who like me are able to review
patches and help their authors but have yet to submit a patch and have
their code part of PostgreSQL, e.g.
I hope this is more clear stated this way.
--
dim
Tom Lane <tgl@sss.pgh.pa.us> writes:
There seems to be some weird notion abroad in this thread that the
primary time sink during beta is unspecified low-skill "release
management" tasks. There really isn't all that much of that.
I'd have said high-skill, which the following paragraph I parse as
confirming it:
What I find takes up a lot of time is post-commit patch review, fixing
reported bugs, and documentation cleanup. Now we could doubtless find
other people to do the purely copy-editing aspects of doc cleanup, like
fixing less-than-stellar English, but what I'm really looking for is
factually incorrect or obsolete statements. It takes someone who's
pretty much familiar top-to-bottom with the whole product to do a decent
job of spotting things that were true awhile ago but aren't any longer.
We just don't have many people who (a) can and (b) will do that work.
Yeah and the ones who can, they're not all having the possibility to get
paid doing it...
What I think we really need for beta, and could reasonably hope to get,
is a larger and better-organized beta testing effort. But we are not
going to get that if people are thinking about new development and
commit fests instead of testing what's already there.
That's where the advocacy people involvement would help I think. But for
beta testing to be effective you need all the 3 of non-trivial
application, non-trivial data set and meaningful automated test suite. I
for one don't have that handy.
So what I had in mind is that if you know you're not that helpful on the
release management issues (of which beta testing), maybe you could help
running the review fest for doing entry-level patch triage, even against
the stabilizing tree (if the only goal is timely feedback to authors).
Again I agree we miss resources more than organization, but I can't help
thinking some resources won't be able to participate in end-of-cycle and
are blocked waiting for the release lock.
Regards,
--
dim
On Sat, Jan 23, 2010 at 4:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Dimitri Fontaine <dfontaine@hi-media.com> writes:
Goal being to continue being responsive to authors in a way that will
not compromise our stability, but if that means *all* qualified talents
of the community get assigned to release management team… I stop seeing
the point.There seems to be some weird notion abroad in this thread that the
primary time sink during beta is unspecified low-skill "release
management" tasks. There really isn't all that much of that.
I wasn't under that impression. I did have the impression that the
primary time sink was resolving "open items", which I think could have
been better organized last time around.
What I find takes up a lot of time is post-commit patch review, fixing
reported bugs, and documentation cleanup. Now we could doubtless find
other people to do the purely copy-editing aspects of doc cleanup, like
fixing less-than-stellar English, but what I'm really looking for is
factually incorrect or obsolete statements. It takes someone who's
pretty much familiar top-to-bottom with the whole product to do a decent
job of spotting things that were true awhile ago but aren't any longer.
We just don't have many people who (a) can and (b) will do that work.
Do you think I'd be qualified to help with any of this? (Feel free to
reply off-list, if that's more appropriate... or just let 'er rip.)
What I think we really need for beta, and could reasonably hope to get,
is a larger and better-organized beta testing effort. But we are not
going to get that if people are thinking about new development and
commit fests instead of testing what's already there.
We've had some interest in trying to organize that - from Josh Berkus,
I believe, among others. As for beta-testing myself, AFAIR, the most
commonly advocated strategy for beta testing is "run your application
on the beta and see if it goes boom". I don't really see how I'm
supposed to spend five months on that. I could do it, but if I poke
at it for a couple of days and nothing blows up, it probably isn't
going to blow up. What then?
...Robert
On Sat, Jan 23, 2010 at 12:07 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
Robert Haas wrote:
Perhaps it isn't that five months is outrageous,
but that it doesn't really benefit from an unorganized swarm of
activity by all the developers, and we've not worked out a
reasonable framework for who should do what during that time to best
benefit the project while giving all these volunteer and sponsored
developers something they are willing to put effort into.I think that's pretty close.
I think it's pretty close to 100% BS. Who constitutes this legion of
sponsored developers in desperate need of organization? And what are they
sponsored for? I can't speak for others, but with one exception the only
sponsorship I have received is for actual development work, not release
finishing (and the exception ended up being mostly development anyway).
Sponsors almost always want to provide money for actual features. And as for
volunteers, they have a fantastic resistance to being organized in some
prescriptive way. We need to achieve what we can by persuasion. It's
sometimes a pain in the neck, but it's the reality.The real problem is that we take a long time between the end of the
development phase and the release. That is often not something you can just
throw bodies at ("Nine women can't make a baby in a month."). Sadly, some
things do just take time to work out. It's frustrating, but shortening the
time could simply result in our making less polished releases. The problem
is likely to grow with our increasing emphasis on enterprise level features.
But I don't think that sacrificing quality for timeliness is a good trade.That is not to say that we can't make some improvements in process, but
expecting them magically to solve this problem is a bit cargo cultish.
I think you're kind of caricaturing what I said here, and what Kevin
said. People really are willing to put time into helping get a
release out the door if they feel like their efforts will move the
needle. Do they get directly paid to make the release happen faster?
No, probably not. That doesn't mean they won't put time into it. I
don't think too many people get paid to do patch review either, but
somehow we manage to have CommitFests. It's not magic, but it does
help.
...Robert
Andrew Dunstan wrote:
The real problem is that we take a long time between the end of the
development phase and the release. That is often not something you can
just throw bodies at ("Nine women can't make a baby in a month.").
This is the best anti-analogy I have heard in years.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
On Sat, Jan 23, 2010 at 9:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
What I find takes up a lot of time is post-commit patch review, fixing
reported bugs, and documentation cleanup. Now we could doubtless find
other people to do the purely copy-editing aspects of doc cleanup, like
fixing less-than-stellar English, but what I'm really looking for is
factually incorrect or obsolete statements. It takes someone who's
pretty much familiar top-to-bottom with the whole product to do a decent
job of spotting things that were true awhile ago but aren't any longer.
We just don't have many people who (a) can and (b) will do that work.
So I've never seen this mentioned before. In retrospect I remember you
popping up with such things but I don't recall discussion of what work
remained and which sections of the docs or commits you've finished
with so far, etc. That makes it hard for anyone else to help the work
go any faster.
Would it be helpful if we divided up the manual and handed out
sections to different people? Or if you could note that something
sounded wrong and then, at least for some of them just send a quick
email noting the section and anyone else could write up the changes?
Obviously in some cases the changes will be minor but in others whole
examples might need to be rewritten or new sections added.
What I think we really need for beta, and could reasonably hope to get,
is a larger and better-organized beta testing effort. But we are not
going to get that if people are thinking about new development and
commit fests instead of testing what's already there.
Incidentally I'm not convinced that's true. The people we really want
testing stuff are the people who have real-world test cases to throw
at the new version and they're the people who will be most excited
about a new release and the least interested in a commitfest for a
version that they won't be able to run for another year. We have a
hard enough time getting people to not wait until the last commitfest
after all.
But I would be happy getting our current process working perfectly
before trying experiments like that.
--
greg
Greg Smith wrote:
So why not do that? Developing new features is fun and tends to attract
sponsorship dollars. Testing a frozen release, finding bugs, and
resolving them is boring, and no one sponsors it. Therefore, if you let
both things go on at once, I guarantee you almost all of the community
attention will be diverted toward new development during any period
where both are happening at the same time. Give developers a choice
between shiny and profitable vs. dull and unpaid, and they'll focus on
the former every time. That means that there's no possible way you can
keep new development open without hurting the dreary work around
stabilizing the beta in the process. You have to put all the fun toys
away in order to keep focus on the painful parts.
"put all the fun toys away in order to keep focus on the painful parts"
--- pure poetry.--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Robert Haas wrote:
On Sat, Jan 23, 2010 at 12:07 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
Robert Haas wrote:
Perhaps it isn't that five months is outrageous,
but that it doesn't really benefit from an unorganized swarm of
activity by all the developers, and we've not worked out a
reasonable framework for who should do what during that time to best
benefit the project while giving all these volunteer and sponsored
developers something they are willing to put effort into.I think that's pretty close.
I think it's pretty close to 100% BS. Who constitutes this legion of
sponsored developers in desperate need of organization? And what are they
sponsored for? I can't speak for others, but with one exception the only
sponsorship I have received is for actual development work, not release
finishing (and the exception ended up being mostly development anyway).
Sponsors almost always want to provide money for actual features. And as for
volunteers, they have a fantastic resistance to being organized in some
prescriptive way. We need to achieve what we can by persuasion. It's
sometimes a pain in the neck, but it's the reality.The real problem is that we take a long time between the end of the
development phase and the release. That is often not something you can just
throw bodies at ("Nine women can't make a baby in a month."). Sadly, some
things do just take time to work out. It's frustrating, but shortening the
time could simply result in our making less polished releases. The problem
is likely to grow with our increasing emphasis on enterprise level features.
But I don't think that sacrificing quality for timeliness is a good trade.That is not to say that we can't make some improvements in process, but
expecting them magically to solve this problem is a bit cargo cultish.I think you're kind of caricaturing what I said here, and what Kevin
said. People really are willing to put time into helping get a
release out the door if they feel like their efforts will move the
needle. Do they get directly paid to make the release happen faster?
No, probably not. That doesn't mean they won't put time into it. I
don't think too many people get paid to do patch review either, but
somehow we manage to have CommitFests. It's not magic, but it does
help.
Certainly I was being slightly facetious. If anyone is surpised they
haven't been paying attention ;-)
But the point I'm trying to get across is that an assumption that better
process and more organization is somehow going to get us to a shorter
period between feature freeze and release is not necessarily so. See
Tom's response upthread for more reasons why this is so. That's not
meant to discourage people from doing work, it's meant to stop people
from getting unreal expectations.
And, BTW, more process and organization can itself consume scarce
resources as well as annoying some of the people you want to do some of
this work. There is a sweet spot that we need to aim at.
OK, back to making the buildfarm client git-aware ...
cheers
andrew
On Sat, Jan 23, 2010 at 7:59 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
And, BTW, more process and organization can itself consume scarce resources
as well as annoying some of the people you want to do some of this work.
There is a sweet spot that we need to aim at.
What, me annoy someone? That never happens.
In all honesty, I think we are anything but drowning in process.
OK, back to making the buildfarm client git-aware ...
+1!
...Robert
Andrew Dunstan wrote:
Perhaps it isn't that five months is outrageous, but that it
doesn't really benefit from an unorganized swarm of activity by
all the developers, and we've not worked out a reasonable
framework for who should do what during that time to best benefit
the project while giving all these volunteer and sponsored
developers something they are willing to put effort into.
And what are they sponsored for? I can't speak for others, but with
one exception the only sponsorship I have received is for actual
development work, not release finishing (and the exception ended up
being mostly development anyway). Sponsors almost always want to
provide money for actual features.
That was one of the points I was intending to convey. After they
confirm that the beta release works on their software, what do they
currently do for the next five months? Currently, as things now
stand.
And as for volunteers, they have a fantastic resistance to
being organized in some prescriptive way. We need to achieve what
we can by persuasion. It's sometimes a pain in the neck, but it's
the reality.
And what do we want *them* to do after spending a couple days effort
on beta testing. (Even if you're going to let it run for months
parallel to production, how long does it take to *set that up*?)
The real problem is that we take a long time between the end of the
development phase and the release. That is often not something you
can just throw bodies at ("Nine women can't make a baby in a
month.").
Again, kinda my point. So what *are* the other eight *currently*
doing? (I guess we don't want to get too graphic about that if we're
going to follow that analogy out....)
Sadly, some things do just take time to work out. It's frustrating,
but shortening the time could simply result in our making less
polished releases.
I thought the quote at the top was specifically about *not*
shortening the time, but trying to figure out how we can best keep
resources working to the benefit of the project during that time.
You've as much as said that it's a given that many of the
contributors will continue to work on new patches during this period
to earn a living, while hopefully volunteering to help with getting
the release out the door on their own time. As I understand the
arguments, having that occur as a "guilty secret", with no community
discussion or review during that period, versus trying to find a way
to organizationally admit the fact and try to manage the available
resources in a real versus pretend way is the issue here.
-Kevin
Import Notes
Resolved by subject fallback
Greg Smith wrote:
Developing new features is fun and tends to attract sponsorship
dollars. Testing a frozen release, finding bugs, and resolving them
is boring, and no one sponsors it. Therefore, if you let both
things go on at once, I guarantee you almost all of the community
attention will be diverted toward new development during any period
where both are happening at the same time.
Frankly, part of the problem is that it's hard for many of us to see
how to contribute effectively for most of these five months or so, in
general. In particular, if someone *is* willing to pay you to work
on developing a feature during these months, but not to work on any
other PostgreSQL development, what do you recommend?
That means that there's no possible way you can keep new
development open without hurting the dreary work around stabilizing
the beta in the process.
Most of my time on stabilizing new releases has, in the past, been
volunteer, in spite of getting some time approved for testing some
releases on the clock. This time around, *all* time I spend on this
phase will be volunteer -- it's just a question of whether my *paid*
time is spent on new development for PostgreSQL, or things entirely
unrelated to PostgreSQL. If I'm working on PostgreSQL for pay, it
doesn't make me either less likely to volunteer time, or less skilled
at contributing during my volunteer efforts.
-Kevin
Import Notes
Resolved by subject fallback
Kevin Grittner wrote:
Greg Smith wrote:
Developing new features is fun and tends to attract sponsorship
dollars. Testing a frozen release, finding bugs, and resolving them
is boring, and no one sponsors it. Therefore, if you let both
things go on at once, I guarantee you almost all of the community
attention will be diverted toward new development during any period
where both are happening at the same time.Frankly, part of the problem is that it's hard for many of us to see
how to contribute effectively for most of these five months or so, in
general. In particular, if someone *is* willing to pay you to work
on developing a feature during these months, but not to work on any
other PostgreSQL development, what do you recommend?
Yea, that is a problem. Years ago the commit process was all driven by
a few individuals, and our group has been successful at distributing
that workload, so my hope is that the stabilization phase will also lend
itself to distributing the workload someday too.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Kevin Grittner wrote:
You've as much as said that it's a given that many of the
contributors will continue to work on new patches during this period
to earn a living, while hopefully volunteering to help with getting
the release out the door on their own time. As I understand the
arguments, having that occur as a "guilty secret", with no community
discussion or review during that period, versus trying to find a way
to organizationally admit the fact and try to manage the available
resources in a real versus pretend way is the issue here.
It's not a guilty secret, it's not really a secret at all. People have
in the past submitted patches during beta, and there has been extensive
discussion about them. You just have to wait to get patches into the
tree. In the past I suggested that we should branch much earlier to
allow such patches to get into the tree. The argument against it, which
I think is probably valid, is that we don't have the resources to manage
both trees, and it could be a distraction for those working on polishing
the release.
As for getting more coverage of Beta, part of my trouble in testing
applications on Beta is that there aren't good tools I know of for
capture and replay of usage scenarios. Now there would be a good project
for someone, and it would be unaffected by the Beta cycle.
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> wrote:
As for getting more coverage of Beta, part of my trouble in
testing applications on Beta is that there aren't good tools I
know of for capture and replay of usage scenarios. Now there would
be a good project for someone, and it would be unaffected by the
Beta cycle.
Did you follow any of the dtester discussion? That would allow
replay of complex usage scenarios, although they would be scripted,
rather than captured. Would that help any?
-Kevin
Kevin Grittner wrote:
Andrew Dunstan <andrew@dunslane.net> wrote:
As for getting more coverage of Beta, part of my trouble in
testing applications on Beta is that there aren't good tools I
know of for capture and replay of usage scenarios. Now there would
be a good project for someone, and it would be unaffected by the
Beta cycle.Did you follow any of the dtester discussion? That would allow
replay of complex usage scenarios, although they would be scripted,
rather than captured. Would that help any?
Yes, I saw some, and I think it's useful. A capture tool, even if its
output required some massaging, would be terrific, though.
cheers
andrew
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
Andrew Dunstan <andrew@dunslane.net> wrote:
As for getting more coverage of Beta, part of my trouble in
testing applications on Beta is that there aren't good tools I
know of for capture and replay of usage scenarios. Now there would
be a good project for someone, and it would be unaffected by the
Beta cycle.Did you follow any of the dtester discussion? That would allow
replay of complex usage scenarios, although they would be scripted,
rather than captured. Would that help any?
And there's already pgfouine to get the scenarios from the logs and
tsung to act as a recording proxy:
http://pgfouine.projects.postgresql.org/tsung.html
http://tsung.erlang-projects.org/user_manual.html#htoc34
So maybe it would be a good idea to have dtester able to replay a tsung
session file so that we already know how to get this input?
Then dtester would be for validating queries output and tsung for
testing the scalability, both working with the same format.
Regards,
--
dim
Dimitri Fontaine wrote:
And there's already pgfouine to get the scenarios from the logs and
tsung to act as a recording proxy:
http://pgfouine.projects.postgresql.org/tsung.html
http://tsung.erlang-projects.org/user_manual.html#htoc34So maybe it would be a good idea to have dtester able to replay a
tsung session file so that we already know how to get this input?Then dtester would be for validating queries output and tsung for
testing the scalability, both working with the same format.
I will take a close look at that and see how the two might work
together or in complementary roles. Thanks for reminding me about
this tool.
-Kevin
Import Notes
Resolved by subject fallback
Greg Stark wrote:
Tom Lane wrote:
What I think we really need for beta, and could reasonably hope to
get, is a larger and better-organized beta testing effort. But we
are not going to get that if people are thinking about new
development and commit fests instead of testing what's already
there.Incidentally I'm not convinced that's true. The people we really
want testing stuff are the people who have real-world test cases to
throw at the new version and they're the people who will be most
excited about a new release and the least interested in a
commitfest for a version that they won't be able to run for another
year.
I tend to agree with you there. The primary risk seems to be that
such discussions could distract people who are already working on the
release process, not that there is a mob of people who could do much
to help with release who will be misdirected into new development.
But I would be happy getting our current process working perfectly
before trying experiments like that.
Seriously? *Perfectly*? I'm not even sure what objective metrics
you could effectively use to measure success in the process, much
less set targets for "perfection" which must be met before trying to
solve acknowledged existing problems.
Other posts have suggested that "review fests" might be helpful in
this period. Again, it sounds to me, from other posts on this
thread, as though the primary risk is that people working on the
release could see something they couldn't resist getting drawn into
-- taking them off-task and delaying the release. The obvious
solution to that would be to create a pgsql-journeyman-peer-review
list for review fests during the release window. As long as we
we all realize that when the big dogs get around to their turn at
reviewing things after the release is out it might all have to be
redone from scratch, it seems like there could be significant benefit
at low risk.
-Kevin
Import Notes
Resolved by subject fallback
Kevin Grittner wrote:
Other posts have suggested that "review fests" might be helpful in
this period. Again, it sounds to me, from other posts on this
thread, as though the primary risk is that people working on the
release could see something they couldn't resist getting drawn into
-- taking them off-task and delaying the release. The obvious
solution to that would be to create a pgsql-journeyman-peer-review
list for review fests during the release window.
Be careful, you're wandering quickly down the classic path by which
you'll find yourself in charge of doing some work here.
I think it's completely reasonable to say that someone could organize
pgsql-rrreviewers (as an initial working area, maybe another list
eventually) for periodic ReviewFest during periods where those patches
won't be considered for commit, such as beta. Now that most patch
submitters have gotten used to doing a matching bit of peer review, the
pool of people to do the reviews is there without having to pull anyone
else into that. I could even see the rrreviewers list or another one
split out of it grow into a somewhat gentler place for people to ask for
help with their patch development too--just ban all the grumpy people
from there (I'll unsubscribe myself). The important thing is that
everyone would need to careful to respect not letting that spill over
onto this list during the periods there is no official CommitFest going
on, or there will be a net increase in said grumpy people.
Looking at stats here for the recent CFs, about 40% of patches submitted
are returned with feedback (or rejected) rather than being committed
anyway. And I'm estimating that >80% of patches only reach comittable
after a round of review+corrections first. Getting a lot of that work
out of the way outside of the regular CF seems a worthwhile goal.
Starting the first CommitFest of the next version (normally a quite
painful one) with a set of patches already marked "Ready for Committer"
or pruned out with feedback already, all because they've been through a
round or two of initial review, would be a nice improvement. Just drop a
summary of what's been done onto pgsql-hackers once the CF opens again
for the ones still in the running and off you go. The existing CF app
could be used to track the early review work too, so someone who wasn't
on pgsql-rrreviewers could dig into the archives to catch up in a few
minutes by following the message ID links. I do that all the time for
patches I had previously been ignoring and deleting out of my mailbox.
--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.com
Greg Smith <greg@2ndquadrant.com> wrote:
Kevin Grittner wrote:
Other posts have suggested that "review fests" might be helpful
in this period. Again, it sounds to me, from other posts on this
thread, as though the primary risk is that people working on the
release could see something they couldn't resist getting drawn
into -- taking them off-task and delaying the release. The
obvious solution to that would be to create a
pgsql-journeyman-peer-review list for review fests during the
release window.Be careful, you're wandering quickly down the classic path by
which you'll find yourself in charge of doing some work here.
Worse things could happen. ;-)
I've shied away from stepping up to bigger commitments here because
of family situations which can make unpredictable demands on my
time; however, those seem to have settled down somewhat in recent
months, so I might venture such a commitment.
I think it's completely reasonable to say that someone could
organize pgsql-rrreviewers (as an initial working area, maybe
another list eventually) for periodic ReviewFest during periods
where those patches won't be considered for commit, such as beta.
Now that most patch submitters have gotten used to doing a
matching bit of peer review, the pool of people to do the reviews
is there without having to pull anyone else into that. I could
even see the rrreviewers list or another one split out of it grow
into a somewhat gentler place for people to ask for help with
their patch development too--just ban all the grumpy people from
there (I'll unsubscribe myself).
LOL.
The important thing is that everyone would need to careful to
respect not letting that spill over onto this list during the
periods there is no official CommitFest going on, or there will be
a net increase in said grumpy people.
Understood.
Looking at stats here for the recent CFs, about 40% of patches
submitted are returned with feedback (or rejected) rather than
being committed anyway. And I'm estimating that >80% of patches
only reach comittable after a round of review+corrections first.
Getting a lot of that work out of the way outside of the regular
CF seems a worthwhile goal.Starting the first CommitFest of the next version (normally a
quite painful one) with a set of patches already marked "Ready for
Committer" or pruned out with feedback already, all because
they've been through a round or two of initial review, would be a
nice improvement. Just drop a summary of what's been done onto
pgsql-hackers once the CF opens again for the ones still in the
running and off you go. The existing CF app could be used to track
the early review work too, so someone who wasn't on
pgsql-rrreviewers could dig into the archives to catch up in a
few minutes by following the message ID links. I do that all the
time for patches I had previously been ignoring and deleting out
of my mailbox.
I see all those benefits, plus the possibility of a few more subtle
but potentially significant ones.
What next?
-Kevin
On Mon, Jan 25, 2010 at 12:01 PM, Greg Smith <greg@2ndquadrant.com> wrote:
I think it's completely reasonable to say that someone could organize
pgsql-rrreviewers (as an initial working area, maybe another list
eventually) for periodic ReviewFest during periods where those patches won't
be considered for commit, such as beta. Now that most patch submitters have
gotten used to doing a matching bit of peer review, the pool of people to do
the reviews is there without having to pull anyone else into that. I could
even see the rrreviewers list or another one split out of it grow into a
somewhat gentler place for people to ask for help with their patch
development too--just ban all the grumpy people from there (I'll unsubscribe
myself). The important thing is that everyone would need to careful to
respect not letting that spill over onto this list during the periods there
is no official CommitFest going on, or there will be a net increase in said
grumpy people.
I kind of like the ideal of a pgsql-fledgling-hackers list (that's
intended to describe the charter, not that we'd necessarily call it
that) as a space for people to ask novice development questions (as
opposed to novice user questions).
I'm less certain I like the idea that some part of patch review is
going to happen off of pgsql-hackers. If people like Tom, Bruce,
Peter, and Heikki are not reading the list where this review is
happening (whether it's pgsql-rrreviewers, pgsql-fledgling-hackers, or
otherwise), it may not actually be very successful in helping people
move their patches forward. Issues that are discussed and resolved in
that forum will very possibly get brought up again on -hackers and
reach a different conclusion the second time around. Now if people
are OK with that, maybe it's OK: but I have a feeling that could be
even more frustrating than the system we have now.
I am in favor of having a ReviewFest if we go too long without being
able to have a CommitFest, but I would personally prefer to see it
happen on -hackers. I wouldn't argue for scheduling a ReviewFest as
soon as March, because I think we really do need to allow some time
and resources for resolving open issues, and I think having another
CommitFest so soon will distract from that. But later on in the
release cycle, I think it would make sense - the work that can be done
by people other than Tom and Bruce and Peter and whoever the other big
guns are is going to be mostly done by then. I suspect that a
ReviewFest in, say, May would give us a useful jump on 9.1 development
without having much impact on getting 9.0 out the door.
...Robert
Robert Haas <robertmhaas@gmail.com> wrote:
Issues that are discussed and resolved in that forum will very
possibly get brought up again on -hackers and reach a different
conclusion the second time around. Now if people are OK with
that, maybe it's OK
I would expect that. Heck, people get that to some degree posting
twice to hackers, depending on who pays how much attention each
time. To some extent it would depend on how far those doing the
reviews would stretch their limits to provide a good review, knowing
that someone might do a lot of work based on their advice before a
senior PostgreSQL developer will put eyes on it. The expansion of
the talent pool that could result is one of the possible "hidden
benefits" which might accrue. Other possible benefits could come
from simple "sounding board" discussions, non-critical
"brainstorming" rounds of discussion, and the synergy of disparate
views.
Of course, all this assumes that people maintain the appropriate
demeanor and put some thought and effort into their posts.
but I have a feeling that could be even more frustrating than the
system we have now.
Possibly. We'd certainly need prominent caveats, so that people had
the right expectations going in.
-Kevin