Re: Time-based Releases WAS: 8.5 release timetable, again

On Tue, Sep 8, 2009 at 2:06 PM, Ron Mayer<rm_pg(at)cheapcomplexdevices(dot)com> wrote:
> Andrew Dunstan wrote:
>> In any case, I don't accept this analogy. The mechanics of a Linux
>> distribution are very different from the mechanics of a project like
>> PostgreSQL. The prominent OSS project that seems to me most like ours is
>> the Apache HTTP project.
>
> I'd think that File Systems might be more like postgres - with a shared
> obsession about data loss risks, and concerns about compatibility
> with any on-disk format changes.   I wonder if the ext4 or btrfs
> guys use time-based release schedules, or if they'll release when
> it's ready.  I see the ZFS guys have target dates for completing
> features that are still in beta, but also that they change as needed.[1]
> [1] http://opensolaris.org/os/project/zfs-crypto/
>
> Anyone know how the F/OSS filesystem guys schedule their releases?
>
>
> I agree it's quite different than a distro - which, if I understand
> correctly, is mostly a matter of identifying completed and stable
> features rather than completing and stabilizing features.
>
>> I would argue that it would be an major setback for us if we made
>> another release without having Hot Standby or whatever we are calling it
>> now. I would much rather slip one month or three than ship without it.
>
> Perhaps if sufficiently interesting features get in outside of
> a time-based schedule, an extra release could be made after the
> commit fest it gets in?
>
> If hot-standby + streaming-replication + index_only_scans +
> magic-fairy-dust-powered-shared-nothing-clusters all happened
> to get in 3 months after a time-based release, it'd be nice to
> see it sooner rather than waiting 9 months for a time-based window.

That's somewhat true, but major patches are also more likely to come
with bugs. I think we ought to try to time major patches near the
beginning of the release cycle, not the end. Indeed, I'd be much more
inclined to support a proposal to branch the tree and do an
out-of-sequence release just BEFORE committing a bunch of major
features rather than just after. Otherwise, PostgreSQL's reputation
for being a solid product with solid releases will suffer.

...Robert