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
w
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.
-
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 pgind
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 s
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 (pgsql-hackers@postgres
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 i
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
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 thinki
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.
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 "
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
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 n
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
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
exam
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
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
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:
> And here are the 7625 from MinGW.
>
> http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=dawn_bat&dt=2008-04-19%20004514&stg=typedefs
>
> It looks like we'll need some sort of extra filter.
Hmm. Wow. For example I see
FINDREPLACE
FINDREPLACEA
FINDREPLACEW
We use
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
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 typede
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 heade
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:
> 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 ca
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_typede
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 i
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 coul
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 m
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
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 symbo
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 li
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 go
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
"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_##
* 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.
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 typede
* 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*
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.
"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 eve
[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 starte
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 Win
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 li
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 on
"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
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 havin
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 unaccepta
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 Rep
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
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
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 i
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?
> >
> >
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
> >
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 s
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 ad
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
> > > > > chang
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 si
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 (pgsql-hackers@postgresql.or
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
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
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,
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.
> >
>
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 wo
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, b
"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 ge
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 poli
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 wo
[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)
>>
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 won
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 i
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. :-(
>
> Ye
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 impr
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 aroun
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 n
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?
> >
[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
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 ru
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
[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
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 c
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
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 man
[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
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
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 pr
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
>
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 wit
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 patch
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.
> >
>
>
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 problems
-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 i
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
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
"high
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
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
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 surroundin
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
"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 lo
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 larger
* 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
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 patche
On Mon, 14 Apr 2008 21:25:28 -0400
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> The problem is that the patch was initially trivial, but it turned
> into a much larger redesign of command handling. I think that's a
> great turnout for a submission.
>
> > Don't forget to update developer FAQ as we
1 - 100 of 128 matches
Mail list logo
