Re: commit fests (was Re: primary key error message)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: commit fests (was Re: primary key error message)
Дата
Msg-id 603c8f071001211645i492a6cc4kf54586e9a7dbcec@mail.gmail.com
обсуждение исходный текст
Ответ на commit fests (was Re: primary key error message)  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: commit fests (was Re: primary key error message)  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Takahiro Itagaki
Дата:
Сообщение: Re: About "Our CLUSTER implementation is pessimal" patch
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: warn in plperl logs as... NOTICE??