For planning purposes, I think its always a good idea to lay down some
dates for the next lot of development milestones. These can be
provisional, until declared solid later.

So: When is the next Feature Freeze?

Is it March 31? If not, when?

I know the answer is "too early to tell for certain", but what will it
be if we release in early Dec/early Jan, or whenever.

If we really are very uncertain, lets at least say it will be "Not
Before DateX". PPPPPPP and all that.

AFAICS, more than 50% of the patches are written by professional
developers, so our various sponsors need to know when the next release
is due. Kinda. Ish.

Thank you.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On Mon, 22 Oct 2007 19:43:28 +0100
Simon Riggs <simon@2ndquadrant.com> wrote:

> For planning purposes, I think its always a good idea to lay down some
> dates for the next lot of development milestones. These can be
> provisional, until declared solid later.

We can't not realistically consider this until we at least come up with
a release date for 8.3.

I seem to recall that we were originally going to release 8.3 in June.

Jsohua D. Drake


>
> So: When is the next Feature Freeze?
>
> Is it March 31? If not, when?
>
> I know the answer is "too early to tell for certain", but what will it
> be if we release in early Dec/early Jan, or whenever.
>
> If we really are very uncertain, lets at least say it will be "Not
> Before DateX". PPPPPPP and all that.
>
> AFAICS, more than 50% of the patches are written by professional
> developers, so our various sponsors need to know when the next release
> is due. Kinda. Ish.
>
> Thank you.
>


--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHHPG4ATb/zqfZUUQRAn3vAJ9Yz0M2WUkHk/VqIQrGX58G3ooCMACeN1bJ
sjKKmTFHjt9h5eX7uVRF8xQ=
=TLnq
-----END PGP SIGNATURE-----

On Mon, 2007-10-22 at 11:53 -0700, Joshua D. Drake wrote:
> On Mon, 22 Oct 2007 19:43:28 +0100
> Simon Riggs <simon@2ndquadrant.com> wrote:
>
> > For planning purposes, I think its always a good idea to lay down some
> > dates for the next lot of development milestones. These can be
> > provisional, until declared solid later.
>
> We can't not realistically consider this until we at least come up with
> a release date for 8.3.

There's always a way of planning through unknowns.

We can issue a provisional date. We could also say "at least 6 months
after release date of 8.3". I'm sure there's other options too.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Simon,

> We can issue a provisional date. We could also say "at least 6 months
> after release date of 8.3". I'm sure there's other options too.

I'm going to suggest 4 months after 8.3. 8.3 was supposed to be a *short*
release so that we could move our calendar around. HOT and some of the
other unexpected massive patches prevented that. Again, we have enough in
the "deferred for 8.4" queue that if we finished up only that it would
qualify as a release.

So my thought is, shoot for a short release so that we can get away from
summer consolidations and December releases, and extend the cycle if
someone dumps another 50,000 lines of attractive patches on us.

In fact, I could see doing a "no-catalog-changes, no major patches we don't
already know about, 6-month release". It would reset our cycle and get
PL/proxy, DSM, clustered indexes, etc. out the door. It could mean
turning away patches which look attractive, though, so the whole community
has to be into this.

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Josh Berkus wrote:
> So my thought is, shoot for a short release so that we can get away from
> summer consolidations and December releases, and extend the cycle if
> someone dumps another 50,000 lines of attractive patches on us.
>
>

Before we settle on any dates I think we should have some discussion
about how we can shorten the period between feature freeze and beta,
which was far too long this time. Perhaps we need to be more aggressive
about what what makes the cut and what doesn't.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Josh Berkus wrote:

> In fact, I could see doing a "no-catalog-changes, no major patches we don't
> already know about, 6-month release". It would reset our cycle and get
> PL/proxy, DSM, clustered indexes, etc. out the door. It could mean
> turning away patches which look attractive, though, so the whole community
> has to be into this.

Ah, you mean like we planned for 8.0 and failed, then for 8.1 and
failed, then for 8.2 and failed, then for 8.3 and failed? I can
definitely support that idea.

--
Alvaro Herrera Developer, http://www.PostgreSQL.org/
"We are who we choose to be", sang the goldfinch
when the sun is high (Sandman)

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On Mon, 22 Oct 2007 16:47:41 -0300
Alvaro Herrera <alvherre@commandprompt.com> wrote:

> Josh Berkus wrote:
>
> > In fact, I could see doing a "no-catalog-changes, no major patches
> > we don't already know about, 6-month release". It would reset our
> > cycle and get PL/proxy, DSM, clustered indexes, etc. out the
> > door. It could mean turning away patches which look attractive,
> > though, so the whole community has to be into this.
>
> Ah, you mean like we planned for 8.0 and failed, then for 8.1 and
> failed, then for 8.2 and failed, then for 8.3 and failed? I can
> definitely support that idea.
>
As I recall 8.0 and 8.1 actually went pretty well.

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHHP/OATb/zqfZUUQRAjqiAKCiLYZtu6B3tOtWCX37dVmfAEr1HwCfWLDn
szVFueazf8jEo43WJx7pcBY=
=4Q/q
-----END PGP SIGNATURE-----

"Joshua D. Drake" <jd@commandprompt.com> writes:
> Alvaro Herrera <alvherre@commandprompt.com> wrote:
>> Ah, you mean like we planned for 8.0 and failed, then for 8.1 and
>> failed, then for 8.2 and failed, then for 8.3 and failed? I can
>> definitely support that idea.
>>
> As I recall 8.0 and 8.1 actually went pretty well.

I don't recall any such plans for those releases, but certainly Josh's
proposal is *EXACTLY* what the plan was for 8.3, and look how well we
adhered to that one.

In point of fact, the big patches that aren't in 8.3 were rejected
because they weren't ready. They won't get into 8.4, either, unless
someone does a lot more work on them. So I don't follow this idea
of how we have a pre-loaded queue of good stuff all ready to go into
8.4. We thought that was true for the 8.3 cycle, which it wasn't,
but there isn't even any basis to think that about 8.4.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> In point of fact, the big patches that aren't in 8.3 were rejected
> because they weren't ready. They won't get into 8.4, either, unless
> someone does a lot more work on them. So I don't follow this idea
> of how we have a pre-loaded queue of good stuff all ready to go into
> 8.4. We thought that was true for the 8.3 cycle, which it wasn't,
> but there isn't even any basis to think that about 8.4.

Incidentally what big features do we have in progress?

I see:

.. GII - there's been discussion about some kind of refactoring the index api
to avoid the layer violations here.

.. Bitmap Indexes - needs a design review and probably changes
possibly needs the same api refactoring as GII

.. DSM - I think Heikki's idea to implement the storage via the buffer manager
so it doesn't have fixed size storage limitations like the FSM is a
good one

.. Recursive Queries - I haven't really started the meat of it but wouldn't
mind feedback on the outline I posted a while back

There are some more in the developer.postgresql.org patch status page but I'm
not too familiar with what's missing for those.

It does seem like most of these are blocked waiting on ideas rather than SMOP
issues, so I'm not sure counting on them to be ready on a particular schedule
is going to be especially safe. Of course the ideas are more likely to come
once we start discussing the issues. I imagine everyone's focused on the beta
right now.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

josh@agliodbs.com (Josh Berkus) writes:
> Simon,
>
>> We can issue a provisional date. We could also say "at least 6 months
>> after release date of 8.3". I'm sure there's other options too.
>
> I'm going to suggest 4 months after 8.3. 8.3 was supposed to be a *short*
> release so that we could move our calendar around. HOT and some of the
> other unexpected massive patches prevented that. Again, we have enough in
> the "deferred for 8.4" queue that if we finished up only that it would
> qualify as a release.
>
> So my thought is, shoot for a short release so that we can get away from
> summer consolidations and December releases, and extend the cycle if
> someone dumps another 50,000 lines of attractive patches on us.
>
> In fact, I could see doing a "no-catalog-changes, no major patches we don't
> already know about, 6-month release". It would reset our cycle and get
> PL/proxy, DSM, clustered indexes, etc. out the door. It could mean
> turning away patches which look attractive, though, so the whole community
> has to be into this.

There are good things about that idea.

There would also be good things about picking a somewhat *longer*
cycle in that we already just had a cycle where the "feature freeze"
period was supposedly a short one, which precluded implementing
anything requiring more planning.

- It seems at least somewhat unfair to burden the 8.4 cycle with the
"sins" of the 8.3 cycle.

- There is the risk that even with the restriction, 8.4 might still
not be a short cycle, which would make the attempt futile.

- And would we then say "hey, we need for 8.5 to have a shortened
cycle too"?
--
(reverse (concatenate 'string "ofni.secnanifxunil" "@" "enworbbc"))
http://linuxfinances.info/info/multiplexor.html
Space is big. Really big. You won't believe how vastly
mind-bogglingly big it is. I mean, you may think it's a long way down
the road to the chemist, but that's just peanuts to space. Listen....