Thread: Feature freeze and the great elog changeover

Feature freeze and the great elog changeover

From
Tom Lane
Date:
I had originally planned to spend the next week editing all the elog()
calls in the backend to convert them to ereport() format where helpful,
add SQLSTATE values, and update wording to match the style guidelines
that were agreed to awhile back.

However, it looks like the same reasons that were holding me back still
apply: any wholesale editing will likely break unapplied patches, plus
I'll have to go back through the code when those patches do get applied.
With folk scrambling to get last-minute stuff done before feature
freeze, these are not good side-effects.

What I'd like to do instead is try to get the editing done during the
interval between feature freeze and the start of beta (which we've
already agreed is July 1 - July 15).  I do not feel that this violates
the spirit of "feature freeze", but does anyone want to object to that
plan?
        regards, tom lane


Re: Feature freeze and the great elog changeover

From
Bruce Momjian
Date:
Good idea.  This is similar to the pgindent run, though that usually
happens just _before_ beta.

---------------------------------------------------------------------------

Tom Lane wrote:
> I had originally planned to spend the next week editing all the elog()
> calls in the backend to convert them to ereport() format where helpful,
> add SQLSTATE values, and update wording to match the style guidelines
> that were agreed to awhile back.
> 
> However, it looks like the same reasons that were holding me back still
> apply: any wholesale editing will likely break unapplied patches, plus
> I'll have to go back through the code when those patches do get applied.
> With folk scrambling to get last-minute stuff done before feature
> freeze, these are not good side-effects.
> 
> What I'd like to do instead is try to get the editing done during the
> interval between feature freeze and the start of beta (which we've
> already agreed is July 1 - July 15).  I do not feel that this violates
> the spirit of "feature freeze", but does anyone want to object to that
> plan?
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: Feature freeze and the great elog changeover

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Good idea.  This is similar to the pgindent run, though that usually
> happens just _before_ beta.

Right.  It still should; I'd recommend we do that after I finish the
error message edits.

I think at least one person had volunteered to help with the editing;
that might be a good thing if they're still willing.  There's something
upwards of 4000 elog calls to be looked at :-(
        regards, tom lane


Re: Feature freeze and the great elog changeover

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Good idea.  This is similar to the pgindent run, though that usually
> > happens just _before_ beta.
> 
> Right.  It still should; I'd recommend we do that after I finish the
> error message edits.
> 
> I think at least one person had volunteered to help with the editing;
> that might be a good thing if they're still willing.  There's something
> upwards of 4000 elog calls to be looked at :-(

Do we get error numbers with that?  :-)

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: Feature freeze and the great elog changeover

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> I think at least one person had volunteered to help with the editing;
>> that might be a good thing if they're still willing.  There's something
>> upwards of 4000 elog calls to be looked at :-(

> Do we get error numbers with that?  :-)

That is the point ... I'd not really be bothering otherwise ...
        regards, tom lane


Re: Feature freeze and the great elog changeover

From
Paul Ramsey
Date:
Lots of hardcoded english... is i8n something which gets raised often, 
or is it lingue franca enough that people don't care? (Since all the 
messages are going to be looked at anyways...)

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> 
>>>I think at least one person had volunteered to help with the editing;
>>>that might be a good thing if they're still willing.  There's something
>>>upwards of 4000 elog calls to be looked at :-(
> 
> 
>>Do we get error numbers with that?  :-)
> 
> 
> That is the point ... I'd not really be bothering otherwise ...

--       __     /     | Paul Ramsey     | Refractions Research     | Email: pramsey@refractions.net     | Phone: (250)
885-0632    \_
 



Re: Feature freeze and the great elog changeover

From
Tom Lane
Date:
Paul Ramsey <pramsey@refractions.net> writes:
> Lots of hardcoded english...

What makes you think it's hardcoded?  We've had internationalization
support for awhile.  (One of the results I'd like to accomplish in this
pass is to reduce the number of "junk" messages that translators need to
look at, by merging near-duplicates and suppressing .po entries for
internal-can't-happen errors.)
        regards, tom lane


Re: Feature freeze and the great elog changeover

From
Paul Ramsey
Date:
Tom Lane wrote:
> Paul Ramsey <pramsey@refractions.net> writes:
> 
>>Lots of hardcoded english...
> 
> 
> What makes you think it's hardcoded?  We've had internationalization
> support for awhile.  (One of the results I'd like to accomplish in this
> pass is to reduce the number of "junk" messages that translators need to
> look at, by merging near-duplicates and suppressing .po entries for
> internal-can't-happen errors.)

Ignorance on my part, probably. You mentioned elog() so I grepped for it 
and found lots of this stuff:

elog(FATAL, "data directory %s was not found", checkdir)
elog(FATAL, "could not read permissions of directory %s: %m",               checkdir);

I am probably just misunderstanding something.

P.

--       __     /     | Paul Ramsey     | Refractions Research     | Email: pramsey@refractions.net     | Phone: (250)
885-0632    \_
 



Re: Feature freeze and the great elog changeover

From
Tom Lane
Date:
Paul Ramsey <pramsey@refractions.net> writes:
> I am probably just misunderstanding something.

See http://candle.pha.pa.us/main/writings/pgsql/sgml/nls.html
        regards, tom lane


Re: Feature freeze and the great elog changeover

From
Dennis Björklund
Date:
On Wed, 25 Jun 2003, Paul Ramsey wrote:

> Ignorance on my part, probably. You mentioned elog() so I grepped for it 
> and found lots of this stuff:
> 
> elog(FATAL, "data directory %s was not found", checkdir)
> elog(FATAL, "could not read permissions of directory %s: %m", 
>                checkdir);
> 
> I am probably just misunderstanding something.

It's taken care of by the gettext system.

One thing that I would like to see in the future (but probably wont for
many years still) is a log file that is saved in a format like

"data directory %s was not found", "/usr/"

where you can view the log with some (gui och command-line) tool that
translates it when you look at it. Then anyone can look at the log using
their language and you don't have to decide one one language when you 
start the server.

Maybe something for postgresql X.

-- 
/Dennis



Re: Feature freeze and the great elog changeover

From
The Hermit Hacker
Date:
On Wed, 25 Jun 2003, Tom Lane wrote:

> I had originally planned to spend the next week editing all the elog()
> calls in the backend to convert them to ereport() format where helpful,
> add SQLSTATE values, and update wording to match the style guidelines
> that were agreed to awhile back.
>
> However, it looks like the same reasons that were holding me back still
> apply: any wholesale editing will likely break unapplied patches, plus
> I'll have to go back through the code when those patches do get applied.
> With folk scrambling to get last-minute stuff done before feature
> freeze, these are not good side-effects.
>
> What I'd like to do instead is try to get the editing done during the
> interval between feature freeze and the start of beta (which we've
> already agreed is July 1 - July 15).  I do not feel that this violates
> the spirit of "feature freeze", but does anyone want to object to that
> plan?

Based on the reasons given, it sounds like it would be more harmful not to
do it when things are supposed to be frozen ... no objections here ...