Alvaro Herrera wrote:
Excerpts from Tom Lane's message of lun abr 25 20:48:42 -0300 2011:
Andrew Dunstan and...@dunslane.net 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
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 Blewettda...@dawninglight.net wrote:
This seems like a pretty good idea, but maybe it'd be easiest to take
it a step further and add an automatic
On Wed, May 4, 2011 at 12:19 AM, Tom Lane t...@sss.pgh.pa.us 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
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
hook.
On Wed, May 4, 2011 at 19:21, Josh Berkus j...@agliodbs.com 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,
On Wed, May 4, 2011 at 1:21 PM, Josh Berkus j...@agliodbs.com 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,
On Mon, May 2, 2011 at 2:01 AM, Pavan Deolasee pavan.deola...@gmail.com 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
On Tue, May 3, 2011 at 9:51 PM, David Blewett da...@dawninglight.net 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
On 05/03/2011 09:53 PM, David Blewett wrote:
On Tue, May 3, 2011 at 9:51 PM, David Blewettda...@dawninglight.net 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
Andrew Dunstan and...@dunslane.net writes:
On 05/03/2011 09:53 PM, David Blewett wrote:
On Tue, May 3, 2011 at 9:51 PM, David Blewettda...@dawninglight.net wrote:
That should read: ... but maybe it'd be easiest to take it a step
further and have an additional, automatically created patch file
On Tue, Apr 26, 2011 at 2:25 AM, Andrew Dunstan and...@dunslane.net wrote:
On 04/25/2011 04:28 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net 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
Robert Treat r...@xzilla.net wrote:
Tom Lane t...@sss.pgh.pa.us 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
On Sat, Apr 30, 2011 at 5:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Joshua Berkus j...@agliodbs.com 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:
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
Joshua Berkus j...@agliodbs.com 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
On May 1, 2011, at 9:34 PM, Kevin Grittner kevin.gritt...@wicourts.gov
wrote:
Joshua Berkus j...@agliodbs.com 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:
On Sun, May 1, 2011 at 1:14 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Treat r...@xzilla.net wrote:
Tom Lane t...@sss.pgh.pa.us 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
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 30, 2011, at 9:23 PM, Joshua Berkus j...@agliodbs.com 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
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
Joshua Berkus j...@agliodbs.com 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
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Joshua Berkus j...@agliodbs.com 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:
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,
On Apr 29, 2011, at 5:19 PM, Joshua Berkus j...@agliodbs.com 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.
On Mon, Apr 25, 2011 at 4:03 PM, Greg Stark gsst...@mit.edu wrote:
On Mon, Apr 25, 2011 at 3:45 PM, Tom Lane t...@sss.pgh.pa.us 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:
On Mon, Apr 25, 2011 at 2:17 PM, Robert Haas robertmh...@gmail.com 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
On Mon, Apr 25, 2011 at 3:19 PM, Stephen Frost sfr...@snowman.net 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
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 few
Josh Berkus j...@agliodbs.com 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
* 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.
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
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
* 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 we
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
On Mon, Apr 25, 2011 at 3:45 PM, Tom Lane t...@sss.pgh.pa.us 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
Greg Stark gsst...@mit.edu 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
On Mon, Apr 25, 2011 at 11:03 AM, Greg Stark gsst...@mit.edu 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
On Mon, Apr 25, 2011 at 10:45 AM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Apr 25, 2011 at 11:32 AM, Christopher Browne cbbro...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Mon, Apr 25, 2011 at 10:45 AM, Tom Lane t...@sss.pgh.pa.us 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
Aidan Van Dyk ai...@highrise.ca 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
On Mon, Apr 25, 2011 at 12:03 PM, Tom Lane t...@sss.pgh.pa.us 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
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Aidan Van Dyk ai...@highrise.ca 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
On Mon, Apr 25, 2011 at 1:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Aidan Van Dyk ai...@highrise.ca wrote:
Of course, that all depends on:
1) pgindent being work everywhere, exactly the same
2) Discipline of all new published commits being
On 04/25/2011 01:12 PM, David Blewett wrote:
On Mon, Apr 25, 2011 at 1:04 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Kevin Grittnerkevin.gritt...@wicourts.gov writes:
Aidan Van Dykai...@highrise.ca wrote:
Of course, that all depends on:
1) pgindent being work everywhere, exactly the same
2)
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 my
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 Mon, Apr 25, 2011 at 4:17 PM, Tom Lane t...@sss.pgh.pa.us 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,
Josh Berkus j...@agliodbs.com 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
Greg Stark gsst...@mit.edu 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*.
On 04/25/2011 03:30 PM, Tom Lane wrote:
Greg Starkgsst...@mit.edu 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
On Mon, Apr 25, 2011 at 2:26 PM, Josh Berkus j...@agliodbs.com 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
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 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
On Mon, Apr 25, 2011 at 3:47 PM, Joshua D. Drake j...@commandprompt.com 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
Andrew Dunstan and...@dunslane.net 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
On Apr 25, 2011, at 3:28 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
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
On Mon, Apr 25, 2011 at 4:29 PM, Steve Singer ssinger...@sympatico.ca 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
On 04/25/2011 04:28 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net 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
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
Andrew Dunstan and...@dunslane.net 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
On 04/25/2011 07:00 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net 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
Andrew Dunstan and...@dunslane.net writes:
On 04/25/2011 07:00 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net 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
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
Andrew Dunstan and...@dunslane.net 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
On 04/25/2011 08:54 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net 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
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
On Tue, Apr 26, 2011 at 2:07 AM, Andrew Dunstan and...@dunslane.net 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
-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:
Excerpts from Tom Lane's message of lun abr 25 20:48:42 -0300 2011:
Andrew Dunstan and...@dunslane.net 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
Greg Stark gsst...@mit.edu writes:
On Tue, Apr 26, 2011 at 2:07 AM, Andrew Dunstan and...@dunslane.net 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
73 matches
Mail list logo
