Not ready for 8.3
Based on our progress during this feature freeze, we will not complete
the feature freeze until August/September. I think we need adjust
expectations about an 8.3 release date, and decide if we want to
radically change our work process.
Basically, to make a release anywhere near July, we need 10x more
progress than we have had, which is unlikely.
We could ship what is in CVS now, but that just pushes the patches for
8.4, and isn't fair to patch submitters. We could shove what we have
now into CVS, but that is unwise.
I think the only other thing we _could_ do is to re-open normal 8.3
development, so we aren't hampering updates to trivial parts of the
code. Many of the patches now in the queue had been developed for months
before 8.3 started, so the hope is that we wouldn't have many more new
large patches, but several small ones we could deal with while we
whittle away at the larger patches during the next few months.
The question is whether it is healthy for us to remain in feature freeze
for months, and if it is unhealthy, what are our options?
Patch status:
http://developer.postgresql.org/index.php/Todo:PatchStatus
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
"Bruce Momjian" <bruce@momjian.us> writes:
I think the only other thing we _could_ do is to re-open normal 8.3
development, so we aren't hampering updates to trivial parts of the
code. Many of the patches now in the queue had been developed for months
before 8.3 started, so the hope is that we wouldn't have many more new
large patches, but several small ones we could deal with while we
whittle away at the larger patches during the next few months.The question is whether it is healthy for us to remain in feature freeze
for months, and if it is unhealthy, what are our options?
I don't see any reason development has to stop while the tree is in feature
freeze. If it led to patches being ready for review and getting reviewed and
committed early in the cycle rather than just before release I think it would
actually be extremely healthy.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Bruce Momjian wrote:
Based on our progress during this feature freeze, we will not complete
the feature freeze until August/September. I think we need adjust
expectations about an 8.3 release date, and decide if we want to
radically change our work process.Basically, to make a release anywhere near July, we need 10x more
progress than we have had, which is unlikely.
Or we have another short release cycle, basically accepting what we have
now that can be worked through in the next 3 weeks and committed. If it
can't be done in that time, it waits. Then we have beta etc...
We could ship what is in CVS now, but that just pushes the patches for
8.4, and isn't fair to patch submitters. We could shove what we have
now into CVS, but that is unwise.
Sure it is, if we have a short release cycle. There are plenty of things
out there that are not quite ready yet, that could be if we released
again next January...
I think the only other thing we _could_ do is to re-open normal 8.3
development, so we aren't hampering updates to trivial parts of the
code. Many of the patches now in the queue had been developed for months
Gah, that sounds like a horrible solution. Sorry Bruce.
The question is whether it is healthy for us to remain in feature freeze
for months, and if it is unhealthy, what are our options?Patch status:
If... this is actually a problem (I leave to other committers and
reviewers to comment) then I suggest we push all patches without a
reviewer as of now to 8.4.
Leaving only those patches that have confirmed reviewers to be worked
through.
FYI, whoever did that Todo:Patch status, Bravo! That is easily one of
the smallest but best improvements to the process I have seen in recent
memory.
Sincerely,
Joshua D. Drake
Joshua D. Drake wrote:
Bruce Momjian wrote:
Based on our progress during this feature freeze, we will not complete
the feature freeze until August/September. I think we need adjust
expectations about an 8.3 release date, and decide if we want to
radically change our work process.Basically, to make a release anywhere near July, we need 10x more
progress than we have had, which is unlikely.Or we have another short release cycle, basically accepting what we have
now that can be worked through in the next 3 weeks and committed. If it
can't be done in that time, it waits. Then we have beta etc...
That is not fair to patch submitters, and pushes the problem to 8.4,
where it will be no better.
We could ship what is in CVS now, but that just pushes the patches for
8.4, and isn't fair to patch submitters. We could shove what we have
now into CVS, but that is unwise.Sure it is, if we have a short release cycle. There are plenty of things
out there that are not quite ready yet, that could be if we released
again next January...
Huh, you didn't answer my issue about unfair.
The question is whether it is healthy for us to remain in feature freeze
for months, and if it is unhealthy, what are our options?Patch status:
If... this is actually a problem (I leave to other committers and
reviewers to comment) then I suggest we push all patches without a
reviewer as of now to 8.4.Leaving only those patches that have confirmed reviewers to be worked
through.FYI, whoever did that Todo:Patch status, Bravo! That is easily one of
the smallest but best improvements to the process I have seen in recent
memory.
Fairness and not pushing our problems out to the future --- address
those issues.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Joshua D. Drake wrote:
Patch status:
If... this is actually a problem (I leave to other committers and
reviewers to comment) then I suggest we push all patches without a
reviewer as of now to 8.4.Leaving only those patches that have confirmed reviewers to be worked
through.FYI, whoever did that Todo:Patch status, Bravo! That is easily one of
the smallest but best improvements to the process I have seen in recent
memory.
I did one of those for previous releases. I guess you forgot. It was
done by someone else this time only because I was going to be traveling.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
"Bruce Momjian" <bruce@momjian.us> writes:
Joshua D. Drake wrote:
Bruce Momjian wrote:
Based on our progress during this feature freeze, we will not complete
the feature freeze until August/September. I think we need adjust
expectations about an 8.3 release date, and decide if we want to
radically change our work process.Basically, to make a release anywhere near July, we need 10x more
progress than we have had, which is unlikely.Or we have another short release cycle, basically accepting what we have
now that can be worked through in the next 3 weeks and committed. If it
can't be done in that time, it waits. Then we have beta etc...That is not fair to patch submitters, and pushes the problem to 8.4,
where it will be no better.
It's nice to be fair but it's not really the goal here.
However I think the latter point is key. This *was* a short release cycle. If
we push off these patches to later there's no reason to think the situation
will be any different in a few months.
I suspect as much as Tom finds reviewing boring he would rather get it out of
the way and then have a chance to do development before more major patches
arrive than start the new cycle with major patches sitting in the review queue
and spend the whole cycle reviewing them.
As much as I hate that the patches sit in the queue until feature freeze
there's nothing else that will really force us to make a yea or nay decision
on them. If we start the next release with things in the patch queue they're
liable to sit there with no feedback for months again.
I think the key here is to give feedback for the authors but not allow the
time to respond to that feedback to grow. If you review a patch and find
problems with it and there's only three weeks for the author to deal with
those problems and it's not enough time then he can deal with them and submit
it for next release. But letting the patch ride over without giving any
feedback just seems pointless.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Joshua D. Drake wrote:
FYI, whoever did that Todo:Patch status, Bravo! That is easily one of
the smallest but best improvements to the process I have seen in recent
memory.
well bruce asked for something like that:
http://archives.postgresql.org/pgsql-hackers/2007-05/msg00249.php
and I simply went ahead and did it:
http://archives.postgresql.org/pgsql-hackers/2007-05/msg00265.php
Stefan
Bruce,
Realistically I just don't see getting everything in the ToDo patch list in;
my vote is that we start deferring stuff for 8.4 if it doesn't have a
reviewer, except for items which were submitted early in the cycle (and to
whom it would be unfair).
If that means shortening the 8.4 cycle somewhat, I'm for that ... feature
freeze in Feburary would be even better than April, because it means we could
be in Beta for the May-June-July conferences, and increase our probability of
being able to release at a major conference or PostgreSQL conference.
Obviously for 8.4 reviewers need to start reviewing stuff from the first week
of the development cycle. I also don't actually see anything wrong with a
3-month feature freeze if we can somehow branch development earlier. Easy
for me to say, I know.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
That is not fair to patch submitters, and pushes the problem to 8.4,
where it will be no better.
If it isn't done, it isn't done. We aren't dropping the patch. The patch
has been accepted, just not reviewed. It is just delayed.
Sure it is, if we have a short release cycle. There are plenty of things
out there that are not quite ready yet, that could be if we released
again next January...Huh, you didn't answer my issue about unfair.
Sure I did see above :). Unfair would be to let go all together. We are
just delaying. If we don't have reviewers, we don't have reviewers and
as I look at the open list we have more reviewers than we did for 8.2 so
I would suspect that 8.4 is going to go smoother as it is.
Leaving only those patches that have confirmed reviewers to be worked
through.FYI, whoever did that Todo:Patch status, Bravo! That is easily one of
the smallest but best improvements to the process I have seen in recent
memory.Fairness and not pushing our problems out to the future --- address
those issues.
Life isn't fair. It isn't like we are telling these people to bugger
off. We are just delaying the review to what is a reasonable workload
for the current set of reviewers.
Life... is a perpetual problem. We do what we can, when we can, and the
best that we can.
Taking my suggestion above for leaving patches that don't have reviewers
let's look at some of them.
Tsearch2 in core. I know that Tom has some reservations, he I and Treat
all commented on how it was done and to my knowledge those reservations
have not been resolved.
HOT is a huge patch that has gone round and round and round. Lots of
people want it, including me but it is invasive enough to where it may
due it good to work through another cycle.
Grouped Index Tuples. I like the result of this patch. I tested the
performance and it did work as advertised but we didn't get much
feedback as a whole from known hackers. Either there isn't much interest
or we are too busy. Either way it is certainly not a critical patch
and can be pushed.
Concurrent psql, nifty but still trying to decide on actual interface.
Full Page Writes Improvement, doesn't actually do anything *yet* (as far
as I can tell) it just makes it so something can be done in the future.
It is also apparently a small patch.
UTF8 text matching performance improvements (todo wiki link broke), so I
don't have much comment.
On Disk Bitmap indexes (todo wiki link broke): Doesn't support Vacuum
(to my knowledge), community member tested, reported problems... no
response yet from author. The author is known to be time constrained,
boot it till 8.4.
Posix shared memory, not usable in current state per Tom's comments and
Apples, agreement. Dumped till 8.4 or further.
Stream bitmaps, apparently needed more info from Gavin (see previous
comment about author's time). No feed back since March 9th. Dumped till 8.4.
Bitmapscan change, this one is unfortunate because at the time Heikki
had resources and desire but was basically ignored. Sometimes we have to
punt although Heikki is doing patch review right now and it is not
unheard of for a patch reviewer to commit his own patch (in this case we
would need a comitter to actually accept it.).
Updateable cursors, apparently breaks explain and patch has been
updated. Punt!
Group Commit, Heikki has already suggested that it may be a good idea to
push for 8.4 on this patch: http://momjian.us/mhonarc/patches/msg00127.html
Index Advisor.. I think the link is wrong:
http://momjian.us/mhonarc/patches/msg00119.html
Ctid chain patch, apparently no discussion since last January even
though requests had been made to change the patch to some degree. Punt.
I will note that no one was negative about the patch, it just doesn't
appear that the requests were ever finished.
Error correct for n_dead_tuples, patch was requested for hold in Feb. No
discussion since. Punt!
DSM, apparently includes n_dead_tuples, please remove n_dead_tuples line
on todo. Significant memory allocation enhancements are expected in 8.4
for this. Discussion died in April. Concerns were raised about how
memory is allocated (fixed, shared) which author already admints to
wanting to change for 8.4.
PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be
developed outside of core. Don't get me wrong I like the feature but it
can take advantage of facilities outside of core.
So there ya go... thoughts, flames?
Sincerely,
Joshua D. Drake
Show quoted text
Gregory Stark wrote:
"Bruce Momjian" <bruce@momjian.us> writes:
I think the only other thing we _could_ do is to re-open normal 8.3
development, so we aren't hampering updates to trivial parts of the
code. Many of the patches now in the queue had been developed for months
before 8.3 started, so the hope is that we wouldn't have many more new
large patches, but several small ones we could deal with while we
whittle away at the larger patches during the next few months.The question is whether it is healthy for us to remain in feature freeze
for months, and if it is unhealthy, what are our options?I don't see any reason development has to stop while the tree is in feature
freeze. If it led to patches being ready for review and getting reviewed and
committed early in the cycle rather than just before release I think it would
actually be extremely healthy.
If we had multiple dev branches it might be more possible. That has its
own costs, of course - having a single dev branch makes management much
easier, and we never have to worry about things like merging.
Patches seem to be getting larger, more complex, and harder to review.
That is stressing our processes more than somewhat.
Short cycles would only make matters worse - the frictional cost of each
dev cycle is growing. I think at least we have learned not to repeat
this exercise.
cheers
andrew
We have new patch available
http://www.sigaev.ru/misc/tsearch_core-0.47.gz
to sync with CVS HEAD.
Oleg
On Tue, 15 May 2007, Joshua D. Drake wrote:
Bruce Momjian wrote:
Based on our progress during this feature freeze, we will not complete
the feature freeze until August/September. I think we need adjust
expectations about an 8.3 release date, and decide if we want to
radically change our work process.Basically, to make a release anywhere near July, we need 10x more
progress than we have had, which is unlikely.Or we have another short release cycle, basically accepting what we have now
that can be worked through in the next 3 weeks and committed. If it can't be
done in that time, it waits. Then we have beta etc...We could ship what is in CVS now, but that just pushes the patches for
8.4, and isn't fair to patch submitters. We could shove what we have
now into CVS, but that is unwise.Sure it is, if we have a short release cycle. There are plenty of things out
there that are not quite ready yet, that could be if we released again next
January...I think the only other thing we _could_ do is to re-open normal 8.3
development, so we aren't hampering updates to trivial parts of the
code. Many of the patches now in the queue had been developed for monthsGah, that sounds like a horrible solution. Sorry Bruce.
The question is whether it is healthy for us to remain in feature freeze
for months, and if it is unhealthy, what are our options?Patch status:
If... this is actually a problem (I leave to other committers and reviewers
to comment) then I suggest we push all patches without a reviewer as of now
to 8.4.Leaving only those patches that have confirmed reviewers to be worked
through.FYI, whoever did that Todo:Patch status, Bravo! That is easily one of the
smallest but best improvements to the process I have seen in recent memory.Sincerely,
Joshua D. Drake
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83
josh@agliodbs.com (Josh Berkus) writes:
Bruce,
Realistically I just don't see getting everything in the ToDo patch
list in; my vote is that we start deferring stuff for 8.4 if it
doesn't have a reviewer, except for items which were submitted early
in the cycle (and to whom it would be unfair).If that means shortening the 8.4 cycle somewhat, I'm for that
... feature freeze in Feburary would be even better than April,
because it means we could be in Beta for the May-June-July
conferences, and increase our probability of being able to release
at a major conference or PostgreSQL conference.
If we're pushing stuff planned for 8.3 off into 8.4, then doesn't that
mean that we'd be inclined to _lengthen_ the 8.4 cycle?
If we were to shorten the 8.4 cycle, that seems likely to me to worsen
the problem, so that I'd expect to see even more stuff deferred for
8.5 than was the case with 8.3...
Obviously for 8.4 reviewers need to start reviewing stuff from the
first week of the development cycle. I also don't actually see
anything wrong with a 3-month feature freeze if we can somehow
branch development earlier. Easy for me to say, I know.
Well, if people are essentially already working on patches for 8.4
*now*, but just deferring merging until after 8.3 is committed +
released, then we've got 8.4 work underway already.
Unfortunately, that's also likely to worsen the problem of the
reviewers' queues being even more overflowing.
I'd sorta like to see the Tom Lanes and Bruce Momjians of the project
getting to have some time to work on things that *they'd* like add, as
opposed to turning things into a spiral cycle where they keep spending
more and more of their time reviewing patches, as opposed to doing
things they find neat and new. Too many iterations of that sort of
thing, and they'll not want to ever see a patch again...
--
output = ("cbbrowne" "@" "linuxdatabases.info")
http://cbbrowne.com/info/wp.html
"...It is also possible to post imbecilic articles with any browser,
especially when you toppost and omit snippage." -- CBFalconer
<cbfalconer@yahoo.com> - seen on comp.lang.c
On Tue, 15 May 2007, Joshua D. Drake wrote:
Tsearch2 in core. I know that Tom has some reservations, he I and Treat all
commented on how it was done and to my knowledge those reservations have not
been resolved.
We'd like to know about these reservations. If I understand you mean there
are issues with the patch ? Our patch is several months old. We permanently
keep it in sync with CVS HEAD, latest version is 0.47.
We're really bored with the whole process of development. We're not
full-time developers, we just devote our spare time which we withdraw from
time we should spend on many other things. We have no time even to discuss
those very useful threads about community management, patches, etc. We just
rely on community decision.
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83
Joshua D. Drake wrote:
[...]
Concurrent psql, nifty but still trying to decide on actual interface.
Full Page Writes Improvement, doesn't actually do anything *yet* (as far
as I can tell) it just makes it so something can be done in the future.
It is also apparently a small patch.UTF8 text matching performance improvements (todo wiki link broke), so I
don't have much comment.
url should be fixed now
On Disk Bitmap indexes (todo wiki link broke): Doesn't support Vacuum
(to my knowledge), community member tested, reported problems... no
response yet from author. The author is known to be time constrained,
boot it till 8.4.
url fixed too
Bitmapscan change, this one is unfortunate because at the time Heikki
had resources and desire but was basically ignored. Sometimes we have to
punt although Heikki is doing patch review right now and it is not
unheard of for a patch reviewer to commit his own patch (in this case we
would need a comitter to actually accept it.).Updateable cursors, apparently breaks explain and patch has been
updated. Punt!Group Commit, Heikki has already suggested that it may be a good idea to
push for 8.4 on this patch: http://momjian.us/mhonarc/patches/msg00127.htmlIndex Advisor.. I think the link is wrong:
url fixed
PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be
developed outside of core. Don't get me wrong I like the feature but it
can take advantage of facilities outside of core.
url fixed - I wonder why we had so much of them and all those pointing
to the patch list bruce maintains - are the urls to the mails there not
stable somehow ?
Stefan
Oleg Bartunov wrote:
On Tue, 15 May 2007, Joshua D. Drake wrote:
Tsearch2 in core. I know that Tom has some reservations, he I and
Treat all commented on how it was done and to my knowledge those
reservations have not been resolved.We'd like to know about these reservations. If I understand you mean
there are issues with the patch ? Our patch is several months old. We
permanently
keep it in sync with CVS HEAD, latest version is 0.47.
http://archives.postgresql.org/pgsql-hackers/2007-01/msg01172.php
Sincerely,
Joshua D. Drake
Stefan Kaltenbrunner wrote:
Joshua D. Drake wrote:
PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be
developed outside of core. Don't get me wrong I like the feature but it
can take advantage of facilities outside of core.url fixed - I wonder why we had so much of them and all those pointing
to the patch list bruce maintains - are the urls to the mails there not
stable somehow ?
They are not stable. The items should point to the archives, which are
supposedly more stable. (I had already fixed one item in PatchStatus
this morning). Really it would be much nicer to have links using the
Message-Id but I doubt that's at all doable.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera wrote:
Stefan Kaltenbrunner wrote:
Joshua D. Drake wrote:
PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be
developed outside of core. Don't get me wrong I like the feature but it
can take advantage of facilities outside of core.url fixed - I wonder why we had so much of them and all those pointing
to the patch list bruce maintains - are the urls to the mails there not
stable somehow ?They are not stable. The items should point to the archives, which are
supposedly more stable. (I had already fixed one item in PatchStatus
this morning). Really it would be much nicer to have links using the
Message-Id but I doubt that's at all doable.
I think we discussed it once... I don't remember the reason why we
didn't go that direction.
Joshua D. Drake
Show quoted text
Alvaro Herrera wrote:
Stefan Kaltenbrunner wrote:
Joshua D. Drake wrote:
PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be
developed outside of core. Don't get me wrong I like the feature but it
can take advantage of facilities outside of core.url fixed - I wonder why we had so much of them and all those pointing
to the patch list bruce maintains - are the urls to the mails there not
stable somehow ?They are not stable. The items should point to the archives, which are
supposedly more stable. (I had already fixed one item in PatchStatus
this morning). Really it would be much nicer to have links using the
Message-Id but I doubt that's at all doable.
hrm - I see so is there a particular reason for that behaviour ?
I will work on pointing to the archives tomorrow ...
Stefan
They are not stable. The items should point to the archives, which are
supposedly more stable. (I had already fixed one item in PatchStatus
this morning). Really it would be much nicer to have links using the
Message-Id but I doubt that's at all doable.
I use this all the time:
http://news.gmane.org/find-root.php?message_id=$MSGID
It uses non-PostgreSQL infrastructure, but hey, I think gmane does list
archives better than PostgreSQL right now ;-)
Try it:
http://news.gmane.org/find-root.php?message_id=20070515201925.GL12731@alvh.no-ip.org
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
Stefan Kaltenbrunner wrote:
Alvaro Herrera wrote:
Stefan Kaltenbrunner wrote:
Joshua D. Drake wrote:
PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be
developed outside of core. Don't get me wrong I like the feature but it
can take advantage of facilities outside of core.url fixed - I wonder why we had so much of them and all those pointing
to the patch list bruce maintains - are the urls to the mails there not
stable somehow ?They are not stable. The items should point to the archives, which are
supposedly more stable. (I had already fixed one item in PatchStatus
this morning). Really it would be much nicer to have links using the
Message-Id but I doubt that's at all doable.hrm - I see so is there a particular reason for that behaviour ?
I will work on pointing to the archives tomorrow ...
Bruce adds and removes emails from the "pgpatches" inbox and I assume he
regenerates the MHonarc archives when he does, which may change the URL
for each specific item. I don't think it was ever intended that the
URLs were to be stable.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
