Robert Haas <robertmhaas@gmail.com> writes:
>> read up-thread, i've already shown that this would not be the case. remember,
>> we reduce the pressure from the large, complex patches that bottleneck the
>> process, which allows more parralell review/commit.
>
> I read what you wrote - I just don't believe it. My own experience is
> that doing more releases is more work.
Yeah, more releases than once a year is kind of crazy.
> Also, two commitfests per release means that if you can't get your patch up
> to snuff in two iterations, you're bumped.
I wish we could get rid of the whole concept and stigma of being "bumped" your
patch will be released in the next release after it's committed. What does it
matter if there's been another release since you started or not?
ISTM there are two ways to make the release step take less time. Either we
sacrifice quality or we change the development process so more testing and
review happens during development. I see the latter as realistic if we hold
off committing (but not reviewing) any major patches submitted after
commitfest#1 until the next commitfest#1. That means when it comes time to
release there won't be any major changes in it that people haven't had months
to experiment with already.
I would still like an answer to my question about what steps there are that
take so many months for a release, but I expect most of them boil down to
(justified) paranoia about testing major features that people haven't already
tested outside of development environments.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production
Tuning
