Thread: 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.

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
allowedto creep in still. 

Seems to me we can have discussion anytime, though a given patch might get more or less discussion at various times.
Butclearly 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 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.

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

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.php
>
> 3 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
stillenjoy 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 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?

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