Alvaro Herrera wrote:
> Excerpts from Tom Lane's message of lun abr 25 20:48:42 -0300 2011:
> > Andrew Dunstan writes:
>
> > > Well, that way you'll have a handful of -Ttypdef parameters for each
> > > invocation of indent instead of a gazillion of them. No more command
> > > line length issues
On Wed, May 4, 2011 at 1:21 PM, Josh Berkus wrote:
>
>>> You can't indent patches, only patched files. And that's the problem
>>> with this happy scheme. For it to work at all sanely we'd need to keep
>>> the committed code that the patch is to be applied against strictly
>>> pgindent clean, presu
On Wed, May 4, 2011 at 19:21, Josh Berkus wrote:
>
>>> You can't indent patches, only patched files. And that's the problem
>>> with this happy scheme. For it to work at all sanely we'd need to keep
>>> the committed code that the patch is to be applied against strictly
>>> pgindent clean, presuma
>> You can't indent patches, only patched files. And that's the problem
>> with this happy scheme. For it to work at all sanely we'd need to keep
>> the committed code that the patch is to be applied against strictly
>> pgindent clean, presumably via some automated process such as a commit
>>
On Wed, May 4, 2011 at 12:19 AM, Tom Lane wrote:
> Mind you, I've read more than enough horribly-formatted patches to wish
> that we could do something about this. But I doubt that a mechanical
> reformatting pass before reviewing will be a net plus.
It wouldn't hurt to have the option.
It woul
On May 3, 2011, at 11:10 PM, Andrew Dunstan wrote:
> On 05/03/2011 09:53 PM, David Blewett wrote:
>> On Tue, May 3, 2011 at 9:51 PM, David Blewett wrote:
>>> This seems like a pretty good idea, but maybe it'd be easiest to take
>>> it a step further and add an "automatic pgindent-ified" patch is
>
Andrew Dunstan writes:
> On 05/03/2011 09:53 PM, David Blewett wrote:
>> On Tue, May 3, 2011 at 9:51 PM, David Blewett wrote:
>> That should read: ... but maybe it'd be easiest to take it a step
>> further and have an additional, automatically created patch file that
>> is run through pgindent wh
On 05/03/2011 09:53 PM, David Blewett wrote:
On Tue, May 3, 2011 at 9:51 PM, David Blewett wrote:
This seems like a pretty good idea, but maybe it'd be easiest to take
it a step further and add an "automatic pgindent-ified" patch is
created when a patch is added to the commitfest app?
That s
On Tue, May 3, 2011 at 9:51 PM, David Blewett wrote:
> This seems like a pretty good idea, but maybe it'd be easiest to take
> it a step further and add an "automatic pgindent-ified" patch is
> created when a patch is added to the commitfest app?
That should read: ... but maybe it'd be easiest to
On Mon, May 2, 2011 at 2:01 AM, Pavan Deolasee wrote:
> Can we not setup a automatic mechanism where a submitter can send a patch to
> some email id, the patch gets applied on the current HEAD, pgindent is run
> and the new patch is sent back to the submitter who can then submit it to
> the hacker
On Tue, Apr 26, 2011 at 2:25 AM, Andrew Dunstan wrote:
>
>
> On 04/25/2011 04:28 PM, Tom Lane wrote:
>
>> Andrew Dunstan writes:
>>
>>> On 04/25/2011 03:30 PM, Tom Lane wrote:
>>>
*Ouch*. Really? It's hard to believe that anyone would consider it
remotely usable for more than toy-siz
On Sun, May 1, 2011 at 1:14 PM, Kevin Grittner
wrote:
> Robert Treat wrote:
>> Tom Lane wrote:
>
>>> CF #1: June 1-30
>>> CF #2: August 1-31
>>> CF #3: October 1-31
>>> CF #4 (one week shortened CF): December 1-7
>>> CF #5: January 1-31
>>>
>>> I think the main
On May 1, 2011, at 9:34 PM, "Kevin Grittner"
wrote:
> Joshua Berkus wrote:
>
>> Generally the last week only has 1-3 patches open
>
> The last CF I managed the end of the third week looked like this:
>
> http://archives.postgresql.org/pgsql-hackers/2010-08/msg00334.php
>
> That is, we had 15
Joshua Berkus wrote:
> Generally the last week only has 1-3 patches open
The last CF I managed the end of the third week looked like this:
http://archives.postgresql.org/pgsql-hackers/2010-08/msg00334.php
That is, we had 15 patches still pending out of 72 submitted:
9 ready for committer
> I think the main thing we have to think about before choosing is
> whether
> we believe that we can shorten the CFs at all. Josh's proposal had
> 3-week CFs after the first one, which makes it a lot easier to have a
> fest in November or December, but only if you really can end it on
> time.
I
On Sat, Apr 30, 2011 at 5:33 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Joshua Berkus wrote:
>>> I just searched backwards on this thread and I can't find it.
>
>> I think he's talking about the bottom of this post:
>> http://archives.postgresql.org/message-id/BANLkTimnjZNemdpqgK=8Mj=pzq3
Robert Treat wrote:
> Tom Lane wrote:
>>CF #1: June 1-30
>>CF #2: August 1-31
>>CF #3: October 1-31
>>CF #4 (one week shortened CF): December 1-7
>>CF #5: January 1-31
>>
>> I think the main thing we have to think about before choosing is
>> whether we be
"Kevin Grittner" writes:
> Joshua Berkus wrote:
>> I just searched backwards on this thread and I can't find it.
> I think he's talking about the bottom of this post:
> http://archives.postgresql.org/message-id/BANLkTimnjZNemdpqgK=8Mj=pzq33pz0...@mail.gmail.com
... which was:
CF #1: J
Joshua Berkus wrote:
> I just searched backwards on this thread and I can't find it.
I think he's talking about the bottom of this post:
http://archives.postgresql.org/message-id/BANLkTimnjZNemdpqgK=8Mj=pzq33pz0...@mail.gmail.com
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hacke
> > If CF1 is June1, though, when will CF4 be? Having a CF start Dec. 1
> > is probably a bad idea.
>
> Well, I made a suggestion on this topic in my previous email on the
> subject...
I just searched backwards on this thread and I can't find it. There's been a
lot of posts.
--
Josh Berkus
P
On Apr 30, 2011, at 9:23 PM, Joshua Berkus wrote:
> Robert,
>
>> Tom and I were talking about starting maybe June 1, rather than July
>> 1. You seem opposed but I'm not sure why.
>
> Because I think -- strictly based on history and the complexity of the new
> features -- we'll still be fixing m
Robert,
> Tom and I were talking about starting maybe June 1, rather than July
> 1. You seem opposed but I'm not sure why.
Because I think -- strictly based on history and the complexity of the new
features -- we'll still be fixing major issues with the beta in June, which was
what Tom said as
On Apr 29, 2011, at 5:19 PM, Joshua Berkus wrote:
> Beyond that, are we ready to set the schedule for 9.2 yet? I'd tend to say
> that:
>
> CF1: July 1-30
> CF2: Sept 1-21
> CF3: November 1-21
> CF4: January 3-31
Tom and I were talking about starting maybe June 1, rather than July 1. You
seem
All,
> +1 from me for keeping it as-is as well.
So it sounds like most committers want to keep the CFs on their existing
schedule for another year. Also that we don't want to branch until RC1. While
it would be nice to get some feedback from those who had bad experiences with
the CF cycle,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> What it would mostly
> do is decouple the development community entirely from release
> stabilization work, and I think that would be a seriously bad idea.
+1000%, seriously. This is a huge concern that we need to make sure is
addressed in a sensible way.
Josh Berkus writes:
>> Huh? We've never guaranteed anyone a regular annual cycle, and we've
>> never had one. We agreed to use the same schedule for 9.1 as for 9.0;
>> I don't remember anything more than that being discussed anywhere,
>> ever.
> We *want* to have a regular annual cycle which do
> Huh? We've never guaranteed anyone a regular annual cycle, and we've
> never had one. We agreed to use the same schedule for 9.1 as for 9.0;
> I don't remember anything more than that being discussed anywhere,
> ever.
We *want* to have a regular annual cycle which doesn't vary by more than
a
On Mon, Apr 25, 2011 at 3:19 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On balance, I think I prefer the
>> current arrangement, though if we could make the CommitFests a bit
>> shorter I would certainly like that better. I don't know how to make
>> that happen wit
On Mon, Apr 25, 2011 at 2:17 PM, Robert Haas wrote:
> if we
> make CommitFests more frequent and shorter, we can give people
> feedback more quickly
"We" can give people feedback more quickly. There is no "we" in that regard.
Some individuals may be in a position to give more frequent feedback,
On Mon, Apr 25, 2011 at 4:03 PM, Greg Stark wrote:
> On Mon, Apr 25, 2011 at 3:45 PM, Tom Lane wrote:
>> One small issue that would have to be resolved before branching is
>> whether and when to do a "final" pgindent run for 9.1. Seems like the
>> alternatives would be:
>>
>
> If the tools becom
Greg Stark writes:
> On Tue, Apr 26, 2011 at 2:07 AM, Andrew Dunstan wrote:
>> Oh, it just occurred to me that maybe you thought the whole thing
>> *including* indent would be reimplemented in perl. That was never my
>> intention, and is a much larger project than I had in mind.
> Oh, I thought
Excerpts from Tom Lane's message of lun abr 25 20:48:42 -0300 2011:
> Andrew Dunstan writes:
> > Well, that way you'll have a handful of -Ttypdef parameters for each
> > invocation of indent instead of a gazillion of them. No more command
> > line length issues.
>
> Well, -Ttypedef is wrong on
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Sounds good to me ... who's volunteering?
(Andrew) I will as well. Github perhaps, Andrew? I'll be happy to get
some unit tests written.
- --
Greg Sabino Mullane g...@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x1
On Tue, Apr 26, 2011 at 2:07 AM, Andrew Dunstan wrote:
> Oh, it just occurred to me that maybe you thought the whole thing
> *including* indent would be reimplemented in perl. That was never my
> intention, and is a much larger project than I had in mind.
Oh, I thought that was what you were prop
On 04/25/2011 09:02 PM, Andrew Dunstan wrote:
The current script calls our (patched) BSD indent. Any rewrite would
have to also. It (the BSD indent) doesn't have any facility to pass a
typedef file parameter. If you want that we have to patch the C code.
No amount of rewriting in Perl or a
On 04/25/2011 08:54 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 04/25/2011 07:48 PM, Tom Lane wrote:
Well, -Ttypedef is wrong on its face. Right would be a switch
specifying the name of the file to read the typedef list from.
Then you don't need massive script-level infrastructure to try
Andrew Dunstan writes:
> On 04/25/2011 07:48 PM, Tom Lane wrote:
>> Well, -Ttypedef is wrong on its face. Right would be a switch
>> specifying the name of the file to read the typedef list from.
>> Then you don't need massive script-level infrastructure to try
>> to spoonfeed that data to the pr
On 04/25/2011 07:48 PM, Tom Lane wrote:
Well, that way you'll have a handful of -Ttypdef parameters for each
invocation of indent instead of a gazillion of them. No more command
line length issues.
Well, -Ttypedef is wrong on its face. Right would be a switch
specifying the name of the file
Andrew Dunstan writes:
> On 04/25/2011 07:00 PM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> and filter the typedefs list so that we only use the ones
>>> that appear in each file with that file, instead of passing the whole
>>> list to each file.
>> Not sure I gather the value of doing that.
On 04/25/2011 07:00 PM, Tom Lane wrote:
Andrew Dunstan writes:
Well, my solution would be to replace pgindent with a perl script (among
other advantages, it would then run everywhere we build, including
Windows),
Sounds good to me ... who's volunteering?
I'll take a look.
and filter the t
Andrew Dunstan writes:
> Well, my solution would be to replace pgindent with a perl script (among
> other advantages, it would then run everywhere we build, including
> Windows),
Sounds good to me ... who's volunteering?
> and filter the typedefs list so that we only use the ones
> that appea
On 04/25/2011 01:55 PM, Andrew Dunstan wrote:
Well, my solution would be to replace pgindent with a perl script
(among other advantages, it would then run everywhere we build,
including Windows), and filter the typedefs list so that we only use
the ones that appear in each file with that f
On 04/25/2011 04:28 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 04/25/2011 03:30 PM, Tom Lane wrote:
*Ouch*. Really? It's hard to believe that anyone would consider it
remotely usable for more than toy-sized projects, if you have to list
all the typedef names on the command line.
Looks
On Mon, Apr 25, 2011 at 4:29 PM, Steve Singer wrote:
> On 11-04-25 03:40 PM, Robert Haas wrote:
>>
>> At the risk of getting a bit cranky, you haven't participated in a
>> material way in any CommitFest we've had in well over a year. AFAICS,
>> the first, last, and only time you are listed in the
On 11-04-25 03:40 PM, Robert Haas wrote:
At the risk of getting a bit cranky, you haven't participated in a
material way in any CommitFest we've had in well over a year. AFAICS,
the first, last, and only time you are listed in the CommitFest
application is as co-reviewer of a patch in July 2009,
On Apr 25, 2011, at 3:28 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 04/25/2011 03:30 PM, Tom Lane wrote:
>>> *Ouch*. Really? It's hard to believe that anyone would consider it
>>> remotely usable for more than toy-sized projects, if you have to list
>>> all the typedef names on the com
Andrew Dunstan writes:
> On 04/25/2011 03:30 PM, Tom Lane wrote:
>> *Ouch*. Really? It's hard to believe that anyone would consider it
>> remotely usable for more than toy-sized projects, if you have to list
>> all the typedef names on the command line.
> Looks like BSD does the same. It's just
On Mon, Apr 25, 2011 at 3:47 PM, Joshua D. Drake wrote:
> On 04/25/2011 12:40 PM, Robert Haas wrote:
>> At the risk of getting a bit cranky, you haven't participated in a
>> material way in any CommitFest we've had in well over a year. AFAICS,
>> the first, last, and only time you are listed in t
On 04/25/2011 12:40 PM, Robert Haas wrote:
At the risk of getting a bit cranky, you haven't participated in a
material way in any CommitFest we've had in well over a year. AFAICS,
the first, last, and only time you are listed in the CommitFest
application is as co-reviewer of a patch in July 20
On 04/25/2011 02:26 PM, Josh Berkus wrote:
Overall, I think the advantages to a faster/shorter CF cycle outweigh
the disadvantages enough to make it at least worth trying. I'm willing
to run the first 1-week CF, as well as several of the others during the
9.2 cycle to try and make it work.
On Mon, Apr 25, 2011 at 2:26 PM, Josh Berkus wrote:
> I thought the idea of setting the initial CF for July 15th for 9.1 was
> that we would consistently have the first CF in July every year? As
> discussed at that time, there's value to our corporate-sponsored
> developers in knowing a regular a
On 04/25/2011 03:30 PM, Tom Lane wrote:
Greg Stark writes:
Fwiw I tried getting Gnu indent to work. I'm having a devil of a time
figuring out how to get even remotely similar output.
...
And it doesn't take a file for the list of typedefs. You have to
provide each one as an argment on the com
Greg Stark writes:
> Fwiw I tried getting Gnu indent to work. I'm having a devil of a time
> figuring out how to get even remotely similar output.
> ...
> And it doesn't take a file for the list of typedefs. You have to
> provide each one as an argment on the command-line.
*Ouch*. Really? It's
Josh Berkus writes:
> As much as I'd like to start development early officially, I'm with Tom
> in being pessimistic about the bugs we're going to find in SSI,
> Collations and Synch Rep. Frankly, if you and Tom weren't so focused on
> fixing it, I'd be suggesting that we pull Collations from 9.1
On Mon, Apr 25, 2011 at 4:17 PM, Tom Lane wrote:
> No, not at all, because you're ignoring the common case of a series of
> dependent patches that are submitted in advance of the first one having
> been committed.
Uh, true.
> To get to the point where we could do things that way, it would have
All,
> �I'm not aware that we've set
>>> any dates for 9.2 CommitFests yet ...
I thought the idea of setting the initial CF for July 15th for 9.1 was
that we would consistently have the first CF in July every year? As
discussed at that time, there's value to our corporate-sponsored
developers in
On mån, 2011-04-25 at 09:17 -0400, Robert Haas wrote:
> it'll be harder to organize reviewers (see esp. the note
> by Greg Smith in that regard),
As far as I'm concerned, those who run the commit fests will have to
work out how to best configure the commit fests. I have no strong
feelings about m
On 04/25/2011 01:12 PM, David Blewett wrote:
On Mon, Apr 25, 2011 at 1:04 PM, Tom Lane wrote:
"Kevin Grittner" writes:
Aidan Van Dyk wrote:
Of course, that all depends on:
1) pgindent being "work everywhere", "exactly the same"
2) Discipline of all new published commits being "pgindent cl
On Mon, Apr 25, 2011 at 1:04 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Aidan Van Dyk wrote:
>>> Of course, that all depends on:
>>> 1) pgindent being "work everywhere", "exactly the same"
>>> 2) Discipline of all new published commits being "pgindent clean".
>
>> The problem is that gett
"Kevin Grittner" writes:
> Aidan Van Dyk wrote:
>> Of course, that all depends on:
>> 1) pgindent being "work everywhere", "exactly the same"
>> 2) Discipline of all new published commits being "pgindent clean".
> The problem is that getting it set up isn't yet trivial. This is
> all assuming
On Mon, Apr 25, 2011 at 12:03 PM, Tom Lane wrote:
> You're ignoring the extremely real costs involved in an early branch,
> namely having to double-patch every bug fix we make during beta.
> (And no, my experiences with git cherry-pick are not so pleasant as
> to make me feel that that's a non-pro
Aidan Van Dyk wrote:
> 2) Discipline of all new published commits being "pgindent clean".
Heck, I think it would be reasonable to require that patch
submitters run it before creating their patches. If people merged
in changes from the main repository and then ran pgindent, I don't
think there
Robert Haas writes:
> On Mon, Apr 25, 2011 at 10:45 AM, Tom Lane wrote:
>> But a much more significant issue is that I don't see a lot of point in
>> branching until we are actually ready to start active 9.2 development.
>> So unless you see this as a vehicle whereby committers get to start
>> ha
On Mon, Apr 25, 2011 at 11:32 AM, Christopher Browne wrote:
> Methinks there'd need to be an experiment run where pgindent is run
> each time on some sort of "parallel tree" for a little while, to let
> people get some feel for what changes it introduces.
The point is that if the tools worked "e
On Mon, Apr 25, 2011 at 10:45 AM, Tom Lane wrote:
> One small issue that would have to be resolved before branching is
> whether and when to do a "final" pgindent run for 9.1. Seems like the
> alternatives would be:
> 1. Don't do anything more, be happy with the one run done already.
>
On Mon, Apr 25, 2011 at 11:03 AM, Greg Stark wrote:
> If the tools become easy to run is it possible we cold get to the
> point where we do an indent run on every commit? This wold require a
> stable list of system symbols plus the tool would need to add any new
> symbols added by the patch.
Meth
Greg Stark writes:
> If the tools become easy to run is it possible we cold get to the
> point where we do an indent run on every commit? This wold require a
> stable list of system symbols plus the tool would need to add any new
> symbols added by the patch. As long as the tool produced consisten
On Mon, Apr 25, 2011 at 3:45 PM, Tom Lane wrote:
> One small issue that would have to be resolved before branching is
> whether and when to do a "final" pgindent run for 9.1. Seems like the
> alternatives would be:
>
If the tools become easy to run is it possible we cold get to the
point where w
Robert Haas writes:
> The recent and wide-ranging "formatting curmudgeons" thread included
> suggestions by Tom and myself that we should consider branching the
> tree immediately after beta1.
> http://archives.postgresql.org/pgsql-hackers/2011-04/msg01157.php
> http://archives.postgresql.org/pgsq
Robert Haas wrote:
> The recent and wide-ranging "formatting curmudgeons" thread
> included suggestions by Tom and myself that we should consider
> branching the tree immediately after beta1.
My take is that it should be branched as soon as a committer would
find it useful to commit something
* Robert Haas (robertmh...@gmail.com) wrote:
> On balance, I think I prefer the
> current arrangement, though if we could make the CommitFests a bit
> shorter I would certainly like that better. I don't know how to make
> that happen without more reviewers, though.
Given our current method (where
On 04/25/2011 09:17 AM, Robert Haas wrote:
The recent and wide-ranging "formatting curmudgeons" thread included
suggestions by Tom and myself that we should consider branching the
tree immediately after beta1.
http://archives.postgresql.org/pgsql-hackers/2011-04/msg01157.php
http://archives.po
The recent and wide-ranging "formatting curmudgeons" thread included
suggestions by Tom and myself that we should consider branching the
tree immediately after beta1.
http://archives.postgresql.org/pgsql-hackers/2011-04/msg01157.php
http://archives.postgresql.org/pgsql-hackers/2011-04/msg01162.php
73 matches
Mail list logo
