Re: [HACKERS] When is 7.0 going Beta?

Bruce Momjian wrote:

> OK, seeing as everyone disagrees with me...

BADDAY.MPG?

Wasn't that I completely disagreed. Just that in the actual
case, I don't think we can make another release out of the
current tree. And about that I'm not alone.

> Other than WAL, what else is half-completed and installed?
>
> Foreign Keys - Jan
> WAL - Vadim
> Function args - Tom
> Date/Time types - Thomas
> Optimizer - Tom
>
> Outer Joins - Thomas?
> Long Tuples - ?
>
> I guess I am wondering, other than WAL, what makes our current state
> any worse than the time before previous beta cycles

At least FK. Just found myself a bug that makes things ugly.
Forces CKECK lookup in PK table even if FK values didn't
change on trigger invocation - otherwise someone could cause
RI violation not recognized by deleting DEFAULT key values of
FK from PK table.

That's IMHO something so easily to trigger, that I expect
more bugs in the stuff.

Since FOREIGN KEY is a feature so many ppl asked for, I
expect many of them penetrating the lists if things go bad -
what's really possible for now. Thus, I wouldn't feel
comfortable if it goes out in this state.

> I am very hesitant about our "one big release" thing coming? If we wait
> for everything to get done, we would never have a release.
>
> The more items in a release, the longer the beta cycle. If you wait too
> long, you are fixing code you wrote 6 months ago, and that makes it very
> hard. Smaller releases where the code is relatively fresh and the
> additional features minimal are cleaner, faster betas.

Hmmm,

yes and no. Yes, the more items the longer beta. But no, the
longer beta the better the release.

The last release had the longest of all beta delays. And it
was the best of all releases. Maybe because while feature A
prevents release, another bug in feature H shows up while B-G
are silent, but after fixing H's bug F shout's "stop". Not
surprising - (real) programmers experience.

The worst thing we can do is to release FEATURES, that are
current development state and must be deprecated because they
interfere with ongoing development. I just saw that someone
added some kind of subselect inside or the targetlist - and I
absolutely don't know if that will stand the test of time
(i.e. issues WRT the rewriter MIGHT be more important). So
that syntax might need to be removed/changed in 7.0 or a
subsequent release again.

> The concern about a release sapping our energy when we should be adding
> code is valid, but this delays how soon users can use the items we
> _have_ finished.

I don't see any (of the important) issues finished.

> Obviously, no one agrees with me, so it looks like May.

At least not me.

May? Vadim said he could probably come back to finish WAL by
April/May. And I'm so bored about the tuple split stuff up
to now, that I don't know if I should start on it for 7.0
right now. So May (optimistic) might be start of BETA - not
release.

And AFAIK, if we start beta that long after our last release,
the next wouldn't be out before July.

That would give me enough time for the other thing (Bruce
knows what I'm talking about).

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #