What is our plan for pgindent for 8.4? I would rather not have to bug
someone to create a list of symbols manually. I would like it to be
built on a regular basis and I can pull it from there and add it to CVS
when I run pgindent.
I will try to look at it again in a few days.
cheers
andrew
Bruce Momjian wrote:
What is our plan for pgindent for 8.4? I would rather not have to bug
someone to create a list of symbols manually. I would like it to be
built on a regular basis and I can pull it from there and add it to CVS
Tom Lane wrote:
[ click click... ] A quick grep counts 2154 occurrences of the word
'typedef' in our tree. Some of them are no doubt false hits
(documentation etc), but on the other hand you need to add typedefs
coming from system headers.
doxygen's 200-some is clearly an order of
Bruce Momjian wrote:
pgindent is probably 97% optimal. Getting a better typedef list will
change that to perhaps 97.2% optimal. There is a lot of discussion
happening to try to get that 0.2%. :-O
If I'm allowed to make my own guesses I'd say pgindent is at about 90%
currently and we could
Alvaro Herrera wrote:
Bruce Momjian wrote:
pgindent is probably 97% optimal. Getting a better typedef list will
change that to perhaps 97.2% optimal. There is a lot of discussion
happening to try to get that 0.2%. :-O
If I'm allowed to make my own guesses I'd say pgindent is at
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Greg Smith wrote:
Scraping that HTML seems like it would be pretty straightforward.
It's awfully incomplete. Bruce said to me the other day on IM that the
list he was getting with the Linux version of find_typedef
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
doxygen's 200-some is clearly an order of magnitude too low, but I
wonder whether Bruce's list hasn't got some false hits ...
Skimming the output it does have things like int and float but presumably
we would know if that caused any
Gregory Stark wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
doxygen's 200-some is clearly an order of magnitude too low, but I
wonder whether Bruce's list hasn't got some false hits ...
Skimming the output it does have things like int and float but
Andrew Dunstan [EMAIL PROTECTED] writes:
It looks like Windows will blow all our existing numbers out of the
water. Here's a list generated from Cygwin with 6088 symbols. I'm
working on getting a similar list from MinGW.
Hmm, your toolset must be listing all typedefs present in the header
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
It looks like Windows will blow all our existing numbers out of the
water. Here's a list generated from Cygwin with 6088 symbols. I'm
working on getting a similar list from MinGW.
Hmm, your toolset must be listing all
Andrew Dunstan wrote:
Gregory Stark wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
doxygen's 200-some is clearly an order of magnitude too low, but I
wonder whether Bruce's list hasn't got some false hits ...
Skimming the output it does have things like
Andrew Dunstan wrote:
And here are the 7625 from MinGW.
http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=dawn_batdt=2008-04-19%20004514stg=typedefs
It looks like we'll need some sort of extra filter.
Hmm. Wow. For example I see
FINDREPLACE
FINDREPLACEA
FINDREPLACEW
We use
Alvaro Herrera [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
It looks like we'll need some sort of extra filter.
Hmm. Wow. For example I see
FINDREPLACE
FINDREPLACEA
FINDREPLACEW
We use neither ... My guess is that they are used in the system DLLs or
something like that.
Andrew Dunstan wrote:
Skimming the output it does have things like int and float but
presumably
we would know if that caused any problem, they wouldn't inflate the numbers
much.
2800 does seem a bit high. My buildfarm member dungbeetle just found 2482
on a
build that is only
Bruce Momjian [EMAIL PROTECTED] writes:
As soon as you have a stable typedef file we can all use please update
the pgindent README to point to that URL. Keep the instructions of how
to create it in our tree so we have it for future reference.
If we're going to go down this path, why would we
Bruce Momjian wrote:
I have created a proper typedef file that I would normally use for a
pgindent run of the entire tree (it has /contrib, 2628 entries). It is
at:
http://momjian.us/expire/pgtypedefs.bsdos
Well, there are typedefs in there not used anywhere in our code, for
example
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
As soon as you have a stable typedef file we can all use please update
the pgindent README to point to that URL. Keep the instructions of how
to create it in our tree so we have it for future reference.
If we're going to go down
Alvaro Herrera wrote:
Bruce Momjian wrote:
I have created a proper typedef file that I would normally use for a
pgindent run of the entire tree (it has /contrib, 2628 entries). It is
at:
http://momjian.us/expire/pgtypedefs.bsdos
Well, there are typedefs in there not used
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
It looks like we'll need some sort of extra filter.
Hmm. Wow. For example I see
FINDREPLACE
FINDREPLACEA
FINDREPLACEW
We use neither ... My guess is that they are used in the system DLLs or
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
If we're going to go down this path, why would we not put the
reference typedef list into CVS?
Uh, I assume we don't want an automated system updating the file in CVS.
Nowhere did I suggest that. What I suggested is that the considered
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
If we're going to go down this path, why would we not put the
reference typedef list into CVS?
Uh, I assume we don't want an automated system updating the file in CVS.
Nowhere did I suggest that. What I
Alvaro Herrera [EMAIL PROTECTED] writes:
It does take a while to run though ... it's not something we'll want to
do routinely.
Well, we're not going to want to change the reference typedef list very
often anyway, because it'd just result in whitespace-thrashing in the
repository. I'm thinking
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
It does take a while to run though ... it's not something we'll want to
do routinely.
Well, we're not going to want to change the reference typedef list very
often anyway, because it'd just result in whitespace-thrashing in the
Bruce Momjian [EMAIL PROTECTED] writes:
I have no problem using a URL to pull down the typedef list via wget.
How is that CVS file going to be updated?
I do not follow your thought process. You would rather depend on a URL
that has no visible commit history?
As I already noted elsewhere in
Bruce Momjian [EMAIL PROTECTED] writes:
Does someone want to look at improving the pgindent script itself?
I notice that you've carefully ignored the suggestion of re-testing
GNU indent.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I have no problem using a URL to pull down the typedef list via wget.
How is that CVS file going to be updated?
I do not follow your thought process. You would rather depend on a URL
that has no visible commit history?
This does
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Does someone want to look at improving the pgindent script itself?
I notice that you've carefully ignored the suggestion of re-testing
GNU indent.
No. Why would I carefully ignore testing GNU indent? Because I am
afraid pgindent
Alvaro Herrera wrote:
Bruce Momjian wrote:
Alvaro Herrera wrote:
Maybe this means that we should give pgindent a run over the back
branches.
Yea, that thought has crossed our minds, but the problem is that there
is little testing of back branches so it would be risky.
That's a fair point,
On Thu, Apr 17, 2008 at 09:11:12AM +0300, Heikki Linnakangas wrote:
Something like this:
if (foo)
{
do something;
do something else;
}
...
-
if (foo)
do something;
do something else;
...
I doubt it, indent doesn't know nearly enough C to be able to anything
Bruce Momjian wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am reviewing the psql wrap patch and just used pgindent today
to clean it up. (pgindent did not add any extra spacing
changes.) Patch reviewers should probably be able to run
Martijn van Oosterhout wrote:
I doubt it, indent doesn't know nearly enough C to be able to anything
other than adjust whitespace. It surely won't remove braces...
I faintly recall that it does or at least did at some point.
--
Sent via pgsql-hackers mailing list
Peter Eisentraut wrote:
Martijn van Oosterhout wrote:
I doubt it, indent doesn't know nearly enough C to be able to anything
other than adjust whitespace. It surely won't remove braces...
I faintly recall that it does or at least did at some point.
It used to remove braces around
Magnus Hagander wrote:
Bruce Momjian wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am reviewing the psql wrap patch and just used pgindent today
to clean it up. (pgindent did not add any extra spacing
changes.) Patch reviewers
Bruce Momjian wrote:
Magnus Hagander wrote:
Bruce Momjian wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am reviewing the psql wrap patch and just used pgindent
today to clean it up. (pgindent did not add any extra
spacing
Bruce Momjian wrote:
Magnus Hagander wrote:
IIRC, last time I tried it, the failure was because I couldn't get it
to build the proper typedefs. Any chance you could just put a regularly
updated typedefs file somewhere that I could wget down?
Have you tried the CVS version? It should
Magnus Hagander wrote:
Also I can put up a web page where you can upload or email your C
file and get a formatted version back.
IIRC, last time I tried it, the failure was because I couldn't get
it to build the proper typedefs. Any chance you could just put a
regularly updated
Alvaro Herrera wrote:
Bruce Momjian wrote:
Magnus Hagander wrote:
IIRC, last time I tried it, the failure was because I couldn't get it
to build the proper typedefs. Any chance you could just put a regularly
updated typedefs file somewhere that I could wget down?
Have you tried
Bruce Momjian wrote:
The source code is the same for both Unix and Windows but you are right
some typedefs are only visible on windows. I think most are from
EXEC_BACKEND so compiling with/without that should help but then you
have to merge the typedef lists, of course.
The source code is
Alvaro Herrera [EMAIL PROTECTED] writes:
What are we going to do about the duality of Windows vs. non-Windows?
Perhaps we could collect typedefs generated on the buildfarm.
I think it's really not acceptable that pgindent misformats Windows-only
code (or any other part of the code that Bruce
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
What are we going to do about the duality of Windows vs. non-Windows?
Perhaps we could collect typedefs generated on the buildfarm.
I think it's really not acceptable that pgindent misformats Windows-only
code (or any other part of
Bruce Momjian wrote:
Based on that reaction I am not going to bother uploading my copy of the
typedefs.
Please reconsider. Not having pgindent work at all is not better than
it working only 98%.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL
Alvaro Herrera wrote:
Bruce Momjian wrote:
Based on that reaction I am not going to bother uploading my copy of the
typedefs.
Please reconsider. Not having pgindent work at all is not better than
it working only 98%.
That's what I thought, but Tom thinks my list is unacceptable. What
Alvaro Herrera wrote:
Bruce Momjian wrote:
Based on that reaction I am not going to bother uploading my copy of the
typedefs.
Please reconsider. Not having pgindent work at all is not better than
it working only 98%.
I have been thinking of pursuing your suggestion of having
Alvaro Herrera [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
Based on that reaction I am not going to bother uploading my copy of the
typedefs.
Please reconsider. Not having pgindent work at all is not better than
it working only 98%.
I think I'm rescinding my objection to checking a
Andrew Dunstan wrote:
I have been thinking of pursuing your suggestion of having it as a
buildfarm option. We could provide a SOAP interface to collect the
typedefs and then consolidate them and put them in CVS. We could even do
it per release. That would include Windows, although only
Gregory Stark wrote:
The only thing is that if the whole point is to have patch submitters run
pgindent on their own added code it won't work since their own code will be
precisely the code with the missing typedefs. How easy is it to manually add a
handful of typedefs to the list?
The list
Andrew Dunstan [EMAIL PROTECTED] writes:
I have been thinking of pursuing your suggestion of having it as a
buildfarm option. We could provide a SOAP interface to collect the
typedefs and then consolidate them and put them in CVS. We could even do
it per release. That would include Windows,
[EMAIL PROTECTED] (Tom Lane) writes:
Chris Browne [EMAIL PROTECTED] writes:
Would it be a terrible idea to...
- Draw the indent code from NetBSD into src/tools/pgindent
I am not real eager to become maintainers of our own indent fork, which
is what you propose. (Just for starters, what
Tom Lane [EMAIL PROTECTED] writes:
Andrew Dunstan [EMAIL PROTECTED] writes:
I have been thinking of pursuing your suggestion of having it as a
buildfarm option. We could provide a SOAP interface to collect the
typedefs and then consolidate them and put them in CVS. We could even do
it
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
That would certainly be better than the current approach, since
presumably it would cover not only Windows but the other
conditionally-compiled stuff that Bruce chooses not to compile on
his own machine.
It would, as
* Tom Lane [EMAIL PROTECTED] [080417 20:11]:
3) How would this work with typedefs which come from system or library
includes?
Ouch, that's a real good point. Maybe a certain amount of platform
dependence is inevitable.
I don't get it. If they are used as typedefs *anywhere* in the
Aidan Van Dyk [EMAIL PROTECTED] writes:
* Tom Lane [EMAIL PROTECTED] [080417 20:11]:
Ouch, that's a real good point. Maybe a certain amount of platform
dependence is inevitable.
I don't get it. If they are used as typedefs *anywhere* in the PG
source, they're needed in the typedef list.
* Tom Lane [EMAIL PROTECTED] [080417 20:47]:
Right, but if the only use is inside #ifdef __BRAND_X_PLATFORM__,
the only way for the proposed toolchain to extract that usage is
if someone runs it on BRAND_X_PLATFORM.
Of course, for seldom-used platforms maybe we don't care that much.
But
Tom Lane [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
1) I take it we feel safe guaranteeing that we won't use any fancy macros
inside typedefs. So no '#define pgtype(x) _pg_##x' or anythin like
Gregory Stark wrote:
But if we're still doing object file analysis on the build farm and it's easy
to add typedefs manually then perhaps there's not much effort saved by having
such a tool. I think it would be possible to write but it wouldn't really be
easy. You have to parse just enough C to
On Fri, 18 Apr 2008, Gregory Stark wrote:
The reason I was asking these questions was because I was thinking about
how hard it would be to generate the list from a textual analysis
instead of using object files.
Is there some reason I don't understand why the listing doyxgen creates
isn't
Greg Smith wrote:
On Fri, 18 Apr 2008, Gregory Stark wrote:
The reason I was asking these questions was because I was thinking
about how hard it would be to generate the list from a textual analysis
instead of using object files.
Is there some reason I don't understand why the listing
Alvaro Herrera [EMAIL PROTECTED] writes:
Greg Smith wrote:
Scraping that HTML seems like it would be pretty straightforward.
It's awfully incomplete. Bruce said to me the other day on IM that the
list he was getting with the Linux version of find_typedef was something
like 2800 symbols. I
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Greg Smith wrote:
Scraping that HTML seems like it would be pretty straightforward.
It's awfully incomplete. Bruce said to me the other day on IM that the
list he was getting with the Linux version of find_typedef was something
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Apr 16, 2008 at 2:17 AM, Joshua D. Drake wrote:
On Tue, 15 Apr 2008 12:12:24 -0400
Alvaro Herrera wrote:
Tom Lane wrote:
I tend to just fix this stuff while committing, rather than lecture
the submitters about it, but it
On Apr 14, 2008, at 4:15 PM, Bruce Momjian wrote:
If you don't want an issue to get forgotten, then make a TODO
entry for
it. But the purpose of commit fest is to make sure we deal with
things
that can be dealt with in a timely fashion. It's not going to cause
solutions to unsolved
Hi,
The idea that we fix stylistic issues on the fly is not sustainable.
We should offer help and mentorship to new patch submitters in all
areas (including stylistic) but they should do the work. It is the only
way we will mold them to submit patches in the proper way.
I agree.
NikhilS wrote:
Hi,
The idea that we fix stylistic issues on the fly is not
sustainable.
We should offer help and mentorship to new patch submitters in
all areas (including stylistic) but they should do the work. It
is the only way we will mold them to submit patches in the proper
Magnus Hagander [EMAIL PROTECTED] writes:
I think pg_indent has to be made a lot more portable and easy to use
before that can happen :-) I've run it once or twice on linux machines,
and it comes out with huge changes compared to what Bruce gets on his
machine.
Yeah, I've had no luck with it
On Wed, Apr 16, 2008 at 1:07 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
I think pg_indent has to be made a lot more portable and easy to use
before that can happen :-) I've run it once or twice on linux machines,
and it comes out with huge changes compared to what Bruce gets on his
Brendan Jurd wrote:
The idea that we fix stylistic issues on the fly is not sustainable.
We should offer help and mentorship to new patch submitters in all
areas (including stylistic) but they should do the work. It is the only
way we will mold them to submit patches in the proper way.
Magnus Hagander wrote:
And I think adopting surrounding naming, commeting, coding conventions
should come naturally as it can aide in copy-pasting too :)
I think pg_indent has to be made a lot more portable and easy to use
before that can happen :-) I've run it once or twice on linux
[EMAIL PROTECTED] (Tom Lane) writes:
Magnus Hagander [EMAIL PROTECTED] writes:
I think pg_indent has to be made a lot more portable and easy to use
before that can happen :-) I've run it once or twice on linux machines,
and it comes out with huge changes compared to what Bruce gets on his
Chris Browne [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Tom Lane) writes:
Every so often there are discussions of going over to GNU indent
instead. Presumably that would solve the portability problem.
The last time we tried it (which was a long time ago) it seemed
to have too many bugs and
On Wed, 16 Apr 2008 12:36:50 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
If the patch submitters hasn't read the developers' FAQ, we assume
they are not interested in improving the style of their patch.
I think that point is fairly flawed in consideration. I know for a fact
that I
[EMAIL PROTECTED] (Bruce Momjian) writes:
Magnus Hagander wrote:
And I think adopting surrounding naming, commeting, coding conventions
should come naturally as it can aide in copy-pasting too :)
I think pg_indent has to be made a lot more portable and easy to use
before that can happen
Chris Browne wrote:
[EMAIL PROTECTED] (Bruce Momjian) writes:
Magnus Hagander wrote:
And I think adopting surrounding naming, commeting, coding conventions
should come naturally as it can aide in copy-pasting too :)
I think pg_indent has to be made a lot more portable and easy to use
Chris Browne wrote:
[EMAIL PROTECTED] (Tom Lane) writes:
Magnus Hagander [EMAIL PROTECTED] writes:
I think pg_indent has to be made a lot more portable and easy to use
before that can happen :-) I've run it once or twice on linux machines,
and it comes out with huge changes compared to
Bruce Momjian wrote:
Chris Browne wrote:
Would it be a terrible idea to...
- Draw the indent code from NetBSD into src/tools/pgindent
- Build it _in place_ inside the code tree (e.g. - don't assume
it will get installed in /usr/local/bin)
- Thus have the ability to run it in
[EMAIL PROTECTED] (Bruce Momjian) writes:
Chris Browne wrote:
[EMAIL PROTECTED] (Bruce Momjian) writes:
Magnus Hagander wrote:
And I think adopting surrounding naming, commeting, coding conventions
should come naturally as it can aide in copy-pasting too :)
I think pg_indent has to
Chris Browne wrote:
Would it be a terrible idea to...
- Draw the indent code from NetBSD into src/tools/pgindent
- Build it _in place_ inside the code tree (e.g. - don't assume
it will get installed in /usr/local/bin)
- Thus have the ability to run it in place?
Yes, but it
Chris Browne [EMAIL PROTECTED] writes:
Would it be a terrible idea to...
- Draw the indent code from NetBSD into src/tools/pgindent
I am not real eager to become maintainers of our own indent fork, which
is what you propose. (Just for starters, what will we have to do to
make it run on
Tom Lane wrote:
The main problem I see with pgindent early and often is that it only
works well if everyone is using exactly the same pgindent code (and
exactly the same typedef list). Otherwise you just get buried in
useless whitespace diffs.
It's bad enough that Bruce whacks around his
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
It's bad enough that Bruce whacks around his copy from time to time :-(.
I hate to say it but pgindent formatting changes are usually made in
cases where you or the community want pgindent to improve its indenting. :-)
So we improve
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I hate to say it but pgindent formatting changes are usually made in
cases where you or the community want pgindent to improve its indenting. :-)
So we improve pgindent but pay for it in backpatching difficulties. :-(
Yeah, I know
Alvaro Herrera wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I hate to say it but pgindent formatting changes are usually made in
cases where you or the community want pgindent to improve its indenting.
:-)
So we improve pgindent but pay for it in backpatching
Bruce Momjian wrote:
Alvaro Herrera wrote:
Maybe this means that we should give pgindent a run over the back
branches.
Yea, that thought has crossed our minds, but the problem is that there
is little testing of back branches so it would be risky.
That's a fair point, though I wonder how
[EMAIL PROTECTED] (Bruce Momjian) writes:
Chris Browne wrote:
Would it be a terrible idea to...
- Draw the indent code from NetBSD into src/tools/pgindent
- Build it _in place_ inside the code tree (e.g. - don't assume
it will get installed in /usr/local/bin)
- Thus have the
Alvaro Herrera [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
Alvaro Herrera wrote:
Maybe this means that we should give pgindent a run over the back
branches.
Yea, that thought has crossed our minds, but the problem is that there
is little testing of back branches so it would be risky.
Chris Browne wrote:
That is much a more radical use of pgindent than it has had in the past
but it is certainly possible.
Well, supposing you're cleaning up a patch after someone has generated
it in bad style, it would seem like rather less work to use pgindent
to impose style policy
Alvaro Herrera [EMAIL PROTECTED] writes:
I suggested to you awhile back that we could keep a typedef file on the
repository, saving one step.
That kind of sucks since it means you get conflicts when you update if you've
run it yourself.
Is there a reason we can't write makefiles which
Bruce Momjian [EMAIL PROTECTED] writes:
I am reviewing the psql wrap patch and just used pgindent today to clean
it up. (pgindent did not add any extra spacing changes.) Patch
reviewers should probably be able to run pgindent.
Well, that means nobody in the world can review except you,
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am reviewing the psql wrap patch and just used pgindent today to clean
it up. (pgindent did not add any extra spacing changes.) Patch
reviewers should probably be able to run pgindent.
Well, that means nobody in the world can
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am reviewing the psql wrap patch and just used pgindent today to clean
it up. (pgindent did not add any extra spacing changes.) Patch
reviewers should probably be able to run pgindent.
Well, that
On Mon, Apr 14, 2008 at 05:15:51PM -0400, Bruce Momjian wrote:
So when/how do those discussions get resolved?
[ shrug... ] You can't force ideas to happen on a schedule.
I need is to know if they are ideas worthy of TODO.
One thing I would like is if larger more complex patches where
* Tom Lane ([EMAIL PROTECTED]) wrote:
One problem with this fest was that a whole lot of the patches *weren't*
trivial; if they had been they'd not have gotten put off till 8.4. So
there weren't that many that I wanted to let go in without looking at
them. I guess that's just another way in
Martijn van Oosterhout napsal(a):
On Mon, Apr 14, 2008 at 05:15:51PM -0400, Bruce Momjian wrote:
So when/how do those discussions get resolved?
[ shrug... ] You can't force ideas to happen on a schedule.
I need is to know if they are ideas worthy of TODO.
One thing I would like is if
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
One problem with this fest was that a whole lot of the patches *weren't*
trivial; if they had been they'd not have gotten put off till 8.4. So
there weren't that many that I wanted to let go in without looking at
Gregory Stark [EMAIL PROTECTED] writes:
One thing I found is that I'm not sure what to do if I don't find any changes
to propose. I tend to assume that means I just don't understand the code well
enough and end up just not posting anything.
It's still worth adding an annotation to the wiki
Gregory Stark [EMAIL PROTECTED] writes:
I don't think we know what a typical review really looks like.
A general comment is that in stuff I review, I frequently spend a lot of
time trying to make the patch look like it belongs, that is make it
reasonably well-integrated with the surrounding
Tom Lane wrote:
A general comment is that in stuff I review, I frequently spend a lot of
time trying to make the patch look like it belongs, that is make it
reasonably well-integrated with the surrounding code. This is important
because a code base that too obviously consists of layers upon
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
A general comment is that in stuff I review, I frequently spend a lot of
time trying to make the patch look like it belongs, that is make it
reasonably well-integrated with the surrounding code. This is important
because a code base
Tom Lane wrote:
I tend to just fix this stuff while committing, rather than lecture the
submitters about it, but it undoubtedly is a time sink.
Lesson learned: a useful task for another reviewer to do is to grab the
patch, fix the style issues, and post the fixed version. That way, the
higher
On Tue, 15 Apr 2008 12:12:24 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
Tom Lane wrote:
I tend to just fix this stuff while committing, rather than lecture
the submitters about it, but it undoubtedly is a time sink.
Lesson learned: a useful task for another reviewer to do is to grab
There has been talk of the lessons we learned during this commit fest,
but exactly what lessons did we learn? I am not clear on that so I
assume others are not as well. What are we going to do differently
during the next commit fest?
--
Bruce Momjian [EMAIL PROTECTED]
1 - 100 of 128 matches
Mail list logo
