On 1 May 2015 at 18:05, Simon Riggs si...@2ndquadrant.com wrote:
* TABLESAMPLE clause
Doesn't seem very far from being done. Some questions about including
(or not) DDL and contrib modules seem to remain.
Will commit this soon
OK, completely happy with this now and will commit
On 2015-05-01 18:37:23 +0200, Andres Freund wrote:
* Multivariate statistics
This is not intended to be committed this CF.
= I'd like to mark this as returned with (little) feedback.
* Avoiding plan disasters with LIMIT
I'm not enthused by the approach, it's disabled by default though.
On Fri, May 1, 2015 at 1:16 PM, Stephen Frost sfr...@snowman.net wrote:
We really need to segregate the two.. By that what I mean is this: I
want an always-open bugfix CF, which allows us to keep track of
bugfix patches. Having something about applies to versions X, Y, Z
would be nice too...
On Tue, May 5, 2015 at 3:47 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, May 1, 2015 at 1:16 PM, Stephen Frost sfr...@snowman.net wrote:
We really need to segregate the two.. By that what I mean is this: I
want an always-open bugfix CF, which allows us to keep track of
bugfix
2015-05-02 1:37 GMT+09:00 Andres Freund and...@anarazel.de:
* ctidscan as an example of custom-scan
Hasn't really gotten sufficient review.
= Move
I have to agree.
* Join pushdown support for foreign tables
Hasn't gotten particularly much review yet. And it doesn't look
entirely
On Fri, May 1, 2015 at 5:27 PM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
Also as I've pointed out, it's not even clear that there is a regression
at all, since I've already shown that changes of several percent in
timings of sort operations can be caused by irrelevant noise factors.
To
Andres == Andres Freund and...@anarazel.de writes:
Andres * Abbreviated key support for Datum sorts
Andres Unfortunately the discussion about potential performance
Andres regression has been largely sidestepped by bickering over
Andres minutiae.
Andres = ?
There isn't a potential
On Fri, May 1, 2015 at 10:07 PM, Andres Freund and...@anarazel.de wrote:
On 2015-04-30 08:39:45 -0400, Peter Eisentraut wrote:
If you have spare cycles, there are a number of relevant patches still
open in the commit fest.
I was wondering what the actual state of the commitfest is. I'm
On 01/05/15 18:37, Andres Freund wrote:
I was wondering what the actual state of the commitfest is. I'm thus
going through all the open items. Here's my thoughts:
Cool.
* Sequence Access Method
There's been some back and forth between Petr and Heikki on this
lately.
= Maybe there's
On 2015-04-30 08:39:45 -0400, Peter Eisentraut wrote:
If you have spare cycles, there are a number of relevant patches still
open in the commit fest.
I was wondering what the actual state of the commitfest is. I'm thus
going through all the open items. Here's my thoughts:
* fsync $PGDATA
On 2015-05-01 13:05:19 -0400, Simon Riggs wrote:
On 1 May 2015 at 12:37, Andres Freund and...@anarazel.de wrote:
* fastbloat
Not too big, I think it should be easy to commit this.
= Keep in 'ready for committer'
Will commit soon
Cool.
* Allow snapshot too old error, to prevent
Andres,
* Andres Freund (and...@anarazel.de) wrote:
On 2015-04-30 08:39:45 -0400, Peter Eisentraut wrote:
If you have spare cycles, there are a number of relevant patches still
open in the commit fest.
I was wondering what the actual state of the commitfest is. I'm thus
going through all
- Original Message -
From: Stephen Frost sfr...@snowman.net
To: Andres Freund and...@anarazel.de
Cc: Peter Eisentraut pete...@gmx.net; pgsql-hackers
pgsql-hackers@postgresql.org
Sent: Friday, May 1, 2015 12:16 PM
Subject: Re: [HACKERS] feature freeze and beta schedule
Andres
On Fri, May 1, 2015 at 9:37 AM, Andres Freund and...@anarazel.de wrote:
* Abbreviated key support for Datum sorts
Unfortunately the discussion about potential performance regression
has been largely sidestepped by bickering over minutiae.
= ?
There really is no discussion about
On 1 May 2015 at 12:37, Andres Freund and...@anarazel.de wrote:
* fastbloat
Not too big, I think it should be easy to commit this.
= Keep in 'ready for committer'
Will commit soon
* Turning off HOT for larger SQL queries
Seems to have degenerated into a discussion of not really
On 2015-05-01 09:49:50 -0700, Peter Geoghegan wrote:
On Fri, May 1, 2015 at 9:37 AM, Andres Freund and...@anarazel.de wrote:
* Abbreviated key support for Datum sorts
Unfortunately the discussion about potential performance regression
has been largely sidestepped by bickering over
Stephen Frost sfr...@snowman.net wrote:
Andres Freund (and...@anarazel.de) wrote:
* Allow snapshot too old error, to prevent bloat
http://archives.postgresql.org/message-id/1361166406.1897609.1424371443904.JavaMail.yahoo%40mail.yahoo.com
talked about a new version that afaics never
The schedule
https://wiki.postgresql.org/wiki/PgCon_2014_Developer_Meeting#9.5_Schedule
calls for beta in June. In light of that, the core team has agreed to
call for
feature freeze on May 15
That means that all patches that add or change features should be
committed by then.
If you have
On 4/30/15 12:01 PM, Robert Haas wrote:
So generally we have stamped in late April or early May and released
in September, but last year we didn't release until December. I
assume that if we stamp beta1 in June instead of May, that's going to
somewhat delay the final release as well, but I'm
On Thu, Apr 30, 2015 at 12:52 PM, Peter Eisentraut pete...@gmx.net wrote:
On 4/30/15 12:01 PM, Robert Haas wrote:
So generally we have stamped in late April or early May and released
in September, but last year we didn't release until December. I
assume that if we stamp beta1 in June instead
On Fri, May 1, 2015 at 1:55 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Apr 30, 2015 at 12:52 PM, Peter Eisentraut pete...@gmx.net wrote:
On 4/30/15 12:01 PM, Robert Haas wrote:
So generally we have stamped in late April or early May and released
in September, but last year we didn't
On Thu, Apr 30, 2015 at 8:39 AM, Peter Eisentraut pete...@gmx.net wrote:
The schedule
https://wiki.postgresql.org/wiki/PgCon_2014_Developer_Meeting#9.5_Schedule
calls for beta in June. In light of that, the core team has agreed to
call for
feature freeze on May 15
That means that all
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Just throwing out a crazy idea. What if we had a commitfest as
scheduled at the start of May but made it a Tom-free commitfest.
Specifically to try to organize a larger work-force rather than to
leave it all on Tom's shoulders. Not
We are down to 12 feature freeze items (240 emails):
http://momjian.us/cgi-bin/pgpatches
Most are not ready to apply but require feedback to the author.
--
Bruce Momjian [EMAIL PROTECTED]http://momjian.us
EnterpriseDB http://enterprisedb.com
Bruce,
We are down to 12 feature freeze items (240 emails):
http://momjian.us/cgi-bin/pgpatches
Most are not ready to apply but require feedback to the author.
Yaaay!
Maybe we should make the next commit-fest June 1 to give people some time
off? And some time to improve the tools?
Josh Berkus wrote:
Bruce,
We are down to 12 feature freeze items (240 emails):
http://momjian.us/cgi-bin/pgpatches
Most are not ready to apply but require feedback to the author.
Yaaay!
Maybe we should make the next commit-fest June 1 to give people some time
off? And
On Mon, 7 Apr 2008 14:31:51 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Maybe we should make the next commit-fest June 1 to give people
some time off? And some time to improve the tools?
Agreed.
+1
Joshua D. Drake
--
The PostgreSQL Company since 1997:
Josh Berkus wrote:
Maybe we should make the next commit-fest June 1 to give people some time
off? And some time to improve the tools?
I would rather do the commit fests often, to keep the patch queue and
the commit fests short.
--
Heikki Linnakangas
EnterpriseDB
[EMAIL PROTECTED] (Heikki Linnakangas) writes:
Josh Berkus wrote:
Maybe we should make the next commit-fest June 1 to give people some
time off? And some time to improve the tools?
I would rather do the commit fests often, to keep the patch queue and
the commit fests short.
But if it means
Chris Browne wrote:
[EMAIL PROTECTED] (Heikki Linnakangas) writes:
Josh Berkus wrote:
Maybe we should make the next commit-fest June 1 to give people some
time off? And some time to improve the tools?
I would rather do the commit fests often, to keep the patch queue and
the
Heikki Linnakangas [EMAIL PROTECTED] writes:
Josh Berkus wrote:
Maybe we should make the next commit-fest June 1 to give people some time
off? And some time to improve the tools?
I would rather do the commit fests often, to keep the patch queue and the
commit fests short.
Just throwing
Bruce Momjian [EMAIL PROTECTED] writes:
Josh Berkus wrote:
Maybe we should make the next commit-fest June 1 to give people some time
off? And some time to improve the tools?
Agreed.
I don't agree, not even a little bit. The reason this fest has been so
long and painful is that the queue
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Josh Berkus wrote:
Maybe we should make the next commit-fest June 1 to give people some time
off? And some time to improve the tools?
Agreed.
I don't agree, not even a little bit. The reason this fest has been so
long and
Gregory Stark [EMAIL PROTECTED] writes:
Just throwing out a crazy idea. What if we had a commitfest as scheduled at
the start of May but made it a Tom-free commitfest. Specifically to try to
organize a larger work-force rather than to leave it all on Tom's shoulders.
Not that your efforts
On Mon, 7 Apr 2008 22:05:09 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Better tools would be good, but unless someone commits to producing
a tool that will be ready by June but not by May, that's not a good
reason to slide either.
Fine with me --- I just wanted to give Tom a
Can I ask when the Feature Freeze for next release will be?
Last time we discussed this the only date mentioned was end-March-2008,
which is less than 2 months away now.
We've long expressed the wish to move development onto a cycle that ends
in the Spring, so next alternative would appear to
On Feb 5, 2008 8:57 PM, Simon Riggs [EMAIL PROTECTED] wrote:
Can I ask when the Feature Freeze for next release will be?
I shall be posting on this topic in the next day or so.
/D
---(end of broadcast)---
TIP 6: explain analyze is your friend
Wouldn't seeing which patches are trickling in during the first months
of 8.4 development give a better indication of when it should be
freezable? I'm all in favor of having lots of advance notice and
predictable schedules --- but it seems in the next month or so we'll
have a lot more insight of
Simon Riggs wrote:
Can I ask when the Feature Freeze for next release will be?
Also, from http://www.postgresql.org/about/press/faq
Q: When will 8.4 come out?
A: Historically, PostgreSQL has released approximately
every 12 months and there is no desire in the community
to
On Tue, 05 Feb 2008 13:56:48 -0800
Ron Mayer [EMAIL PROTECTED] wrote:
Simon Riggs wrote:
Can I ask when the Feature Freeze for next release will be?
Also, from http://www.postgresql.org/about/press/faq
Q: When will 8.4 come out?
A: Historically, PostgreSQL has released
Ron Mayer [EMAIL PROTECTED] writes:
Simon Riggs wrote:
Can I ask when the Feature Freeze for next release will be?
Also, from http://www.postgresql.org/about/press/faq
Q: When will 8.4 come out?
A: Historically, PostgreSQL has released approximately
every 12 months and there is
Tom,
This seems pretty entirely orthogonal to the commit-fest proposal.
I see no reason to think that snapshots taken at those times would
be any better than any other nightly snapshot, nor any reason
to memorialize them in an archive.
I can see that. And it would be pretty hard to keep
On 10/25/07, Gregory Stark [EMAIL PROTECTED] wrote:
Huh, I hadn't heard of that either. The Debian package patchutils says it was
downloaded from:
http://cyberelk.net/tim/data/patchutils
What's really cool is that patchutils also appears to have the utility I've
been looking for for a
On Tue, Oct 23, 2007 at 07:24:21PM -0400, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Mind you, I'm in favor of one. A new SCM would make some other
development tasks easier. However, I'm reluctant to open the
can-of-worms which is the what SCM should we use discussion
again,
On Tue, 2007-10-23 at 16:19 -0700, Josh Berkus wrote:
Maybe. I'm looking for ways to increase the amount of development time
we have compared with time releasing. If we release twice as often, we
won't get twice the beta test contribution from everybody, so our code
will be less robust,
On Tue, 2007-10-23 at 19:42 -0400, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Plus, for the developers and other people who really need to be
bleeding-edge, this new plan would result in less-unstable snapshots every
2 months with defined feature sets which someone who wanted
The main problem with using Git on a much larger scale is that there's
still limited ability to use it on Win32. Google is working on that:
http://code.google.com/p/msysgit/ but it's not quite there yet; there's
also a partial MinGW port.
IIRC the official word from the git people is
On 10/24/07, Tom Lane [EMAIL PROTECTED] wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Mind you, I'm in favor of one. A new SCM would make some other development
tasks easier. However, I'm reluctant to open the can-of-worms which is the
what SCM should we use discussion again, and complicate
On 10/24/07, Magnus Hagander [EMAIL PROTECTED] wrote:
The main problem with using Git on a much larger scale is that there's
still limited ability to use it on Win32. Google is working on that:
http://code.google.com/p/msysgit/ but it's not quite there yet; there's
also a partial MinGW
On Wed, Oct 24, 2007 at 11:04:34AM +0300, Marko Kreen wrote:
On 10/24/07, Magnus Hagander [EMAIL PROTECTED] wrote:
The main problem with using Git on a much larger scale is that there's
still limited ability to use it on Win32. Google is working on that:
On 10/24/07, Magnus Hagander [EMAIL PROTECTED] wrote:
On Wed, Oct 24, 2007 at 11:04:34AM +0300, Marko Kreen wrote:
On 10/24/07, Magnus Hagander [EMAIL PROTECTED] wrote:
The main problem with using Git on a much larger scale is that there's
still limited ability to use it on Win32.
David Fetter wrote:
I'm not picking a DSCM. I'm saying we already have tools in place for
a DSCM *without* having a flag day. If Mercurial has a similar
migration/legacy support path, then by all means, let's try that out,
too. :)
There's at least on Mercurial repo, here:
Marko Kreen escribió:
As we seem discussing developement in general, there is one
obstacle in the way of individual use of DSCMs - context diff
format as only one accepted. Both leading DSCMs - GIT and Mercurial
do not support it.
Hmm, in Subversion you can specify a separate diff command
As we seem discussing developement in general, there is one
obstacle in the way of individual use of DSCMs - context diff
format as only one accepted. Both leading DSCMs - GIT and Mercurial
do not support it.
Really? I just started playing around with git, and the output from
git diff
Brendan Jurd escribió:
As we seem discussing developement in general, there is one
obstacle in the way of individual use of DSCMs - context diff
format as only one accepted. Both leading DSCMs - GIT and Mercurial
do not support it.
Really? I just started playing around with git, and
Alvaro Herrera write:
Marko Kreen escribió:
As we seem discussing developement in general, there is one
obstacle in the way of individual use of DSCMs - context diff
format as only one accepted. Both leading DSCMs - GIT and Mercurial
do not support it.
Hmm, in Subversion you can specify a
On 10/24/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Brendan Jurd escribió:
Really? I just started playing around with git, and the output from
git diff produced the same kind of diff file I would normally get from
`svn di`
... which is a unified diff.
or `cvs di -c`.
Huh, strange.
* Brendan Jurd [EMAIL PROTECTED] [071024 01:41]:
How up to date is the Git repos? Does it pull individual commits from
CVS, or does it resync the whole history periodically? If so, what's
the lag?
It's updated hourly, which is the same rate the public CVS is updated.
An important part of
On Tue, Oct 23, 2007 at 02:39:43PM -0700, David Fetter wrote:
The one below is already available, so we don't have to do a flag
day with it.
http://repo.or.cz/w/PostgreSQL.git
As someone who hasn't used GIT: if I have a modified CVS tree from some time
back (1 year) can I use this to manage
Aidan Van Dyk [EMAIL PROTECTED] writes:
* Brendan Jurd [EMAIL PROTECTED] [071024 01:41]:
How up to date is the Git repos? Does it pull individual commits from
CVS, or does it resync the whole history periodically? If so, what's
the lag?
It's updated hourly, which is the same rate the
On Wed, 2007-10-24 at 08:33 -0300, Alvaro Herrera wrote:
David Fetter wrote:
I'm not picking a DSCM. I'm saying we already have tools in place for
a DSCM *without* having a flag day. If Mercurial has a similar
migration/legacy support path, then by all means, let's try that out,
too.
Josh Berkus wrote:
Folks,
You are way ahead of us here. And my vote *still* goes to Mercurial, if
we're picking SCMs.
Will a new SCM actually make this easier, or are people just using it as an
excuse?
We use mercurial here at work, having switched to it recently, and while
I
Martijn van Oosterhout [EMAIL PROTECTED] writes:
On Tue, Oct 23, 2007 at 02:39:43PM -0700, David Fetter wrote:
The one below is already available, so we don't have to do a flag
day with it.
http://repo.or.cz/w/PostgreSQL.git
As someone who hasn't used GIT: if I have a modified CVS tree
On Tue, 2007-10-23 at 19:24 -0400, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Mind you, I'm in favor of one. A new SCM would make some other development
tasks easier. However, I'm reluctant to open the can-of-worms which is the
what SCM should we use discussion again, and
Marko Kreen [EMAIL PROTECTED] writes:
As we seem discussing developement in general, there is one
obstacle in the way of individual use of DSCMs - context diff
format as only one accepted.
Well, that's not a hard-and-fast rule, just a preference. At least for
me, unidiff is vastly harder to
On Wed, Oct 24, 2007 at 09:24:47AM -0400, Tom Lane wrote:
I don't recall that we've rejected any patches lately just because they
were unidiffs. But I'd be sad if a large fraction of incoming patches
started to be unidiffs.
We bounce them back to the author pretty m uch every time with
On Wed, 2007-10-24 at 14:32 +0200, Martijn van Oosterhout wrote:
On Tue, Oct 23, 2007 at 02:39:43PM -0700, David Fetter wrote:
The one below is already available, so we don't have to do a flag
day with it.
http://repo.or.cz/w/PostgreSQL.git
As someone who hasn't used GIT: if I have a
Tom Lane [EMAIL PROTECTED] writes:
Marko Kreen [EMAIL PROTECTED] writes:
As we seem discussing developement in general, there is one
obstacle in the way of individual use of DSCMs - context diff
format as only one accepted.
Well, that's not a hard-and-fast rule, just a preference. At least
On 10/24/07, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
As we seem discussing developement in general, there is one
obstacle in the way of individual use of DSCMs - context diff
format as only one accepted.
Well, that's not a hard-and-fast rule, just a
Marko Kreen wrote:
On 10/24/07, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
As we seem discussing developement in general, there is one
obstacle in the way of individual use of DSCMs - context diff
format as only one accepted.
Well, that's not a
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Oct 24, 2007 at 09:24:47AM -0400, Tom Lane wrote:
I don't recall that we've rejected any patches lately just because they
were unidiffs. But I'd be sad if a large fraction of incoming patches
started to be unidiffs.
We bounce them back to
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Oct 24, 2007 at 09:24:47AM -0400, Tom Lane wrote:
I don't recall that we've rejected any patches lately just because they
were unidiffs. But I'd be sad if a large fraction of incoming patches
started to be unidiffs.
We
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Oct 24, 2007 at 02:32:13PM +0200, Martijn van Oosterhout wrote:
On Tue, Oct 23, 2007 at 02:39:43PM -0700, David Fetter wrote:
The one below is already available, so we don't have to do a flag
day with it.
Heikki Linnakangas [EMAIL PROTECTED] writes:
You can use filterdiff -v --format=context.
Cool, I'll have to get a copy of that.
Because it's easy to convert from one to another, I think the unified
vs. context diff issue is a non-issue.
Fair enough then; we should just change the policy.
Marko Kreen wrote:
On 10/24/07, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
As we seem discussing developement in general, there is one
obstacle in the way of individual use of DSCMs - context diff
format as only one accepted.
Well, that's not a
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I'm fairly resistant to putting less-than-ready code in the tree, I must
say.
Me too, at least if less than ready means unstable. The committed
code has to always be solid enough to let everybody continue working on
their own
Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Anyway, is there anyone who thinks the cycle the queue every 6 weeks or 2
months or suitable short period is a *bad* idea? It might be hard to
pull
off, but we won't know until we try.
It seems worth a try --- we can certainly
Tom Lane wrote:
[ chewing on this a bit... ] The curious thing about that is that
despite this being designed to be a short release cycle, we ended up
landing a bunch of major patches that weren't on the radar screen at
all at the start of the cycle. This suggests to me that there's
Tom Lane [EMAIL PROTECTED] writes:
Heikki Linnakangas [EMAIL PROTECTED] writes:
You can use filterdiff -v --format=context.
Cool, I'll have to get a copy of that.
Huh, I hadn't heard of that either. The Debian package patchutils says it was
downloaded from:
* Tom Lane [EMAIL PROTECTED] [071024 08:45]:
Aidan Van Dyk [EMAIL PROTECTED] writes:
* Brendan Jurd [EMAIL PROTECTED] [071024 01:41]:
How up to date is the Git repos? Does it pull individual commits from
CVS, or does it resync the whole history periodically? If so, what's
the lag?
[EMAIL PROTECTED] wrote:
On Wed, Oct 24, 2007 at 02:32:13PM +0200, Martijn van Oosterhout wrote:
On Tue, Oct 23, 2007 at 02:39:43PM -0700, David Fetter wrote:
The one below is already available, so we don't have to do a flag
day with it.
http://repo.or.cz/w/PostgreSQL.git
As
On Wed, Oct 24, 2007 at 02:18:42PM -0300, Alvaro Herrera wrote:
[EMAIL PROTECTED] wrote:
On Wed, Oct 24, 2007 at 02:32:13PM +0200, Martijn van Oosterhout wrote:
On Tue, Oct 23, 2007 at 02:39:43PM -0700, David Fetter wrote:
The one below is already available, so we don't have to do a flag
Brendan Jurd wrote:
On 10/24/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Brendan Jurd escribió:
Really? I just started playing around with git, and the output from git
diff produced the same kind of diff file I would normally get from `svn
di`
... which is a unified diff.
or `cvs di -c`.
On Mon, 22 Oct 2007, Tom Lane wrote:
If we want a short FF-to-beta period then the criterion will have to be
that patches are either committed or darn near ready to commit on the FF
date.
I think you're stuck with a certain amount of schedule delay regardless of
how mature code is at
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
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
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
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
On Mon, Oct 22, 2007 at 11:56:02PM -0400, Tom Lane wrote:
I'd rather encourage people to work in an incremental, not-so-big-bang
fashion. Obviously one of the requirements for that will be quicker
review turnaround and commit, so that there's time to build on a
previous patch...
From my
Further the people wanting specific features of a specific release,
don't have to wait 12-15 months to get them.
I recognize this would be a *lot* easier if we didn't have the initdb
requirement but still... release early, release often.
I have really taken to the Ubuntu style of releasing.
On Mon, 22 Oct 2007, Tom Lane wrote:
If we want a short FF-to-beta period then the criterion will have to be
that patches are either committed or darn near ready to commit on the FF
date.
I think you're stuck with a certain amount of schedule delay regardless of
how mature code is
Tom Lane [EMAIL PROTECTED] writes:
[ thinks for a bit... ] A truly hard-nosed approach would be to define
FF as if your patch isn't committed by the FF date, you lose. The
FF-to-beta delay then is only long enough to make sure we've documented
everything, written release notes, etc.
Tom Lane [EMAIL PROTECTED] writes:
I'd rather encourage people to work in an incremental, not-so-big-bang
fashion. Obviously one of the requirements for that will be quicker
review turnaround and commit, so that there's time to build on a
previous patch...
I'll second that. It's awfully
Tatsuo Ishii wrote:
+1. Shorter release cycles are maybe good for fancy GUI oriented
applications, but not so good for DBMS.
--
I agree, sure it will be great to have even more and new features as
soon as possible, but not if the quality of the final product decrease.
The most important
On Tue, 2007-10-23 at 11:00 +0200, Rafael Martinez wrote:
We are always 1 year back the main release. We are testing and planing
the move to 8.2 now, and it won't happen until desember. In a 6 month
cycle we will have to jump over every second release.
We here are also just in the process of
On Mon, 2007-10-22 at 23:36 -0400, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
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
On Mon, 2007-10-22 at 12:37 -0700, Josh Berkus wrote:
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
Simon Riggs [EMAIL PROTECTED] writes:
I'd suggest we have multiple checkpoints during the cycle. Checkpoint is
a patch queue blitz where we stop developing and reduce the queue to
nothing. Perhaps a two-week period where everybody helps reduce the
queue, not just Tom and Bruce. Every
Tom, all:
I'd suggest we have multiple checkpoints during the cycle. Checkpoint is
a patch queue blitz where we stop developing and reduce the queue to
nothing. Perhaps a two-week period where everybody helps reduce the
queue, not just Tom and Bruce. Every outstanding patch gets told what
On Tue, 23 Oct 2007 17:28:14 +0900 (JST)
Tatsuo Ishii [EMAIL PROTECTED] wrote:
On Mon, 22 Oct 2007, Tom Lane wrote:
I personally think that shorting the minor release cycle time too
far is counterproductive anyway. From the DBA and system
administrator perspective, new version releases
On Tue, 23 Oct 2007 11:00:59 +0200
Rafael Martinez [EMAIL PROTECTED] wrote:
Tatsuo Ishii wrote:
+1. Shorter release cycles are maybe good for fancy GUI oriented
applications, but not so good for DBMS.
--
We are always 1 year back the main release. We are testing and planing
the
On Tue, Oct 23, 2007 at 09:39:39AM +0100, Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
I'd rather encourage people to work in an incremental,
not-so-big-bang fashion. Obviously one of the requirements for
that will be quicker review turnaround and commit, so that there's
1 - 100 of 387 matches
Mail list logo
