Peter Eisentraut wrote:
> Well, in the past the commit fest manager has usually written an
> email, "The commit fest is now closed".
With the new commitfest software, as the last patch is moved out of
"pending" and the commitfest moved to "closed" status -- I can
practically hear the bang of
On mån, 2009-08-17 at 10:22 -0400, Robert Haas wrote:
> On Mon, Aug 17, 2009 at 8:43 AM, Peter Eisentraut wrote:
> > On Mon, 2009-08-17 at 08:04 -0400, Robert Haas wrote:
> >> Now that the first CommitFest is over and done with,
> >
> > I think you forgot the part where you tell everyone that it is
On Mon, Aug 17, 2009 at 8:43 AM, Peter Eisentraut wrote:
> On Mon, 2009-08-17 at 08:04 -0400, Robert Haas wrote:
>> Now that the first CommitFest is over and done with,
>
> I think you forgot the part where you tell everyone that it is in fact
> done. I'm waiting on you before I get the alpha rele
On Mon, 2009-08-17 at 08:04 -0400, Robert Haas wrote:
> Now that the first CommitFest is over and done with,
I think you forgot the part where you tell everyone that it is in fact
done. I'm waiting on you before I get the alpha release rolling.
--
Sent via pgsql-hackers mailing list (pgsql-hac
On Tue, Jun 30, 2009 at 1:33 AM, Peter Eisentraut wrote:
> Now that 8.4.0 is out the door, development for 8.5devel will be opened any
> day now. But we haven't discussed the development timeline so far. The core
> team has several proposals:
>
> CommitFest Alpha
> Aug. 1 Sept. 1
>
Robert Haas wrote:
> On Fri, Jul 3, 2009 at 1:16 PM, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> Robert Haas wrote:
What I've seen of Heikki's work thus far has led me to believe that
his reasons for rejecting the patch were good ones, but I don't
specifically what they were.
On Fri, Jul 3, 2009 at 1:16 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> Robert Haas wrote:
>>> What I've seen of Heikki's work thus far has led me to believe that
>>> his reasons for rejecting the patch were good ones, but I don't
>>> specifically what they were. It would be helpful, I th
Heikki Linnakangas writes:
> Robert Haas wrote:
>> What I've seen of Heikki's work thus far has led me to believe that
>> his reasons for rejecting the patch were good ones, but I don't
>> specifically what they were. It would be helpful, I think, to
>> reiterate them or repost links to the relev
Robert Haas wrote:
> What I've seen of Heikki's work thus far has led me to believe that
> his reasons for rejecting the patch were good ones, but I don't
> specifically what they were. It would be helpful, I think, to
> reiterate them or repost links to the relevant messages in the
> archives; it
gsst...@mit.edu (Greg Stark) writes:
> I would like to propose a different strategy. Instead of always
> tackling all the smaller patches and leaving the big patches for last,
> I would suggest we start with Hot Standby.
>
> In fact I would suggest as Hot Standby has already gotten a first pass
> r
On Wed, Jul 1, 2009 at 11:42 PM, Andrew Dunstan wrote:
> You have correctly identified the requirement in the sentence quoted above.
> I for one am quite prepared to support core or some person designated by
> core having such authority. I agree with you that without something like
> that not much
Tom Lane wrote:
Ron Mayer writes:
Bruce Momjian wrote:
Where did you see 8.4 was scheduled to be released around the start of
the year? I never never seen that and would have disputed anyone saying
it publicly.
I think people carefully avoided the word "scheduled", but the
press FAQ on www
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Bruce Momjian writes:
> >>> If we review patches as soon as they appear, and give rapid feedback, we
> >>> can easily reject patches that take more than a few days for the patch
> >>> author to resolve, and there would be little sli
Bruce Momjian writes:
> Tom Lane wrote:
>> Bruce Momjian writes:
>>> If we review patches as soon as they appear, and give rapid feedback, we
>>> can easily reject patches that take more than a few days for the patch
>>> author to resolve, and there would be little slippage; the same goes
>>> fo
On Wed, Jul 1, 2009 at 7:00 PM, Tom Lane wrote:
> Greg Stark writes:
>> On Tue, Jun 30, 2009 at 5:11 PM, Tom Lane wrote:
>>> I'm also not prepared to push a large and unstable feature into the tree
>>> on the hope that it will get fixed.
>
>> I didn't have the impression it had any known problems,
Tom Lane wrote:
> Bruce Momjian writes:
> > There has been discussion about how to be more hard-nosed about
> > rejecting patches. I think it has to start with us being more
> > hard-nosed about giving patches feedback --- the very idea we had to
> > create commit-fests reflects that we historica
Robert Haas wrote:
> > If we review patches as soon as they appear, and give rapid feedback, we
> > can easily reject patches that take more than a few days for the patch
> > author to resolve, and there would be little slippage; ?the same goes
> > for dealing with known bugs. ?I know it can be don
Bruce Momjian writes:
> There has been discussion about how to be more hard-nosed about
> rejecting patches. I think it has to start with us being more
> hard-nosed about giving patches feedback --- the very idea we had to
> create commit-fests reflects that we historically have not done an
> org
On Wed, Jul 1, 2009 at 6:55 PM, Bruce Momjian wrote:
> bruce wrote:
>> I realize there is the perception that the large patches that were
>> eventually rejected held up the release, but for all the patches I can
>> think of, they were not rejected immediately _because_ we had other
>> valid patches
On Wed, Jul 1, 2009 at 6:53 PM, Kevin
Grittner wrote:
> Bruce Momjian wrote:
>
>> The problem is that the committers control the commit date, but the
>> one seen as punished for a rejected patch is not the committers but
>> the submitter.
>
> Well, it would seem odd for anyone to feel "punished".
Greg Stark writes:
> On Tue, Jun 30, 2009 at 5:11 PM, Tom Lane wrote:
>> I'm also not prepared to push a large and unstable feature into the tree
>> on the hope that it will get fixed.
> I didn't have the impression it had any known problems, Simon and
> others spent a lot of time testing it alre
Greg Stark wrote:
> On Tue, Jun 30, 2009 at 5:11 PM, Tom Lane wrote:
>
> > I'm also not prepared to push a large and unstable feature into the tree
> > on the hope that it will get fixed.
>
> I didn't have the impression it had any known problems, Simon and
> others spent a lot of time testing it
bruce wrote:
> I realize there is the perception that the large patches that were
> eventually rejected held up the release, but for all the patches I can
> think of, they were not rejected immediately _because_ we had other
> valid patches to work on. Once all valid patches were applied, we were
Bruce Momjian wrote:
> The problem is that the committers control the commit date, but the
> one seen as punished for a rejected patch is not the committers but
> the submitter.
Well, it would seem odd for anyone to feel "punished".
If the patch isn't submitted in good form with the issues h
On Tue, Jun 30, 2009 at 5:11 PM, Tom Lane wrote:
> I'm also not prepared to push a large and unstable feature into the tree
> on the hope that it will get fixed.
I didn't have the impression it had any known problems, Simon and
others spent a lot of time testing it already. The improvements Heikk
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > Define "make that date"? That is the problem.
>
> Not committed by that date. I guess that leaves the issue of picking
> a particular time in a particular time zone, but it doesn't otherwise
> seem ambiguous.
>
> Picture the New York Subw
Bruce Momjian wrote:
> Define "make that date"? That is the problem.
Not committed by that date. I guess that leaves the issue of picking
a particular time in a particular time zone, but it doesn't otherwise
seem ambiguous.
Picture the New York Subway system. You're coming down the stair
On Wed, Jul 1, 2009 at 5:01 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> Kevin Grittner wrote:
>>> However, even the *possibility* that this could be true is pretty
>>> scary. If we need to effectively shut down new development for seven
>>> months at the end of a release, in addition to the in
Tom Lane wrote:
"Joshua D. Drake" writes:
On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote:
It comes down to somebody having the willingness to say "no" and the
authority to make it stick. Robert mentioned upthread that the
committers don't want to be seen as throwing their weight
Joshua D. Drake wrote:
> On Wed, 2009-07-01 at 17:13 -0400, Tom Lane wrote:
> > "Joshua D. Drake" writes:
> > > On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote:
> > >> It comes down to somebody having the willingness to say "no" and the
> > >> authority to make it stick. Robert mentioned upthre
On Wed, 2009-07-01 at 17:13 -0400, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote:
> >> It comes down to somebody having the willingness to say "no" and the
> >> authority to make it stick. Robert mentioned upthread that the
> >> committers don't
"Joshua D. Drake" writes:
> On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote:
>> It comes down to somebody having the willingness to say "no" and the
>> authority to make it stick. Robert mentioned upthread that the
>> committers don't want to be seen as throwing their weight around,
> Is that
On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote:
> It comes down to somebody having the willingness to say "no" and the
> authority to make it stick. Robert mentioned upthread that the
> committers don't want to be seen as throwing their weight around,
Is that the purpose of core? To make exac
Bruce Momjian writes:
> Kevin Grittner wrote:
>> However, even the *possibility* that this could be true is pretty
>> scary. If we need to effectively shut down new development for seven
>> months at the end of a release, in addition to the interim commit
>> fests, we'd better get a handle on why
Kevin Grittner wrote:
> Bruce Momjian wrote:
> > The beta preparation is dealing with all open issues, which is
> > different than the focus of the commit-fest. Ideally we would be
> > addressing those open/bug issues during normal development, but for
> > the hard problems seem to linger and th
Bruce Momjian wrote:
> The beta preparation is dealing with all open issues, which is
> different than the focus of the commit-fest. Ideally we would be
> addressing those open/bug issues during normal development, but for
> the hard problems seem to linger and then we have to deal with them
> d
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> In retrospect, the CF idea took some of the edge off the problem of
> >> lots of large patches arriving at the feature freeze deadline, but it
> >> is far from having eliminated the problem.
>
> > The beta preparation is dealing wit
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > How could we have possibly completed the last commit-fest and gotten
> > ready for beta in two months --- that is just not realistic. I
> > think we anticipated a 2x longer final commit-fest, two months, but
> > there was no time scheduled for
Bruce Momjian writes:
> Tom Lane wrote:
>> In retrospect, the CF idea took some of the edge off the problem of
>> lots of large patches arriving at the feature freeze deadline, but it
>> is far from having eliminated the problem.
> The beta preparation is dealing with all open issues, which is di
Tom Lane wrote:
> Bruce Momjian writes:
> > OK, that is more accurate, but looking at the schedule:
>
> > 1st November 2008 - final commit fest begins
> > 1st January 2009 - beta 1
> > 1st March 2009 - 8.4.0 release
>
> > How could we have possibly completed the last commit-fest and
Ron Mayer writes:
> Bruce Momjian wrote:
>> Where did you see 8.4 was scheduled to be released around the start of
>> the year? I never never seen that and would have disputed anyone saying
>> it publicly.
> I think people carefully avoided the word "scheduled", but the
> press FAQ on www.postgr
Bruce Momjian wrote:
> How could we have possibly completed the last commit-fest and gotten
> ready for beta in two months --- that is just not realistic. I
> think we anticipated a 2x longer final commit-fest, two months, but
> there was no time scheduled for actual beta preparation.
For my
Ron Mayer wrote:
> Bruce Momjian wrote:
> > Where did you see 8.4 was scheduled to be released around the start of
> > the year? I never never seen that and would have disputed anyone saying
> > it publicly.
>
> I think people carefully avoided the word "scheduled", but the
> press FAQ on www.pos
Bruce Momjian writes:
> OK, that is more accurate, but looking at the schedule:
> 1st November 2008 - final commit fest begins
> 1st January 2009 - beta 1
> 1st March 2009 - 8.4.0 release
> How could we have possibly completed the last commit-fest and gotten
> ready for beta in
Bruce Momjian wrote:
Where did you see 8.4 was scheduled to be released around the start of
the year? I never never seen that and would have disputed anyone saying
it publicly.
I think people carefully avoided the word "scheduled", but the
press FAQ on www.postgresql.org did say to expect it i
Kevin Grittner wrote:
> Tom Lane wrote:
> > "Kevin Grittner" writes:
> >> That showed a January 1 beta release and a March 1 production
> >> release.
> >
> > Terminological problem. Around here, "release" *always* means
> > production release. We don't expect end users to be very interested
>
Kevin Grittner wrote:
> "Joshua D. Drake" wrote:
> > On Wed, 2009-07-01 at 12:47 -0500, Kevin Grittner wrote:
>
> >> http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php
> >>
> >> That showed a January 1 beta release and a March 1 production
> >> release.
> >
> > Right that woul
Tom Lane wrote:
> "Kevin Grittner" writes:
>> That showed a January 1 beta release and a March 1 production
>> release.
>
> Terminological problem. Around here, "release" *always* means
> production release. We don't expect end users to be very interested
> in pre-production versions.
Well,
"Kevin Grittner" writes:
> Bruce Momjian wrote:
>> Where did you see 8.4 was scheduled to be released around the start of
>> the year?
> http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php
> That showed a January 1 beta release and a March 1 production release.
Terminological pr
"Joshua D. Drake" wrote:
> On Wed, 2009-07-01 at 12:47 -0500, Kevin Grittner wrote:
>> http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php
>>
>> That showed a January 1 beta release and a March 1 production
>> release.
>
> Right that would be the expectation I had.
The first
On Wed, 2009-07-01 at 12:47 -0500, Kevin Grittner wrote:
> Bruce Momjian wrote:
> > Where did you see 8.4 was scheduled to be released around the start
> of
> > the year? I never never seen that and would have disputed anyone
> saying
> > it publicly.
>
> http://archives.postgresql.org/pgsql-h
Bruce Momjian wrote:
> Where did you see 8.4 was scheduled to be released around the start
of
> the year? I never never seen that and would have disputed anyone
saying
> it publicly.
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php
That showed a January 1 beta release and a
On Wed, 2009-07-01 at 13:39 -0400, Bruce Momjian wrote:
> Where did you see 8.4 was scheduled to be released around the start of
> the year? I never never seen that and would have disputed anyone saying
> it publicly.
As I understood it, 8.4 was supposed to released at the beginning of Q2.
I nev
Kevin Grittner wrote:
> Ron Mayer wrote:
>
> > I could imagine an enterprise plan that says "we'll upgrade to
> > the current production release in January [after christmas sales]";
> > or "we'll begin to upgrade the January after [feature-x] is in
> > production".
> >
> > But in neither case
Ron Mayer writes:
> Tom Lane wrote:
>> I think we used to do it more or less like that, but people didn't like
>> it because they couldn't do any long-range planning.
> Does the current system help long-range planning?
> I could imagine an enterprise plan that says "we'll upgrade to
> the curren
Bruce Momjian wrote:
> Kevin Grittner wrote:
>> To what do you attribute the extended time needed to handle the
>> final CF? How can that be made better?
>
> We had many patches that had been through previous commit-fests with
> minor adjustments and we had to finalize them before we could close
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > I realize there is the perception that the large patches that were
> > eventually rejected held up the release, but for all the patches I
> > can think of, they were not rejected immediately _because_ we had
> > other valid patches to work on.
Ron Mayer wrote:
> But in neither case does it help my long term planning to know if
> the current version January release is scheduled to be called 8.4
> or 8.5 or 9.1 (which is really all that the current system helps
> me predict).
The numbering is typically decided near the end of the devel c
Ron Mayer wrote:
> I could imagine an enterprise plan that says "we'll upgrade to
> the current production release in January [after christmas sales]";
> or "we'll begin to upgrade the January after [feature-x] is in
> production".
>
> But in neither case does it help my long term planning to
On Wed, Jul 01, 2009 at 11:51:28AM -0400, Robert Haas wrote:
> Tom wrote upthread:
> # If you find yourself with nothing else to do except review a new patch
> # during beta, then sure, go do it. But is there *really* nothing you
> # could be doing to help expedite the beta?
>
> My honest answer
Tom Lane wrote:
"Joshua D. Drake" writes:
We already push and pull our release dates based are what in the queue,
we just do so informally. Why not just make it part of the process?
I think we used to do it more or less like that, but people didn't like
it because they couldn't do any long-ra
On Wed, Jul 1, 2009 at 10:30 AM, Kevin
Grittner wrote:
> Bruce Momjian wrote:
>> I realize there is the perception that the large patches that were
>> eventually rejected held up the release, but for all the patches I
>> can think of, they were not rejected immediately _because_ we had
>> other va
Ugh, I disagree. I agree that we were too generous with letting
people rework patches while the CommitFest was in progress (mostly, we
let people drop off the map for 3 weeks and then come back and say,
oh, here's my revised version). But you have to allow a certain
amount of reworking as the
Bruce Momjian wrote:
> I realize there is the perception that the large patches that were
> eventually rejected held up the release, but for all the patches I
> can think of, they were not rejected immediately _because_ we had
> other valid patches to work on. Once all valid patches were
> app
On Wed, 2009-07-01 at 02:14 -0400, Robert Haas wrote:
> Basically, if we're too quick to bump patches to the next CommitFest,
> there will be only moderate resistance for the first N-1 CommitFests,
> but then for the last CommitFest people won't want to be bumped by a
> whole major release for wh
On Tue, 2009-06-30 at 08:33 +0300, Peter Eisentraut wrote:
> Now that 8.4.0 is out the door, development for 8.5devel will be
> opened any day now. But we haven't discussed the development timeline
> so far.
This is a wonderful thing. Development opening quickly and the idea of a
discussed and
On Tue, 2009-06-30 at 09:35 -0400, Robert Haas wrote:
> In any case, we probably need some weigh-in from Heikki and Simon on
> their plans for Hot Standby before we make any decisions...
We discussed this at the developer meeting in May.
I gave a clear commitment to getting Hot Standby into Pos
On Tue, 2009-06-30 at 21:04 +0300, Heikki Linnakangas wrote:
> Merlin Moncure wrote:
> > Given that there is also a lot of work on synchronous replication, is
> > it better to get the HS in so the SR stuff can use that as a baseline,
> > or to triage in both patches together?
>
> Whichever finish
On Wed, Jul 1, 2009 at 1:16 AM, Josh Berkus wrote:
> Hmmm ... actually, I think Andrew's right that we don't need a specific
> "last commitfest" rule which is special. Really, any patch which gets
> submitted to any commitfest gets returned if it's not ready to be committed
> immediately after rev
Andrew,
I thought we discussed that at pgCon in May and rejected it.
That's not what we have in my notes:
http://wiki.postgresql.org/wiki/PgCon_2009_Developer_Meeting#CommitFests
Of course, I may have missed some options, a lot of people were talking.
I have very, very serious reservations
On Tue, Jun 30, 2009 at 11:18 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> > As for thresholds, I'd propose that we measure the size of patches
>> > using "diff -u | diffstat". If the number of insertions plus the
>> > number of deletions is >= 1000, then the patch is not eligible for the
>> > fi
Tom Lane wrote:
> > As for thresholds, I'd propose that we measure the size of patches
> > using "diff -u | diffstat". If the number of insertions plus the
> > number of deletions is >= 1000, then the patch is not eligible for the
> > final CommitFest unless it was submitted for the penultimate
>
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I'm in agreement that we should try to provide feedback (in general, to
> > be honest) on patches/suggestions/ideas/designs/etc as quickly as
> > possible. The commitfest approach is good for this when it's "in
> > motion", but it
Josh Berkus wrote:
One thing Peter forgot to mention here is that the next-to-last
commitfest is the *last* commitfest for new major features. For the
*last* commitfest, any patch introduced either has to be a
resubmission of something we've seen at a prior CF, or has to be very
"small" (
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Yeah. In core's private discussion of this, I too was arguing for
>> running a CommitFest ASAP, in order to have some motion on the existing
>> patch backlog. I don't know that we'd actually end up committing many,
>> but we need
On Tue, Jun 30, 2009 at 9:17 PM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> As I mentioned in the core discussion, I'm a bit concerned that this
>> would have the effect of choking off development too soon. We could
>> have a situation where nothing major is supposed to be ge
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> As I mentioned in the core discussion, I'm a bit concerned that this
> would have the effect of choking off development too soon. We could
> have a situation where nothing major is supposed to be getting worked
> on from Nov 15 to mid-May, which seems much
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I would like to propose aiming for a release around April/May 2010 ...
> "in time for PGCon" if you like, but the main point is to have it out
> before people start disappearing for summer break. We've already run
> into problems with scheduling the 8.4 rel
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > What I think we have is a lot of people who are waiting
> > for feedback, and we should try to give them some. I also know that
> > reviewing 60 patches for the November CommitFest was a ton of work,
> > and the reviewers (including
Kevin Grittner wrote:
Tom Lane wrote:
I think we used to do it more or less like that, but people
didn't like it because they couldn't do any long-range planning.
Well, obviously the 8.4 release cycle did little to help them.
As has already been observed, there is a crying need to say "no
Josh Berkus writes:
> One thing Peter forgot to mention here is that the next-to-last
> commitfest is the *last* commitfest for new major features. For the
> *last* commitfest, any patch introduced either has to be a resubmission
> of something we've seen at a prior CF, or has to be very "smal
Josh Berkus writes:
>> I would propose to start CommitFests July 15th, September 15th,
>> November 15th, and January 15th, planning all but the last to be one
>> month long. The last CommitFest I would plan on closing up by March
>> 1st, with release hopefully by June 1st.
> This sounds good to
On 6/29/09 10:33 PM, Peter Eisentraut wrote:
Now that 8.4.0 is out the door, development for 8.5devel will be opened any
day now. But we haven't discussed the development timeline so far. The core
team has several proposals:
CommitFest Alpha
Aug. 1 Sept. 1
Oct. 1 Nov. 1
I would propose to start CommitFests July 15th, September 15th,
November 15th, and January 15th, planning all but the last to be one
month long. The last CommitFest I would plan on closing up by March
1st, with release hopefully by June 1st.
This sounds good to me. Anyone object?
As for th
Kevin Grittner wrote:
> It might actually help to do that on big patches if we don't let too
> many tiny ones accumulate. I seem to remember the argument being tossed
> about that "we might as well keep working on this one because there's
> all these others to wrap up."
Yeah, and the people who
Merlin Moncure wrote:
> Given that there is also a lot of work on synchronous replication, is
> it better to get the HS in so the SR stuff can use that as a baseline,
> or to triage in both patches together?
Whichever finishes first. Although they're very useful together, there
is little if any co
Robert Haas wrote:
> In any case, we probably need some weigh-in from Heikki and Simon on
> their plans for Hot Standby before we make any decisions...
I'm planning to spend considerable amount of time reviewing and helping
with hot standby and synchronous replication, but someone else will have
t
Tom Lane wrote:
> I think we used to do it more or less like that, but people
> didn't like it because they couldn't do any long-range planning.
Well, obviously the 8.4 release cycle did little to help them.
As has already been observed, there is a crying need to say "no" at
some point to ge
Robert Haas writes:
> I agree. On the other hand, I think all of the proposed schedules are
> somewhat optimistic about how long the final release will take. We
> started the final CommitFest for 8.4 on November 1st and are set to
> release July 1st. The proposed schedule for next time involves
"Joshua D. Drake" writes:
> We already push and pull our release dates based are what in the queue,
> we just do so informally. Why not just make it part of the process? That
> way we are being up front and saying, "Yeah, we have no idea. We will
> review in 6 months and that is when we decide our
On Tue, Jun 30, 2009 at 12:37 PM, Tom Lane wrote:
> "Joshua D. Drake" writes:
>> On Tue, 2009-06-30 at 12:29 -0400, Tom Lane wrote:
>>> I would like to propose aiming for a release around April/May 2010 ...
>>> "in time for PGCon" if you like, but the main point is to have it out
>>> before people
On Tue, 2009-06-30 at 12:37 -0400, Tom Lane wrote:
> > We are not a company. We don't have a deadline. Why can't we just
> > develop and say, "Yeah, this looks like it would make a substantive
> > release."?
>
> Well, then you might as well not have a schedule at all. The point of
> setting up a
"Joshua D. Drake" writes:
> On Tue, 2009-06-30 at 12:29 -0400, Tom Lane wrote:
>> I would like to propose aiming for a release around April/May 2010 ...
>> "in time for PGCon" if you like, but the main point is to have it out
>> before people start disappearing for summer break. We've already run
On Tue, 2009-06-30 at 12:29 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > Now that 8.4.0 is out the door, development for 8.5devel will be opened any
> > day now. But we haven't discussed the development timeline so far. The
> > core
> > team has several proposals:
> > [ details snippe
On Tue, 2009-06-30 at 12:11 -0400, Tom Lane wrote:
> I'm also not prepared to push a large and unstable feature into the tree
> on the hope that it will get fixed. The general consensus among -core,
> and I think most of -hackers as well, is that we want to try to keep CVS
> HEAD pretty stable, s
Peter Eisentraut writes:
> Now that 8.4.0 is out the door, development for 8.5devel will be opened any
> day now. But we haven't discussed the development timeline so far. The core
> team has several proposals:
> [ details snipped ]
ISTM there are two critical decisions here: when's the first
Greg Stark writes:
> I would like to propose a different strategy. Instead of always
> tackling all the smaller patches and leaving the big patches for last,
> I would suggest we start with Hot Standby.
> In fact I would suggest as Hot Standby has already gotten a first pass
> review that we cons
Robert Haas writes:
> What I think we have is a lot of people who are waiting
> for feedback, and we should try to give them some. I also know that
> reviewing 60 patches for the November CommitFest was a ton of work,
> and the reviewers (including the committers) ran out of steam well
> before w
On Tue, Jun 30, 2009 at 10:11 AM, Peter Eisentraut wrote:
> On Tuesday 30 June 2009 16:50:55 Kevin Grittner wrote:
>> > However, if anything, I think if anything we should go the other way
>> > and start the first CommitFest July 15th.
>>
>> I'm curious what the counter-arguments to this are. Is i
Peter Eisentraut wrote:
> Well, think about what could happen if we go this way. What you
> basically have here are people who have essentially ignored the
> commitfest and beta mandates and worked on new patches. And they
> now get to say, because we already have enough patches, let's start
1 - 100 of 110 matches
Mail list logo
