Bruce Momjian wrote:
That private email list has grown into something official because I am
more thorough about it than most. If the community wants a more
collaborative tool, they can create one or ask for additions to my web
pages. If I need to take my pages offline to help, fine.
If
Alvaro Herrera [EMAIL PROTECTED] writes:
FWIW I've been asking patch submitters (privately) to add the patches
they submit to the May commitfest pages, and they've mostly done it
right away. If you click the history link on the May page you can see
changes from Pavel Stehule, Teodor, Andrew
Gregory Stark wrote:
I would like to suggest a few attributes we want for each patch:
[...]
My first instinct is to convert it to a table. But perhaps we could just stick
these attributes in the current format as sublist items under each major
bullet point.
I agree -- having these
Alvaro Herrera wrote:
Personally I don't think either the March or May wiki pages are accurate
enough, so that isn't a good sign.
To me, what this means is that you're the perfect person to be helping
making the wiki pages more accurate to cover all items that need
attention. The fact
On Thu, Apr 3, 2008 at 4:55 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
That seems like a *really* odd thing for one of the founders of the
world's most advanced OSS DBMS project to say. It's all relational
(which we do do pretty well) - we can add links to the wiki to threads
in the
On Fri, 4 Apr 2008, Dave Page wrote:
We must be talking at cross purposes because I really cannot believe
you're asking me how to add a link to a wiki page :-o
He wants to know how to automate turning an entire mbox file full of them
into wiki markup, now how to do one at a time. Other
Greg Smith [EMAIL PROTECTED] writes:
On Fri, 4 Apr 2008, Dave Page wrote:
We must be talking at cross purposes because I really cannot believe
you're asking me how to add a link to a wiki page :-o
He wants to know how to automate turning an entire mbox file full of them into
wiki markup,
Gregory Stark wrote:
Greg Smith [EMAIL PROTECTED] writes:
He wants to know how to automate turning an entire mbox file full of them
into
wiki markup, now how to do one at a time. Other people have been running
such
tools for Bruce but he doesn't have one he can become comfortable
Alvaro Herrera wrote:
BTW, Greg Stark already dumped the patch queue into a wiki page some
time ago: http://wiki.postgresql.org/wiki/CommitFest:Bruce Do you think
that's more useful than the other commitfest layout? I don't.
No.
The bottom line is that I used to do this tracking in my own
Bruce Momjian [EMAIL PROTECTED] writes:
Basically a Wiki takes 10x more time for me to modify something, so
unless I get another 9 people to do the same amount of work I do on
tracking, we are going to fall behind. I am not willing to increase the
amount of time I already spend doing this.
Gregory Stark [EMAIL PROTECTED] writes:
Bruce Momjian [EMAIL PROTECTED] writes:
Basically a Wiki takes 10x more time for me to modify something, so
unless I get another 9 people to do the same amount of work I do on
tracking, we are going to fall behind. I am not willing to increase the
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Bruce Momjian [EMAIL PROTECTED] writes:
Basically a Wiki takes 10x more time for me to modify something, so
unless I get another 9 people to do the same amount of work I do on
tracking, we are going to fall behind. I am not willing
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
The hard part is reading the email and figuring out
what status the patch is in.
Certainly. What we've got to do is make sure that after someone has
made that decision, it doesn't cost them a couple of minutes of
Bruce Momjian [EMAIL PROTECTED] writes:
I think ultimately we are going to have to remove the patches email list
and require patch submitters to add their patches to a patch tracker.
That's outright silly. The email list and archives are a critical part
of what we do, because they provide a
Tom Lane wrote:
The patch queue is by definition transient --- nobody particularly cares
about what its past state was, as shown by the fact that you've gotten
along for years with an implementation that's incapable of recalling
past state. (Now I do like the idea that a wiki-based patch
On Fri, 04 Apr 2008 22:37:17 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I think ultimately we are going to have to remove the patches email
list and require patch submitters to add their patches to a patch
tracker.
That's outright silly. The email
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Saturday, April 05, 2008 03:37:08 +0100 Gregory Stark
[EMAIL PROTECTED] wrote:
It probably would be neat if the email footer thingy added a url to each email
it distributed via the lists pointing to the permanent message-id-based url in
On Thu, Apr 3, 2008 at 12:35 AM, Bruce Momjian [EMAIL PROTECTED] wrote:
It is not clear to me how a wiki can be easily created for 2k emails and
then maintained in a reasonable way, or how emails can be added to it
easily.
That seems like a *really* odd thing for one of the founders of the
The one concern I have with the way the last commitfest went (and I say
this as strictly an observer), there was no discussion on anything.
Now, I know that discussion happened, but it happened somewhere, in some
web-forum, in a community that seems to generally promote mailing lists
as the
Aidan Van Dyk [EMAIL PROTECTED] writes:
The one concern I have with the way the last commitfest went (and I say
this as strictly an observer), there was no discussion on anything.
Umm ... in the first place, the fest isn't over yet. In the second
place, the reason you haven't seen much
Dave Page wrote:
On Thu, Apr 3, 2008 at 12:35 AM, Bruce Momjian [EMAIL PROTECTED] wrote:
It is not clear to me how a wiki can be easily created for 2k emails and
then maintained in a reasonable way, or how emails can be added to it
easily.
That seems like a *really* odd thing for one
On Wed, 2 Apr 2008, Bruce Momjian wrote:
The new permanent ones are permanent against mailbox movement, and in
fact the comments and thread merging also travels with the email.
The someone replied to your comment links in e-messages I've been
getting the last few days have all been working,
Greg Smith [EMAIL PROTECTED] writes:
Those hacking on tools to convert Bruce's currently preferred working form
(that revolves around mbox files) into something else that's web oriented
are stuck with considering how all the above information is going to be
handled before everybody will be
Tom Lane wrote:
For the past couple of weeks I've been dealing with both Bruce's queue
and the one at
http://wiki.postgresql.org/wiki/CommitFest:March
and frankly I find the latter a *whole* lot more satisfactory, despite
the fact that it's got exactly zero custom tooling or infrastructure
Tom Lane wrote:
For the past couple of weeks I've been dealing with both Bruce's queue
and the one at
http://wiki.postgresql.org/wiki/CommitFest:March
and frankly I find the latter a *whole* lot more satisfactory, despite
the fact that it's got exactly zero custom tooling or infrastructure
I have found a way to have permanent URLs that stay permanent even if
the email is moved from the patches queue to the patches_hold queue.
The trick is to use base to specify the base directory in the html.
The new URLs look like:
http://momjian.us/mhonarc/message-id/[EMAIL PROTECTED]
On Thu, 2008-03-27 at 11:18 -0400, Bruce Momjian wrote:
The new URLs look like:
http://momjian.us/mhonarc/message-id/[EMAIL PROTECTED]
The new URLs appear now. The old permanent will also remain active
until the next commit fest.
If they are going to be permanent then they should
On Thu, Mar 27, 2008 at 3:44 PM, Simon Riggs [EMAIL PROTECTED] wrote:
On Thu, 2008-03-27 at 11:18 -0400, Bruce Momjian wrote:
The new URLs look like:
http://momjian.us/mhonarc/message-id/[EMAIL PROTECTED]
The new URLs appear now. The old permanent will also remain active
Simon Riggs wrote:
On Thu, 2008-03-27 at 11:18 -0400, Bruce Momjian wrote:
The new URLs look like:
http://momjian.us/mhonarc/message-id/[EMAIL PROTECTED]
The new URLs appear now. The old permanent will also remain active
until the next commit fest.
If they are going to be
Dave Page wrote:
On Thu, Mar 27, 2008 at 3:44 PM, Simon Riggs [EMAIL PROTECTED] wrote:
On Thu, 2008-03-27 at 11:18 -0400, Bruce Momjian wrote:
The new URLs look like:
http://momjian.us/mhonarc/message-id/[EMAIL PROTECTED]
The new URLs appear now. The old permanent
On Feb 6, 2008 1:52 PM, Alvaro Herrera [EMAIL PROTECTED] wrote:
Josh Berkus escribió:
I think we might want to do something along the lines of what Stefan set up
(at least I think it was he) for the end of 8.4 on developer.postgresql.org.
Bruce's patch list is easy to update, but hard to
On Wed, 2007-09-12 at 17:47 -0400, Bruce Momjian wrote:
For those who have forgotten the progress we have made toward 8.3, here
are the open patches we had for 8.3 as of May 1, 2006:
Could you please issue a list of open items for 8.3?
I want to check whether you are waiting on me for anything
Pavan Deolasee wrote:
On 9/13/07, Bruce Momjian [EMAIL PROTECTED] wrote:
For those who have forgotten the progress we have made toward 8.3, here
are the open patches we had for 8.3 as of May 1, 2006:
You mean May 1, 2007 ;-)
Yea, sorry.
--
Bruce Momjian [EMAIL PROTECTED]
Simon Riggs wrote:
On Wed, 2007-09-12 at 17:47 -0400, Bruce Momjian wrote:
For those who have forgotten the progress we have made toward 8.3, here
are the open patches we had for 8.3 as of May 1, 2006:
Could you please issue a list of open items for 8.3?
I want to check whether you are
For those who have forgotten the progress we have made toward 8.3, here
are the open patches we had for 8.3 as of May 1, 2006:
---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
FYI, Tom, Heikki, I need one of
On 9/13/07, Bruce Momjian [EMAIL PROTECTED] wrote:
For those who have forgotten the progress we have made toward 8.3, here
are the open patches we had for 8.3 as of May 1, 2006:
You mean May 1, 2007 ;-)
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
Tom Lane wrote:
At this point it seems nothing will be done about this issue for 8.3.
* [PATCHES] plpgpsm /Pavel Stehule/
I think this has to be held for 8.4: it was submitted too late for the 8.3
feature deadline, and in fact I don't recall that there was any community
discussion/consensus
Pavan Deolasee wrote:
I suppose inserting HOT tuples without index maintenance is useful
even if no
changes to the space allocation is made is useful. It won't get the
space
usage but it would save on index thrashing. But that still implies
all the
code to handle
Joshua D. Drake wrote:
Tom Lane wrote:
At this point it seems nothing will be done about this issue for 8.3.
* [PATCHES] plpgpsm /Pavel Stehule/
I think this has to be held for 8.4: it was submitted too late for the 8.3
feature deadline, and in fact I don't recall that there was
On 5/17/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
Pavan Deolasee wrote:
There are few things that we can separate easily, like CREATE INDEX
related changes, VACUUM and VACUUM FULL related changed, space
reuse related changes etc. Let me give it a shot.
Did we ever get a broken up
Joshua D. Drake wrote:
Pavan Deolasee wrote:
I suppose inserting HOT tuples without index maintenance is useful
even if no
changes to the space allocation is made is useful. It won't get the
space
usage but it would save on index thrashing. But that still implies
all
Heikki Linnakangas wrote:
There are few things that we can separate easily, like CREATE INDEX
related changes, VACUUM and VACUUM FULL related changed, space
reuse related changes etc. Let me give it a shot.
Did we ever get a broken up patch for this?
Yes:
Sorry for late responce due to very long vacation season in Japan.
Tom Lane wrote:
* Re: [PATCHES] [HACKERS] Full page writes improvement, code update
/Koichi Suzuki/
I feel that we have to insist that this be modified to not create
any WAL
bloat in the pre-compression form.
On 5/2/07, Gregory Stark [EMAIL PROTECTED] wrote:
Can we? I mean, sure you can break the patch up into chunks which might
make
it easier to read, but are any of the chunks useful alone?
Well I agree, it would be a tough job. I can try and break the patch into
several self-complete
On 5/2/07, Tom Lane [EMAIL PROTECTED] wrote:
* [PATCHES] HOT Patch - Ready for review /Pavan Deolasee/
This needs a *lot* of review. Can we break it down into more manageable
chunks? I'm not sure that anyone's got a full grasp of the implications
of this patch, and that's a scary thought.
On Tue, 1 May 2007, Tom Lane wrote:
* [HACKERS] tsearch_core patch for inclusion
/Teodor Sigaev/
Have we resolved whether the API and the dump/restore strategy are
acceptable? The code needs review too, but not till we've settled
on the basic question whether we like the feature set.
Hello Tom,
All what you wrote is true. plpgpsm copies-and-pastes about 30% of code and
It is terrible for long run. But when I can change it? Writing differnt
runtime is nonsense, better way is refactoring plpgsql and then sharing code
with its. It's not propable in 8.4 .. there will by lot
* [PATCHES] Updateable cursors patch /FAST PostgreSQL/
This is incomplete, and I fear at this point has to be held over to 8.4.
It is true that my original patch post said that I need to modify the
patch to work with tidscan. Since then I have realized that this
modification is not needed
Pavan Deolasee [EMAIL PROTECTED] writes:
On 5/2/07, Tom Lane [EMAIL PROTECTED] wrote:
This needs a *lot* of review. Can we break it down into more manageable
chunks?
Sure, we can do that. I actually did that when I posted the
incremental versions of the HOT-patch, each version
Tom Lane [EMAIL PROTECTED] writes:
Bruce Momjian [EMAIL PROTECTED] writes:
FYI, Tom, Heikki, I need one of you to post the list of patches and
where we think we are on each one, even if the list is imperfect.
This message is an attempt to sort out which patch queue entries have
no hope of
On Tue, May 01, 2007 at 10:44:38PM -0400, Tom Lane wrote:
* [PATCHES] Preliminary GSSAPI Patches /Henry B. Hotz/
Magnus is reviewing this one.
Check.
* [PATCHES] Clear up strxfrm() in UTF-8 with locale on Windows
/ITAGAKI Takahiro/
Someone else needs to look at this; I can't
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Bruce Momjian [EMAIL PROTECTED] writes:
FYI, Tom, Heikki, I need one of you to post the list of patches and
where we think we are on each one, even if the list is imperfect.
This message is an attempt to sort out which patch
Bruce Momjian [EMAIL PROTECTED] writes:
Then, figure out where the gains on the non-TEXT field seem to diminish
in usefulness. Basically, with a lower TOAST value, we are going to
spend more time accessing the TEXT field, but the speedup for the
non-TEXT field should be large enough win
Another complexity is testing cases where the table fits in shared
memory/RAM, and those that don't, and testing cases where heap fits in
RAM only because we pushed things to TOAST, and cases where we have to
do lots of TOAST access that doesn't fit in RAM. I wonder if it is even
worth testing
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
FYI, Tom, Heikki, I need one of you to post the list of patches and
where we think we are on each one, even if the list is imperfect.
This message is an attempt to sort out which patch queue entries have
no hope of getting into
Tom Lane wrote:
* [pgsql-patches] Ctid chain following enhancement
/Pavan Deolasee/
I'm not very excited about this --- it seems to me to complicate the code
in some places that are not in fact performance-critical. While it
doesn't seem likely to break things, I'm not in favor of
http://www.sigaev.ru/misc/tsearch_core-0.46.gz
Patch is synced with current CVS HEAD and synced with bugfixes in
contrib/tsearch2
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
On Tue, 2007-05-01 at 22:44 -0400, Tom Lane wrote:
Nice summary Tom.
* Re: [PATCHES] [Fwd: Deferred Transactions, Transaction Guarantee
and COMMITwithout waiting] /Simon Riggs/
Simon is on the hook to submit an updated patch. I hope this one
makes it in, as it looks like a really
Bruce Momjian [EMAIL PROTECTED] writes:
FYI, Tom, Heikki, I need one of you to post the list of patches and
where we think we are on each one, even if the list is imperfect.
This message is an attempt to sort out which patch queue entries have
no hope of getting into 8.3 (and so we shouldn't
On Tue, 1 May 2007, Tom Lane wrote:
* Re: [PATCHES] Synchronized Scan WIP patch
/Simon Riggs/
Heikki is reviewing this one. Also I believe Greg Smith is doing more
performance testing.
Actually it was the Automatic adjustment of bgwriter_lru_maxpages patch
from Itagaki Takahiro I've
Greg Smith [EMAIL PROTECTED] writes:
On Tue, 1 May 2007, Tom Lane wrote:
* Re: [PATCHES] Synchronized Scan WIP patch
/Simon Riggs/
Heikki is reviewing this one. Also I believe Greg Smith is doing more
performance testing.
Actually it was the Automatic adjustment of bgwriter_lru_maxpages
On 5/2/07, Tom Lane [EMAIL PROTECTED] wrote:
* [pgsql-patches] Ctid chain following enhancement
/Pavan Deolasee/
I'm not very excited about this --- it seems to me to complicate the code
in some places that are not in fact performance-critical. While it
doesn't seem likely to break
My feeling is we should have more regular sync points where the
patch
queue is emptied and everything committed or rejected.
No doubt, but the real problem here is that
reviewing/committing other people's patches is not fun, it's
just work :-(. So it's no surprise that it tends to
On Thu, 2007-03-29 at 01:34 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
My feeling is we should have more regular sync points where the patch
queue is emptied and everything committed or rejected.
No doubt, but the real problem here is that reviewing/committing other
Tom Lane [EMAIL PROTECTED] writes:
Simon Riggs [EMAIL PROTECTED] writes:
My feeling is we should have more regular sync points where the patch
queue is emptied and everything committed or rejected.
No doubt, but the real problem here is that reviewing/committing other
people's patches is
Gregory Stark wrote:
Obviously a big part of that is that we just don't have enough committers. I'm
hopeful that in time that situation will improve but in the meantime we do
have a problem and the burden falls unfairly on a few.
Is there anything others can do to help? If non-committers like
Andrew Dunstan [EMAIL PROTECTED] writes:
There is plenty of scope for people to review patches if they aren't
committers. In fact, it is highly encouraged. Please review anything on
the patch list you feel able to.
Sure. Even if you miss things, every problem you do spot is one less...
and
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
It favours people who are short-sighted and don't see what possible
improvements their code has. No code in an ongoing project like this is
ever
completed anyways.
It favors those who do not wait until the last minute,
We don't want open-ended a few days before feature feeze. We want them
to be as done, at some complete stopping point, and submitted.
OK, but we don't want something that is ready to be committed, we need
it complete.
So how many more releases before you think Postgres is complete?
I am
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
My feeling is we should have more regular sync points where the patch
queue is emptied and everything committed or rejected.
No doubt, but the real problem here is that reviewing/committing other
people's patches is not fun, it's just
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Simon Riggs [EMAIL PROTECTED] writes:
My feeling is we should have more regular sync points where the patch
queue is emptied and everything committed or rejected.
No doubt, but the real problem here is that reviewing/committing
Bruce Momjian wrote:
OK, but we don't want something that is ready to be committed, we need
it complete.
So how many more releases before you think Postgres is complete?
I am getting tired of your semantic games, here, Greg. I have no idea
what you are trying to accomplish, but I have
Bruce Momjian [EMAIL PROTECTED] writes:
The basic problem is we have a lot of complex patches coming in, and
many from people who do not have years of experience with submitting
patches to PostgreSQL. A complex patch from a novice user takes a lot
of time to review, and frankly, we don't have
Hello,
I found in queue patch simply custom variables protection, Pavel Stehule
which you removed and didn't find my patch for scrollable cursors in
plpgsql.
Regards
Pavel Stehule
_
Emotikony a pozadi programu MSN Messenger
Josh Berkus wrote:
Bruce,
However, with feature freeze coming on Sunday, I am worried because
there are a significant number of patches that have are not ready for
review because they have not been completed by their authors.
Can you flag those somehow?
I have sent out email on every
Bruce Momjian [EMAIL PROTECTED] writes:
Right now, all the patches I think are ready for review are in the patch
queue:
http://momjian.postgresql.org/cgi-bin/pgpatches
However, with feature freeze coming on Sunday, I am worried because
there are a significant number of patches that
On Tue, 2007-03-27 at 21:15 -0400, Bruce Momjian wrote:
Right now, all the patches I think are ready for review are in the patch
queue:
http://momjian.postgresql.org/cgi-bin/pgpatches
However, with feature freeze coming on Sunday, I am worried because
there are a significant number
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Right now, all the patches I think are ready for review are in the patch
queue:
http://momjian.postgresql.org/cgi-bin/pgpatches
However, with feature freeze coming on Sunday, I am worried because
there are a
Simon Riggs wrote:
On Tue, 2007-03-27 at 21:15 -0400, Bruce Momjian wrote:
Right now, all the patches I think are ready for review are in the patch
queue:
http://momjian.postgresql.org/cgi-bin/pgpatches
However, with feature freeze coming on Sunday, I am worried because
there
at seems like a bit of a whacky criterion to use before reviewing a patch.
wacky?
It favours people who are short-sighted and don't see what possible
improvements their code has. No code in an ongoing project like this is ever
completed anyways.
It favors those who do not wait until the
Joshua D. Drake wrote:
at seems like a bit of a whacky criterion to use before reviewing a patch.
wacky?
It favours people who are short-sighted and don't see what possible
improvements their code has. No code in an ongoing project like this is
ever
completed anyways.
It
On Wed, 2007-03-28 at 15:48 -0400, Bruce Momjian wrote:
What about the delayed fsync patch?
All complete bar two fiddly items, as of Mar 11, design-to-complete
posted along with patch.
Working on those now.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
Bruce Momjian [EMAIL PROTECTED] writes:
Simon Riggs wrote:
It's probably a good idea to have a queue of those too, to allow others
to finish them if the original author hasn't/can't/won't. I'm not sure
which ones you mean.
At this point, with four days left before feature freeze, if the
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Simon Riggs wrote:
It's probably a good idea to have a queue of those too, to allow others
to finish them if the original author hasn't/can't/won't. I'm not sure
which ones you mean.
At this point, with four days left
On Wed, 2007-03-28 at 17:02 -0400, Bruce Momjian wrote:
they
It would be good to know who/what you're talking about, specifically.
Some patchers may think they have completed their work.
Not a name-and-shame, just fair warning their work is considered
incomplete and is about to be rejected as
Simon Riggs wrote:
On Wed, 2007-03-28 at 17:02 -0400, Bruce Momjian wrote:
they
It would be good to know who/what you're talking about, specifically.
Some patchers may think they have completed their work.
Not a name-and-shame, just fair warning their work is considered
incomplete
Bruce Momjian wrote:
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Simon Riggs wrote:
It's probably a good idea to have a queue of those too, to allow others
to finish them if the original author hasn't/can't/won't. I'm not sure
which ones you mean.
Joshua D. Drake wrote:
My assumption is if authors don't finish them in the next few days, they
are unlikely to finish them during some grace period during feature
freeze. And the extra time is usually allowed for changes requested by
committers, while at this point the authors aren't
Perhaps it makes sense to say:
Feature Freeze: April 1st., no new patches accepted for 8.3
Patch Freeze April 15th., Authors have until the 15th to address any
committer concerns
Well, I am OK with that, but we need _community_ agreement on that.
I realize it isn't fair that committers
On Wed, 2007-03-28 at 17:12 -0400, Bruce Momjian wrote:
Simon Riggs wrote:
On Wed, 2007-03-28 at 17:02 -0400, Bruce Momjian wrote:
they
It would be good to know who/what you're talking about, specifically.
Some patchers may think they have completed their work.
Not a
On Wed, 28 Mar 2007, Simon Riggs wrote:
On Wed, 2007-03-28 at 17:12 -0400, Bruce Momjian wrote:
If everybody knows where everybody stands then we'll all be better off.
There may be other dependencies that need resolution, or last minute
decisions required to allow authors to finish.
Wasn't
On Wed, 2007-03-28 at 17:37 -0400, Bruce Momjian wrote:
I realize it isn't fair that committers are behind on patches, while we
are expecting submitters to make the deadline, but there are far fewer
committers than submitters, and there was never a promise to commit
everything before feature
Bruce Momjian [EMAIL PROTECTED] writes:
It favours people who are short-sighted and don't see what possible
improvements their code has. No code in an ongoing project like this is ever
completed anyways.
It favors those who do not wait until the last minute, but complete them
well before
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
That's silly, of course people are still working on them, many of these tasks
are open ended and can be improved as long as we have time. just because
they're still working on them doesn't necessarily mean what they have so far
isn't
Gregory Stark wrote:
In any case I think Simon and you have fallen into the trap of thinking of
development as a single-person project. Most developers here, especially
first-time contributors, don't just work in the dark on their own and turn up
with a finished patch. They have questions and
Simon Riggs [EMAIL PROTECTED] writes:
My feeling is we should have more regular sync points where the patch
queue is emptied and everything committed or rejected.
No doubt, but the real problem here is that reviewing/committing other
people's patches is not fun, it's just work :-(. So it's no
Right now, all the patches I think are ready for review are in the patch
queue:
http://momjian.postgresql.org/cgi-bin/pgpatches
However, with feature freeze coming on Sunday, I am worried because
there are a significant number of patches that have are not ready for
review because they
Bruce,
However, with feature freeze coming on Sunday, I am worried because
there are a significant number of patches that have are not ready for
review because they have not been completed by their authors.
Can you flag those somehow?
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
On 1/30/07, Bruce Momjian [EMAIL PROTECTED] wrote:
FYI, I have been working all January to process 8.3 held patches/ideas,
plus process the items arriving during the month. While I have been
able to make some progress, there are still a significant number of
items for me to address. I will
Jaime Casanova wrote:
On 1/30/07, Bruce Momjian [EMAIL PROTECTED] wrote:
FYI, I have been working all January to process 8.3 held patches/ideas,
plus process the items arriving during the month. While I have been
able to make some progress, there are still a significant number of
items
1 - 100 of 111 matches
Mail list logo
