Re: Formatting Curmudgeons WAS: MMAP Buffers

Поиск
Список
Период
Сортировка
От Christopher Browne
Тема Re: Formatting Curmudgeons WAS: MMAP Buffers
Дата
Msg-id BANLkTimrVC-Aqh4nVoSMyE+LojS3oN3M2g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Formatting Curmudgeons WAS: MMAP Buffers  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Thu, Apr 21, 2011 at 11:05 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> I agree.  I am in favor of a shorter release cycle.  But I think that
> a shorter release cycle won't work well if there is still four month
> long integration period at the end of each series of CommitFests.  The
> problem is a bit circular here: because release cycles are long,
> people really, really want to slip as much as possible in at the end.
> But being under time pressure to get things committed results in a
> higher bug count, which means more things that have to be fixed after
> feature freeze, which translates into a long release cycle.

If we somehow were able to come up with a 6 week release cycle, we'd
still have the problem that there are features that take more than 6
weeks to integrate into a release.  (HOT and SyncRep, I'm looking at
you!) Any such larger features would "blow this up," quite forcibly.

I don't think our release cycle is vastly too long; it takes enough
time to plan upgrades for systems that my colleagues at Afilias aren't
keen on using every PG release in production that comes out as it
stands now.

Peter Eisentraut points out that with the way things are, now,  "...
you are left with all of about 20 days per year for discussion,
collaborative planning and coding.  Which is obviously silly, which is
why the process breaks down."

I think the CommitFests have been a *super* tool for addressing such
problems as:
- patches getting lost
- getting review effort put onto the easier patches

But they aren't the only thing we conceptually need to have.  For
tougher features, they're not great.  And they're completely useless
at addressing discussions surrounding things we know we want done, but
don't have a strategy for yet.  Those things aren't "patches", there's
nothing yet to commit.

My sense is that something else is needed as a process to help with
those "nebulous large changes."  I'm not sure quite what it looks
like.  Maybe there's some tooling that would be helpful, but we really
need some experimentation to figure out what the process should look
like.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: my signature
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: EOL for 8.2 (was Re: Formatting Curmudgeons WAS: MMAP Buffers)