Commitfest problems
I have heard repeated concerns about the commitfest process in the past
few months. The fact we have been in a continual commitfest since
August also is concerning.
I think we are reaching the limits on how much we can do with our
existing commitfest structure, and it might be time to consider changes.
While the commitfest process hasn't changed much and was very successful
in the first few years, a few things have changed externally:
1 more new developers involved in contributing small patches
2 more full-time developers creating big patches
3 increased time demands on experienced Postgres developers
These changes are all driven by increased Postgres popularity. In an
ideal world, as 1 and 2 increase, the time experienced developers have
to work on commitfest items would also increase, but the opposite has
happened. Many of our most experienced developers (3) hold responsible
positions in their organizations which demand their time.
You would think that more full-time developers (2) would help with the
commitfest, but often their paid work is in a specific subsystem of
Postgres, preventing them from effectively helping with other complex
patches.
We have always known that we can create novice developers faster than
experienced ones, but it seems this difference is accelerating.
A good example is the UPSERT patch, which, while receiving extensive
feedback on the user interface and syntax, has not had a full review,
though it has been posted for several months.
It seems like a good time to consider options for restructuring our
process.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/10/2014 10:35 PM, Bruce Momjian wrote:
I have heard repeated concerns about the commitfest process in the past
few months. The fact we have been in a continual commitfest since
August also is concerning.I think we are reaching the limits on how much we can do with our
existing commitfest structure, and it might be time to consider changes.
While the commitfest process hasn't changed much and was very successful
in the first few years, a few things have changed externally:1 more new developers involved in contributing small patches
2 more full-time developers creating big patches
3 increased time demands on experienced Postgres developers
I will add:
4. commitfest managers have burned out and refuse to do it again
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Reply to msg id not found: WMa530bfe0b890d30b067c36d9a565d32e9df03b40ad07086dd8bf1d8f0dafb6e642e0d8a3cab47dafc09364f8dc6cafb2@asav-2.01.com
On Wed, Dec 10, 2014 at 11:00:21PM -0800, Josh Berkus wrote:
On 12/10/2014 10:35 PM, Bruce Momjian wrote:
I think we are reaching the limits on how much we can do with our
existing commitfest structure, and it might be time to consider changes.
While the commitfest process hasn't changed much and was very successful
in the first few years, a few things have changed externally:1 more new developers involved in contributing small patches
2 more full-time developers creating big patches
3 increased time demands on experienced Postgres developersI will add:
4. commitfest managers have burned out and refuse to do it again
Agreed. The "fun", if it was ever there, has left the commitfest
process.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/11/14 1:35 AM, Bruce Momjian wrote:
While the commitfest process hasn't changed much and was very successful
in the first few years, a few things have changed externally:1 more new developers involved in contributing small patches
2 more full-time developers creating big patches
3 increased time demands on experienced Postgres developers
The number of patches registered in the commit fests hasn't actually
changed over the years. It has always fluctuated between 50 and 100,
depending on the point of the release cycle. So I don't think (1) is
necessarily the problem.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
On 12/11/14 1:35 AM, Bruce Momjian wrote:
While the commitfest process hasn't changed much and was very successful
in the first few years, a few things have changed externally:1 more new developers involved in contributing small patches
2 more full-time developers creating big patches
3 increased time demands on experienced Postgres developers
The number of patches registered in the commit fests hasn't actually
changed over the years. It has always fluctuated between 50 and 100,
depending on the point of the release cycle. So I don't think (1) is
necessarily the problem.
Interesting point, but of course not all patches are equal; perhaps
the problem is that we're seeing fewer of (1) and more of (2) in the
commitfest queue. Is there any easy way to quantify the size/complexity
of the patches in past fests?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/11/2014 09:02 AM, Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
On 12/11/14 1:35 AM, Bruce Momjian wrote:
While the commitfest process hasn't changed much and was very successful
in the first few years, a few things have changed externally:1 more new developers involved in contributing small patches
2 more full-time developers creating big patches
3 increased time demands on experienced Postgres developersThe number of patches registered in the commit fests hasn't actually
changed over the years. It has always fluctuated between 50 and 100,
depending on the point of the release cycle. So I don't think (1) is
necessarily the problem.
I don't think that's accurate. The number of patches per CF *has* edged
upwards by 10-30% per CF over the years:
http://www.databasesoup.com/2013/08/94-commitfest-1-wrap-up.html
(I haven't done the rest of 9.4 yet or 9.5)
No, it's not a jump up by 2X, but it is an upwards trend. And I think
that Tom has it right that the additional patches we're seeing are
additional large, complex patches.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Reply to msg id not found: WM6d3ed523eb6454bb20eca7fed8681dedff888d171e776921a88b0a5a7baf57336a715a79b6737329311a423c5b534f0d@asav-2.01.com
On Thu, Dec 11, 2014 at 1:26 PM, Josh Berkus <josh@agliodbs.com> wrote:
No, it's not a jump up by 2X, but it is an upwards trend. And I think
that Tom has it right that the additional patches we're seeing are
additional large, complex patches.
I feel like there's increasingly not that much easy stuff left to do.
Many of the problems we haven't solved yet are unsolved because they
are really hard, or because not that important, or both. For example,
if you look at the current CommitFest, there are things like:
Add ssl_protocols configuration option
alter user/role CURRENT_USER
Fix local_preload_libraries to work as expected.
Refactoring code for synchronous node detection
Refactor of functions related to quoting from builtins.h to utils/quote.h
Those things are all, obviously, important to somebody, or there
wouldn't be patches for them in need of review. But in the broader
scheme of things, they are very minor issues. And then you have
things like:
deparse DDL in event triggers
Compression of Full Page Writes
WIP: dynahash replacement for buffer table
Foreign table inheritance
Grouping Sets
INSERT ... ON CONFLICT {UPDATE | IGNORE}
Pretty much everything on that list is something we've been wrestling
with as a project for at least half a decade. I remember people
complaining about DDL triggers when I first got involved in the
PostgreSQL community, and the initial patch for foreign tables had
support for inheritance and constraints which I ripped out before
committing as too half-baked. Pavel had a GROUPING SETS patch by
2009. Brainstorming solutions to the full_page_writes problem has
been a perennial PGCon after-hours activity for as long as I've been
going. So it's natural that, to the extent these patches are making
progress, they're doing so slowly. It's hard stuff to get right.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Dec 11, 2014 at 11:49:43AM -0500, Peter Eisentraut wrote:
On 12/11/14 1:35 AM, Bruce Momjian wrote:
While the commitfest process hasn't changed much and was very successful
in the first few years, a few things have changed externally:1 more new developers involved in contributing small patches
2 more full-time developers creating big patches
3 increased time demands on experienced Postgres developersThe number of patches registered in the commit fests hasn't actually
changed over the years. It has always fluctuated between 50 and 100,
depending on the point of the release cycle. So I don't think (1) is
necessarily the problem.
Yes, I was hoping someone would produce some numbers --- thanks. I
think the big question is whether the level of complexity of the patches
has increased, or whether it is just the amount of experienced developer
time (3) that has decreased, or something else. Or maybe things have
not materially changed at all over the years.
I am following this thought process:
1. Do we have a problem?
2. What is the cause of the problem?
3. How do we fix the problem?
I think to get a useful outcome we have to process things in that order.
So, is #1 true, and if so, what is the answer to #2?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/11/14 1:56 PM, Robert Haas wrote:
I feel like there's increasingly not that much easy stuff left to do.
Many of the problems we haven't solved yet are unsolved because they
are really hard, or because not that important, or both.
You know, I was telling people the very same thing in 2004.
Yet here we are.
Maybe we just need to relax and accept that we're awesome.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/11/14 1:35 AM, Bruce Momjian wrote:
I have heard repeated concerns about the commitfest process in the past
few months. The fact we have been in a continual commitfest since
August also is concerning.
I realized the other day, I'm embracing the idea of a continual commitfest.
I'm still working on patches from the last commitfest. Why not? They
didn't expire. Sure, it would have been nicer to get them done sooner,
but what are you gonna do? The fact that Nov 15 < now < Dec 15 isn't
going to change the fact that I have a few hours to spare right now and
the patches are still relevant.
As far as I'm concerned, we might as well just have one commitfest per
major release. Call it a patch list. Make the list sortable by created
date and last-updated date, and let the system police itself. At least
that's honest.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Dec 11, 2014 at 03:47:29PM -0500, Peter Eisentraut wrote:
On 12/11/14 1:35 AM, Bruce Momjian wrote:
I have heard repeated concerns about the commitfest process in the past
few months. The fact we have been in a continual commitfest since
August also is concerning.I realized the other day, I'm embracing the idea of a continual commitfest.
I'm still working on patches from the last commitfest. Why not? They
didn't expire. Sure, it would have been nicer to get them done sooner,
but what are you gonna do? The fact that Nov 15 < now < Dec 15 isn't
going to change the fact that I have a few hours to spare right now and
the patches are still relevant.As far as I'm concerned, we might as well just have one commitfest per
major release. Call it a patch list. Make the list sortable by created
date and last-updated date, and let the system police itself. At least
that's honest.
Wow, that's radical, and interesting.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/11/2014 01:07 PM, Bruce Momjian wrote:
On Thu, Dec 11, 2014 at 03:47:29PM -0500, Peter Eisentraut wrote:
On 12/11/14 1:35 AM, Bruce Momjian wrote:
I have heard repeated concerns about the commitfest process in
the past few months. The fact we have been in a continual
commitfest since August also is concerning.I realized the other day, I'm embracing the idea of a continual
commitfest.I'm still working on patches from the last commitfest. Why not?
They didn't expire. Sure, it would have been nicer to get them
done sooner, but what are you gonna do? The fact that Nov 15 <
now < Dec 15 isn't going to change the fact that I have a few
hours to spare right now and the patches are still relevant.As far as I'm concerned, we might as well just have one
commitfest per major release. Call it a patch list. Make the
list sortable by created date and last-updated date, and let the
system police itself. At least that's honest.Wow, that's radical, and interesting.
Actually, to me it sounds a lot like what we did 10 years ago before
the commitfests except with a way to track the patches (other than the
mail archives) and more people participating in patch reviews.
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJUigi9AAoJEDfy90M199hlgTEP/3wZov8w32JN8Olp/KV8OCsC
ZwTluKRxgfAMf3bZmimxrnD5SYvgj6RhGwBfPvnNXPub+ODfCqTkMJ9dx41Xv/H9
wm0sFctfZTJb3TLbdZS4slg32LMbpCXIwL4QmNAXmkbKqqTVkTx+G2RvjtdkIpSQ
ZApg4S7LvDazACZjTSl+bUNfzvu9Ygl6Nu4otgXaMbM1ntfKtgF3irpf0+K8Wwi9
7zQ1eU+bSnH9+/kb416WufLutIP182OalbB3BI1KbLURTL98FElUmPYD7xV39OwZ
tE6bFNwUDYdrZCR6B+vkbf/z+9xa8C2vqU9d85MyKNjV1sB1MXX5O+yMRT7eQd8q
JOX1IhKOMMS79c1LqB2vTQlv8lU6VD6gvxFGO4X2OD5cGaLyl4L90hSYmZDordQe
uhwtCo0xoBFExaNb1NF9bzH8u0bJJpxDYZJPPhMNcWMY7EZ3+McXU7MxinDwLh1D
wNynzrZs0Oq8jyn0XwGSF54urkC5clmpEwnhlzeiu2oHosgKLOOw688r38O77MOL
EtNDcVSq2x4B6ocCjGEN7Xcbjm8kbiuQoQJBXUm2C/lvqbiNyzYJ19oH01tHcVTC
oMv3MrhlJ4p83t40bZGqoDUpA5/hme255OgqRdDDH7WFGQXwA6CQEsROFshcIcyR
f7Zx9iww4SGACOj+j0OS
=hSWH
-----END PGP SIGNATURE-----
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Dec 11, 2014 at 01:12:30PM -0800, Joe Conway wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On 12/11/2014 01:07 PM, Bruce Momjian wrote:
On Thu, Dec 11, 2014 at 03:47:29PM -0500, Peter Eisentraut wrote:
On 12/11/14 1:35 AM, Bruce Momjian wrote:
I have heard repeated concerns about the commitfest process in
the past few months. The fact we have been in a continual
commitfest since August also is concerning.I realized the other day, I'm embracing the idea of a continual
commitfest.I'm still working on patches from the last commitfest. Why not?
They didn't expire. Sure, it would have been nicer to get them
done sooner, but what are you gonna do? The fact that Nov 15 <
now < Dec 15 isn't going to change the fact that I have a few
hours to spare right now and the patches are still relevant.As far as I'm concerned, we might as well just have one
commitfest per major release. Call it a patch list. Make the
list sortable by created date and last-updated date, and let the
system police itself. At least that's honest.Wow, that's radical, and interesting.
Actually, to me it sounds a lot like what we did 10 years ago before
the commitfests except with a way to track the patches (other than the
mail archives) and more people participating in patch reviews.
Yes, it does remind me of the mbox files I put on the web.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Bruce Momjian wrote:
On Thu, Dec 11, 2014 at 01:12:30PM -0800, Joe Conway wrote:
Actually, to me it sounds a lot like what we did 10 years ago before
the commitfests except with a way to track the patches (other than the
mail archives) and more people participating in patch reviews.Yes, it does remind me of the mbox files I put on the web.
The whole commitfest process was put in place in part precisely so we
could get rid of your mboxen. Please let's not get back to that!
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut-2 wrote
On 12/11/14 1:35 AM, Bruce Momjian wrote:
I have heard repeated concerns about the commitfest process in the past
few months. The fact we have been in a continual commitfest since
August also is concerning.I realized the other day, I'm embracing the idea of a continual
commitfest.As far as I'm concerned, we might as well just have one commitfest per
major release. Call it a patch list. Make the list sortable by created
date and last-updated date, and let the system police itself. At least
that's honest.
Having just written about the idea of a CF manager and a CF reviewer...
while having a continual CF works in theory I think breaking it down into,
say, quarters and having each pair commit to 3 months of being in charge has
some logic behind it.
The "patch list" concept should be formalized, and should include a
"targeted release" concept. The idea of a CF seems like it should apply to
the people involved and include an explicit choosing of items from the
"patch list" that are going to get attention by those people during the CF
period. A policy of every new addition being added to the next CF, along
with an item being involved in at least every other CF, would make sense.
Moving along the path of "continuous delivery" maybe just create "CF teams"
instead of a monolithic "CF process".
David J.
--
View this message in context: http://postgresql.nabble.com/Commitfest-problems-tp5830061p5830189.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/11/2014 01:52 PM, Alvaro Herrera wrote:
Bruce Momjian wrote:
On Thu, Dec 11, 2014 at 01:12:30PM -0800, Joe Conway wrote:
Actually, to me it sounds a lot like what we did 10 years ago before
the commitfests except with a way to track the patches (other than the
mail archives) and more people participating in patch reviews.Yes, it does remind me of the mbox files I put on the web.
The whole commitfest process was put in place in part precisely so we
could get rid of your mboxen. Please let's not get back to that!
Well, the CF process was added for 2 reasons:
1) We were losing track of some patches until integration time, when
Bruce suddently found them in the -hackers archives.
2) In order to give the senior committers some time *off* from reviewing
other people's patches. The idea was to spend 3 weeks or so intensively
reviewing others' patches, and then to have a month (or more) *off* from
working on anything but your own stuff.
While the CFs are still doing (1), support for (2) ended sometime in the
9.3 development cycle. Partly this is because current CFMs are not
permitted to take authoritative steps to ensure that the CF ends on
time, and partly it's because of the increase in big complicated patches
which just don't fit into the CF cycle.
Speaking as the originator of commitfests, they were *always* intended
to be a temporary measure, a step on the way to something else like
continuous integration.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Reply to msg id not found: WM96075b8140214a6efb6bb70e9568422e11ffaaaf0c52c8125951e05834745f680f3fafff0e1410143861c31159baef05@asav-2.01.com
On Thu, Dec 11, 2014 at 1:07 PM, Bruce Momjian <bruce@momjian.us> wrote:
As far as I'm concerned, we might as well just have one commitfest per
major release. Call it a patch list. Make the list sortable by created
date and last-updated date, and let the system police itself. At least
that's honest.Wow, that's radical, and interesting.
Agreed. I don't think it's radical, though - it's just acknowledging
the elephant in the room, which is that the commitfests in a given
cycle are not really distinct at all. I suspect that better tooling
had a lot to do with the success of commitfests, which is more or less
incidental to how they were originally conceived. There is still room
for improvement there.
I'd have to think about it some more, but I'd almost be ready to vote
for formalizing how things actually work in practice given the chance
(i.e. Voting to follow Peter's suggestion).
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
Well, the CF process was added for 2 reasons:
1) We were losing track of some patches until integration time, when
Bruce suddently found them in the -hackers archives.
2) In order to give the senior committers some time *off* from reviewing
other people's patches. The idea was to spend 3 weeks or so intensively
reviewing others' patches, and then to have a month (or more) *off* from
working on anything but your own stuff.
Right; I was in the middle of composing words to the same effect when
this arrived.
While the CFs are still doing (1), support for (2) ended sometime in the
9.3 development cycle. Partly this is because current CFMs are not
permitted to take authoritative steps to ensure that the CF ends on
time, and partly it's because of the increase in big complicated patches
which just don't fit into the CF cycle.
I don't see why you think CFMs are not "permitted" to close out a CF
when they want to. At least some of the fests have been closed out per
calendar schedule, punting unprocessed patches to the next fest. We've
certainly utterly failed to do that since August, but I think that's
mismanagement.
Speaking as the originator of commitfests, they were *always* intended
to be a temporary measure, a step on the way to something else like
continuous integration.
Really? How would that address (2)? And please note that part of the
problem we're having right now is that senior people are rebelling
against no longer having any agreed-on time off. IMV, goal (2) is
not optional; if you try to force people into continuous review work,
you'll just lose them completely.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/11/2014 02:12 PM, Tom Lane wrote:
Josh Berkus <josh@agliodbs.com> writes:
While the CFs are still doing (1), support for (2) ended sometime in the
9.3 development cycle. Partly this is because current CFMs are not
permitted to take authoritative steps to ensure that the CF ends on
time, and partly it's because of the increase in big complicated patches
which just don't fit into the CF cycle.I don't see why you think CFMs are not "permitted" to close out a CF
when they want to. At least some of the fests have been closed out per
calendar schedule, punting unprocessed patches to the next fest. We've
certainly utterly failed to do that since August, but I think that's
mismanagement.
I love how you're willing to accuse Michael of mismangement when you
yourself have *never* run a CF. If I was Michael, I'd quit right now.
Every CFM who has taken forceful measures to close out the CF on time
has gotten a large amount of flack for it, and absolutely zero back-up
from the committers or the core team. This is why David, Robert and I
will no longer manage CFs (and probably others as well). The CFM is
expected to miraculously end the CF on time, without bouncing or
forwarding unreviewed patches, cutting off patches which already had one
round of review, bouncing out or holding patches from contributors who
don't participate in the review process, nagging anyone too much, or
taking any other steps which anyone might take exception to.
In fact, the technique you cite (just punting the patches to the next
CF) resulted in Fetter getting a great deal of hassling on this list
when he did it. The only people who backed him up on it were other
former CFMs. And I closed out my CF on my expected schedule (based on
number of patches), but only after taking so much shit for it, I'm never
doing it again. And I have a pretty high tolerance for taking shit.
So now you're left with CFMs who won't do anything to wind up the CF
because they know that the committers and hackers will *not* support
them if they do. So, eternal CF.
How about *you* run the next one, Tom?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Reply to msg id not found: WM8628530e079a41e3e4f0f9905cec762f5cdb06ebc688254163ab38e3aa55bbc8423228054bba0ee9fdd40f47102dd863@asav-1.01.com
Josh Berkus <josh@agliodbs.com> writes:
How about *you* run the next one, Tom?
I think the limited amount of time I can put into a commitfest is better
spent on reviewing patches than on managing the process.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
