community decision-making & 8.5

Robert Haas wrote:

http://archives.postgresql.org/pgsql-hackers/2009-08/msg01651.php
http://archives.postgresql.org/pgsql-hackers/2009-08/msg01983.php

Josh's schedule was subsequently endorsed by Simon Riggs. So by my
count we now have four votes for a 4-CF schedule and one for a 3-CF
schedule (me), maybe two if you count Tom, who I think was leaning in
that direction - so I guess that settles the matter?

I think this is a good illustration of the problems with
decision-making in a community environment - given choices "3" and "4"
most of the votes were somewhere between "3.25" and "3.75". I think,
in general, that when people weigh in with clear opinions, we're
pretty good about moving in the direction that most people want to go.
Even two votes can be enough for a consensus, if they both go in the
same direction. However, when the responses aren't clearly in favor
of one option or the other, or when no-one writes back at all, I think
we tend to flounder.

# Sorry, I could not follow the original thread due to the flood of
# message, but I would like to say my opinion.

From our experience in v8.4 development, it is important to handle
the last commit fest. At the last Nov, we had three big patches to
be reviewed, then we could close the last fest at the middle of
next March with postponing all of them.
In other word, if we don't have a consensus when the last commit
fest to be closed, N-commit fest can grow up (N+1)-commit fest
easily.

So, now, it seems to me Josh's proposition is reasonable.

| We do four CFs, July 15, September 15, November 15, and January 15.
|
| However, we rigidly apply the 30-day deadline for the January 15 CF.

In my reason, it may be a bit short to have only two commit fest remained.
At the first commit fest, I got a suggestion to reworks the native PostgreSQL
access control facilities, then SE-PostgreSQL should be implemented on the
common security abstraction layer.
So, if we have only two commit fests remained, it also means I have to
provide perfect works without any fails. :(

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

Robert Haas wrote:

I think this is a good illustration of the problems with
decision-making in a community environment - given choices "3" and "4"
most of the votes were somewhere between "3.25" and "3.75". I think,
in general, that when people weigh in with clear opinions, we're
pretty good about moving in the direction that most people want to go.
Even two votes can be enough for a consensus, if they both go in the
same direction. However, when the responses aren't clearly in favor
of one option or the other, or when no-one writes back at all, I think
we tend to flounder.

I think it should be up to whoever is the commitfest or release manager
to decide how he/she wants to manage them. That includes deciding how
many of them there is, when they start and when they end. Others can
give suggestions, plea for extensions, and whine.

With that power comes the responsibility to kick the right people at the
right times to make the schedule stick and get the release out of the door.

That implies that we need a release manager. Electing one would be the
first step. That's a lot of work and responsibility, with lots of
potential for making people cross, so in practice I think as soon as
someone steps up to the plate and volunteers to do it, he's the one.

I'm very happy with the way you ran the first commitfest. Thank you.
Want to manage the rest as well?

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On Wed, Sep 2, 2009 at 4:57 AM, Heikki
Linnakangas<heikki.linnakangas@enterprisedb.com> wrote:

That implies that we need a release manager. Electing one would be the
first step. That's a lot of work and responsibility, with lots of
potential for making people cross, so in practice I think as soon as
someone steps up to the plate and volunteers to do it, he's the one.

I'm very happy with the way you ran the first commitfest. Thank you.
Want to manage the rest as well?

+1 on both points.

-selena

--
http://chesnok.com/daily - me
http://endpoint.com - work

On Wed, 2009-09-02 at 12:50 -0700, Selena Deckelmann wrote:

On Wed, Sep 2, 2009 at 4:57 AM, Heikki
Linnakangas<heikki.linnakangas@enterprisedb.com> wrote:

That implies that we need a release manager. Electing one would be the
first step. That's a lot of work and responsibility, with lots of
potential for making people cross, so in practice I think as soon as
someone steps up to the plate and volunteers to do it, he's the one.

I'm very happy with the way you ran the first commitfest. Thank you.
Want to manage the rest as well?

+1 on both points.

Isn't "core" supposed to be the release manager?

Joshua D. Drake

-selena

--
http://chesnok.com/daily - me
http://endpoint.com - work

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering

Joshua D. Drake escribi�:

On Wed, 2009-09-02 at 12:50 -0700, Selena Deckelmann wrote:

On Wed, Sep 2, 2009 at 4:57 AM, Heikki
Linnakangas<heikki.linnakangas@enterprisedb.com> wrote:

That implies that we need a release manager. Electing one would be the
first step. That's a lot of work and responsibility, with lots of
potential for making people cross, so in practice I think as soon as
someone steps up to the plate and volunteers to do it, he's the one.

I'm very happy with the way you ran the first commitfest. Thank you.
Want to manage the rest as well?

+1 on both points.

Isn't "core" supposed to be the release manager?

Core is a decision-making committee. A release manager is a person,
maybe two, but a committee doesn't work (unless they'd split up tasks in
tickets and have them assigned etc, but I don't see -core doing that.)

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

On Wed, Sep 2, 2009 at 4:09 PM, Alvaro
Herrera<alvherre@commandprompt.com> wrote:

Joshua D. Drake escribió:

On Wed, 2009-09-02 at 12:50 -0700, Selena Deckelmann wrote:

On Wed, Sep 2, 2009 at 4:57 AM, Heikki
Linnakangas<heikki.linnakangas@enterprisedb.com> wrote:

That implies that we need a release manager. Electing one would be the
first step. That's a lot of work and responsibility, with lots of
potential for making people cross, so in practice I think as soon as
someone steps up to the plate and volunteers to do it, he's the one.

I'm very happy with the way you ran the first commitfest. Thank you.
Want to manage the rest as well?

+1 on both points.

Isn't "core" supposed to be the release manager?

Core is a decision-making committee.  A release manager is a person,
maybe two, but a committee doesn't work (unless they'd split up tasks in
tickets and have them assigned etc, but I don't see -core doing that.)

Previous emails from Tom seem to indicate that the mandate of -core is
mostly to decide things like the timing of releases. If we gave that
job to somebody else, would there be anything left for -core to do?
If so, what? And on the flip side, it is precisely because of the
lack of a clear statement on release timing from -core that we're
having these discussions here on -hackers. Personally, I think that's
better, since -core is a private list (why?) to which most of us don't
have access, and I don't see any reason why decisions like this can't
be made in public.

The only

On Wed, Sep 2, 2009 at 4:28 PM, Robert Haas<robertmhaas@gmail.com> wrote:

On Wed, Sep 2, 2009 at 4:09 PM, Alvaro
Herrera<alvherre@commandprompt.com> wrote:

Joshua D. Drake escribió:

On Wed, 2009-09-02 at 12:50 -0700, Selena Deckelmann wrote:

On Wed, Sep 2, 2009 at 4:57 AM, Heikki
Linnakangas<heikki.linnakangas@enterprisedb.com> wrote:

That implies that we need a release manager. Electing one would be the
first step. That's a lot of work and responsibility, with lots of
potential for making people cross, so in practice I think as soon as
someone steps up to the plate and volunteers to do it, he's the one.

I'm very happy with the way you ran the first commitfest. Thank you.
Want to manage the rest as well?

+1 on both points.

Isn't "core" supposed to be the release manager?

Core is a decision-making committee.  A release manager is a person,
maybe two, but a committee doesn't work (unless they'd split up tasks in
tickets and have them assigned etc, but I don't see -core doing that.)

Previous emails from Tom seem to indicate that the mandate of -core is
mostly to decide things like the timing of releases.  If we gave that
job to somebody else, would there be anything left for -core to do?
If so, what?  And on the flip side, it is precisely because of the
lack of a clear statement on release timing from -core that we're
having these discussions here on -hackers.  Personally, I think that's
better, since -core is a private list (why?) to which most of us don't
have access, and I don't see any reason why decisions like this can't
be made in public.

The only

Heh. Thankfully that wasn't one of the emails that needed to be
edited for tone before I sent it, or at least I hope not. Anyway, to
finish the thought, the only reason I can think of why we might not
want to publicly discuss release timing is to the extent that it is in
reaction to security vulnerabilities.

Anyway, I'm still curious about what'n'all -core actually does.

...Robert

Robert Haas <robertmhaas@gmail.com> writes:

Previous emails from Tom seem to indicate that the mandate of -core is
mostly to decide things like the timing of releases. If we gave that
job to somebody else, would there be anything left for -core to do?
If so, what? And on the flip side, it is precisely because of the
lack of a clear statement on release timing from -core that we're
having these discussions here on -hackers.

The core team sees its scheduling powers as more like this:
http://archives.postgresql.org/pgsql-hackers/2009-08/msg01803.php
not as determining now what the 8.5 schedule will be.

And yeah, the reason it's a private list has to do with security and
similar problems, not with discussions of long-term project scheduling.
The latter *should* happen on hackers, which is exactly where we're
having it. I think if the -hackers community got deadlocked, core
would try to use its authority to break the deadlock, but I see no
indication that that's needed here.

regards, tom lane

On Wed, Sep 2, 2009 at 9:28 PM, Robert Haas<robertmhaas@gmail.com> wrote:

Previous emails from Tom seem to indicate that the mandate of -core is
mostly to decide things like the timing of releases.

That's not all we do.

If we gave that
job to somebody else, would there be anything left for -core to do?
If so, what?  And on the flip side, it is precisely because of the
lack of a clear statement on release timing from -core that we're
having these discussions here on -hackers.  Personally, I think that's
better, since -core is a private list (why?) to which most of us don't
have access, and I don't see any reason why decisions like this can't
be made in public.

We try to do everything within the community whenever possible, which
is precisely why this discussion is happening here.

Other matters we deal with usually demand confidentiality which is why
-core is a closed list. That may include dealing with private
companies, or dealing with complaints or privacy issues raised by
people who do not wish to do so in public. Obviously I cannot go into
details, but some things just can't be handled on an open list.

We also very occasionally step in and make a decision if -hackers (or
another group) is deadlocked over an issue. For example, the whole
'change the name' debate.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

Robert Haas <robertmhaas@gmail.com> writes:

Anyway, I'm still curious about what'n'all -core actually does.

Not a lot. That's a feature, not a bug. Most project management
discussion happens on -hackers. If -hackers can't come to a decision
then core will try to resolve the deadlock (assuming we can agree ;-))
but we are well aware that we have a finite supply of authority,
and we try not to expend it unnecessarily.

regards, tom lane

Robert, Heikki,

http://archives.postgresql.org/pgsql-hackers/2009-08/msg01651.php
http://archives.postgresql.org/pgsql-hackers/2009-08/msg01983.php

Josh's schedule was subsequently endorsed by Simon Riggs. So by my
count we now have four votes for a 4-CF schedule and one for a 3-CF
schedule (me), maybe two if you count Tom, who I think was leaning in
that direction - so I guess that settles the matter?

I think there's a fairly clear consensus in favor of 4-CF. The reason
you've not heard from anyone else on the topic is that nobody is
objecting. So, at this point, we should go with it and someone (me,
Dave, Tom) should post a schedule somewhere.

That implies that we need a release manager. Electing one would be the
first step. That's a lot of work and responsibility, with lots of
potential for making people cross, so in practice I think as soon as
someone steps up to the plate and volunteers to do it, he's the one.

Having recently been immersed in the issues of the Perl 5 community, I'm
going to disagree and say that having a singular release manager would
be a bad idea. While an autocrat is a more rapid decision-maker, he or
she can also be a bottleneck ... and frequently is.

I do think that we (core) should show more leadership in enforcing the
deadlines that the hackers have already agreed on.

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

On Wed, Sep 2, 2009 at 5:55 PM, Josh Berkus<josh@agliodbs.com> wrote:

Robert, Heikki,

http://archives.postgresql.org/pgsql-hackers/2009-08/msg01651.php
http://archives.postgresql.org/pgsql-hackers/2009-08/msg01983.php

Josh's schedule was subsequently endorsed by Simon Riggs.  So by my
count we now have four votes for a 4-CF schedule and one for a 3-CF
schedule (me), maybe two if you count Tom, who I think was leaning in
that direction - so I guess that settles the matter?

I think there's a fairly clear consensus in favor of 4-CF.  The reason
you've not heard from anyone else on the topic is that nobody is
objecting.  So, at this point, we should go with it and someone (me,
Dave, Tom) should post a schedule somewhere.

I suggest -hackers for starters, on a new thread.

That implies that we need a release manager. Electing one would be the
first step. That's a lot of work and responsibility, with lots of
potential for making people cross, so in practice I think as soon as
someone steps up to the plate and volunteers to do it, he's the one.

Having recently been immersed in the issues of the Perl 5 community, I'm
going to disagree and say that having a singular release manager would
be a bad idea.  While an autocrat is a more rapid decision-maker, he or
she can also be a bottleneck ... and frequently is.

I do think that we (core) should show more leadership in enforcing the
deadlines that the hackers have already agreed on.

I was going to say that I'm perfectly fine with having an all-powerful
release manager, as long as it's me. I don't really think we need to
invest that much authority in one person, however - and certainly not
without more of a clearly-defined mandate for exactly what that person
is supposed to do with that authority. What I really think we need
is, as you say, more leadership in enforcing the agreed-upon
deadlines, and along with that, more leadership in setting the
deadlines (and other parameters) in the first place. However, I'm not
sure that that group should be coterminous with core. For example,
this is something that I'm pretty interested in helping with, and I am
obviously not a core team member. However, I'm not asking for an
exception just for me: I think that generally it's in the best
interest of the project to recruit MORE people to help with this work,
and if we say that it is the responsibility of core, then we're
confining it to a group of seven people of whom only five are
regularly active on -hackers. And several of those people are
committers who I would guess are somewhat overworked already.

I do think it would be good to have a list of who the people are who
are volunteering to help with commitfest and release management. ISTM
that well-organized list of such people would help a lot with
coordination and divvying up of responsibilities: who might be
available to help with X, who is already working on Y, etc.

...Robert

While test building from CVS head on fedora 10 (also on fedora 6), I get:

./configure --prefix=/home/super/pg_stuff/pg_installations/pgsql.cvs_vanilla --with-pgport=6542
--quiet --enable-depend --with-openssl --with-perl --with-libxml --with-libxslt

gcc (GCC) 4.3.2

compile OK, tests OK, install OK, without errors, then initdb:

initializing pg_authid ... ok
setting password ... ok
initdb: The password file was not generated. Please report this problem.
initdb: removing data directory "/home/super/pg_stuff/pg_installations/pgsql.cvs_vanilla/data"

hth,

Erik Rijkers

I suppose the initdb invocation is needed as well:

/home/super/pg_stuff/pg_installations/pgsql.cvs_vanilla/bin/initdb -U super -D
/home/super/pg_stuff/pg_installations/pgsql.cvs_vanilla/data -E UTF8
--pwfile=/home/super/pg_stuff/.84devel

( that .84devel file does exist )

"Erik Rijkers" <er@xs4all.nl> writes:

While test building from CVS head on fedora 10 (also on fedora 6), I get:
initializing pg_authid ... ok
setting password ... ok
initdb: The password file was not generated. Please report this problem.
initdb: removing data directory "/home/super/pg_stuff/pg_installations/pgsql.cvs_vanilla/data"

[ blink... ] initdb is looking for the flat password file. Which is
not there anymore. I guess the real question is not why it fails for
you, but why it works for anyone else!? Will investigate. In the
meantime, just dike out that test in initdb.c...

regards, tom lane

I wrote:

"Erik Rijkers" <er@xs4all.nl> writes:

While test building from CVS head on fedora 10 (also on fedora 6), I get:
initializing pg_authid ... ok
setting password ... ok
initdb: The password file was not generated. Please report this problem.
initdb: removing data directory "/home/super/pg_stuff/pg_installations/pgsql.cvs_vanilla/data"

[ blink... ] initdb is looking for the flat password file. Which is
not there anymore. I guess the real question is not why it fails for
you, but why it works for anyone else!? Will investigate. In the
meantime, just dike out that test in initdb.c...

Ah: the answer is that that test is only made when --pwfile or
--pwprompt is specified. I guess you're the first one to try those
since the no-flatfiles patch went in. Thanks for reporting;
fix is committed.

regards, tom lane

On ons, 2009-09-02 at 12:52 -0700, Joshua D. Drake wrote:

Isn't "core" supposed to be the release manager?

The core team has historically been the release *maker* and has some
done management of the final phases of that process. But I think the
sentiment is growing that we need more management throughout the entire
release cycle.

On Thu, 2009-09-03 at 07:44 +0300, Peter Eisentraut wrote:

On ons, 2009-09-02 at 12:52 -0700, Joshua D. Drake wrote:

Isn't "core" supposed to be the release manager?

The core team has historically been the release *maker* and has some
done management of the final phases of that process. But I think the
sentiment is growing that we need more management throughout the entire
release cycle.

O.k. so a "release" team. Cool. I am assuming the team would be more
directed toward upcoming major release versus minor releases to past
revisions. We already pretty much have that under control between -core
and -packagers. Yes?

Joshua D. Drake

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering

On Thu, Sep 3, 2009 at 11:38 AM, Joshua D. Drake<jd@commandprompt.com> wrote:

On Thu, 2009-09-03 at 07:44 +0300, Peter Eisentraut wrote:

On ons, 2009-09-02 at 12:52 -0700, Joshua D. Drake wrote:

Isn't "core" supposed to be the release manager?

The core team has historically been the release *maker* and has some
done management of the final phases of that process.  But I think the
sentiment is growing that we need more management throughout the entire
release cycle.

O.k. so a "release" team. Cool. I am assuming the team would be more
directed toward upcoming major release versus minor releases to past
revisions. We already pretty much have that under control between -core
and -packagers. Yes?

+1.

...Robert