Re: [HACKERS] 6.6 release

From: wieck(at)debis(dot)com (Jan Wieck)
To: scrappy(at)hub(dot)org (The Hermit Hacker)
Cc: vev(at)michvhf(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgman(at)candle(dot)pha(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] 6.6 release
Date: 1999-12-10 15:03:27
Message-ID: m11wRZv-0003kGC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Marc G. Fournier wrote:

> when we do up Release 7, which I'd like to make this one, I'd *love* to
> make this a whole-hog thing...tag/branch things as REL_7, no minor
> number...then its up to the developers to decide whether something is
> back-patchable (like they've been doing up until now) with a periodic
> release put out while Release 8 is being worked on.

I would really appreceate that. Maybe we need to go ahead in
this manner and make more use of CVS branching.

We have long standing TODO items, which require co work of
multiple developers, affect alot of the code and will take a
long time to implement. Tuple split, fmgr redesign, parsetree
overhaul to name some.

Especially the fact that noone can do them alone IMHO
requires to have a separate branch, where the sources can
stay broken for some time. For example if we change the
parsetree representation, we first change the parser and look
at the printed output's until it fits. Then work on the
planner to get them running and parallel enhance the rewriter
to integrate it again. During this time, the parser will
generate things that may make the entire system unusable, so
any other development would get stuck.

I don't think that all problems could be tackled at once. My
idea is to analyze one of these problems in depth, then
branch off and have the developers, required to get this item
done, doing it separated there. The final result will be a
patch based on an older release, that requires some manual
work to get it merged into the current tree, of course. The
benefit would be, that this long term development would not
be interfered by CURRENT improvements, nor will it delay any
subsequent releasing of funny, neat things.

Just an idea.

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) #

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-12-10 15:06:53 Re: [HACKERS] 6.6 release
Previous Message Tom Lane 1999-12-10 14:59:27 Re: [HACKERS] 6.6 release