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

On Thu, 2009-09-03 at 11:41 -0400, Robert Haas wrote:

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.

O.k. so the second part of this, is I feel it should contain a majority
of people who are not already being slammed into the ground by community
work. E.g; let's get some fresh blood. It is certainly important to have
a couple of long standing contributors involved but we have some people
that have cropped up recently (relatively) within our community that
could probably be overworked a bit more ;)

Joshua D. Drake

/me pokes Robert Haas and Kevin Grittner

...Robert

--
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:55 AM, Joshua D. Drake<jd@commandprompt.com> wrote:

On Thu, 2009-09-03 at 11:41 -0400, Robert Haas wrote:

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.

O.k. so the second part of this, is I feel it should contain a majority
of people who are not already being slammed into the ground by community
work. E.g; let's get some fresh blood. It is certainly important to have
a couple of long standing contributors involved but we have some people
that have cropped up recently (relatively) within our community that
could probably be overworked a bit more ;)

Joshua D. Drake

/me pokes Robert Haas and Kevin Grittner

Yeah, I'm game, though I'm hoping not to become the guy who spends all
his time doing release planning, because I like writing code, too.
Hopefully Selena won't mind my mentioning that she sent me a private
email expressing some interest in this area, too.

And /me pokes Brendan Jurd. :-)

...Robert

On Thu, 2009-09-03 at 12:00 -0400, Robert Haas wrote:

O.k. so the second part of this, is I feel it should contain a majority
of people who are not already being slammed into the ground by community
work. E.g; let's get some fresh blood. It is certainly important to have
a couple of long standing contributors involved but we have some people
that have cropped up recently (relatively) within our community that
could probably be overworked a bit more ;)

Joshua D. Drake

/me pokes Robert Haas and Kevin Grittner

Yeah, I'm game, though I'm hoping not to become the guy who spends all
his time doing release planning, because I like writing code, too.

Of course.

Hopefully Selena won't mind my mentioning that she sent me a private
email expressing some interest in this area, too.

She would definitely be a good option if she has time. I know that I
would be interested and I would like to see at least one long time
-hacker on board.

And /me pokes Brendan Jurd. :-)

Hah! I almost listed him. /me adds a poke to Brendan Jurd.

Sincerely,

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

"Joshua D. Drake" <jd@commandprompt.com> wrote:

/me pokes Robert Haas and Kevin Grittner

I'm honored to be suggested for such a role. I'm happy to do what I
can, but am reluctant to put myself too squarely in any critical path,
as I have responsibility for dealing with some family health issues
which make unpredictable demands on my free time and energy. If
things can be arranged so that what I *can* do contributes, but my
absence at times does no harm, I'm happy to help.

Robert Haas is obviously an outstanding suggestion.

-Kevin

On Thu, Sep 3, 2009 at 9:00 AM, Robert Haas<robertmhaas@gmail.com> wrote:

Yeah, I'm game, though I'm hoping not to become the guy who spends all
his time doing release planning, because I like writing code, too.
Hopefully Selena won't mind my mentioning that she sent me a private
email expressing some interest in this area, too.

Not at all! My schedule is largely open this fall and winter, and I
have a patch or two that I aught to finish soonish as well.

-selena

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

Selena, Robert, Brendan, Kevin,

One of the ideas behind the Alpha releases was to give someone other
than the core team some practice doing releases.

So I think it would make sense for you guys to do Alpha2. Agreed, Peter?

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

On Thu, 2009-09-03 at 10:21 -0700, Josh Berkus wrote:

Selena, Robert, Brendan, Kevin,

One of the ideas behind the Alpha releases was to give someone other
than the core team some practice doing releases.

So I think it would make sense for you guys to do Alpha2. Agreed, Peter?

I think we need at least one long term contributor or core member to
participate in this. Peter would you be up for a Liaison to Core and
active release person?

Joshua D. Drake

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

--
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 1:21 PM, Josh Berkus<josh@agliodbs.com> wrote:

Selena, Robert, Brendan, Kevin,

One of the ideas behind the Alpha releases was to give someone other
than the core team some practice doing releases.

So I think it would make sense for you guys to do Alpha2.  Agreed, Peter?

I have no interest in that.

...Robert

On Thu, Sep 3, 2009 at 10:21 AM, Josh Berkus<josh@agliodbs.com> wrote:

Selena, Robert, Brendan, Kevin,

One of the ideas behind the Alpha releases was to give someone other
than the core team some practice doing releases.

So I think it would make sense for you guys to do Alpha2.  Agreed, Peter?

I'm up for it! :)

Like Robert as expressed on other management roles, I am not
interested in doing it forever. I am certainly up for being part of a
rotating team, and documenting/automating things as much as possible.

-selena

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

Josh Berkus <josh@agliodbs.com> wrote:

So I think it would make sense for you guys to do Alpha2.

I'm not really clear on what that means. I'm assuming that part of
the goal is for us to become more intimately familiar with the details
of putting together a release, documenting the process, and suggesting
possible process improvements. But I think I need a little more of a
broad outline, at least, of what would fall to this team.

Are we talking about taking things from the end of the CF up to the
point of publishing the alpha release files? We would try to cover,
to the extent we can, the jobs normally done in a major release by
Tom, Bruce, and others? (Partly to free them to do other work during
the alpha release preparation?) Or am I totally off base in what
you're talking about?

-Kevin

Josh Berkus <josh@agliodbs.com> writes:

Selena, Robert, Brendan, Kevin,
One of the ideas behind the Alpha releases was to give someone other
than the core team some practice doing releases.

Uh, what's the point of that? The existing core team has that process
perfectly well in hand. What I thought this discussion was about was
putting more effort into long-range project planning/management.

regards, tom lane

On Thu, Sep 3, 2009 at 2:27 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:

Josh Berkus <josh@agliodbs.com> writes:

Selena, Robert, Brendan, Kevin,
One of the ideas behind the Alpha releases was to give someone other
than the core team some practice doing releases.

Uh, what's the point of that?  The existing core team has that process
perfectly well in hand.  What I thought this discussion was about was
putting more effort into long-range project planning/management.

Exactly. I don't see much value in investing a lot of time and effort
in something that's already working well. If someone has a complaint
about the way the process for packaging and bundling releases is
working, then let's hear it (on a separate thread!), but all of the
discussions that we've had on this thread are about making sure that
we set time lines and expectations early, stick to them, and resolve
issues that come up in a timely fashion. Those are basically all
process issues, and I don't see much value in throwing one technical
task into the mix.

...Robert

On Thu, Sep 3, 2009 at 11:27 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote:

Josh Berkus <josh@agliodbs.com> writes:

Selena, Robert, Brendan, Kevin,
One of the ideas behind the Alpha releases was to give someone other
than the core team some practice doing releases.

Uh, what's the point of that?  The existing core team has that process
perfectly well in hand.  What I thought this discussion was about was
putting more effort into long-range project planning/management.

Ok! I was volunteering for work, not suggesting a process was broken.

There's plenty to do around commitfest, so I'll stick to taking tasks there!

-selena

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

* Joshua D. Drake (jd@commandprompt.com) wrote:

She would definitely be a good option if she has time. I know that I
would be interested and I would like to see at least one long time
-hacker on board.

I don't presume to be a long time -hacker, but I'm interested in what I
can do to help with this. I like the general approach. I'm also up for
being involved in 'managing' beta testers. Not sure if that role would
be appropriate for this group, though it seems like it'd be a natural
fit as it's directly related to the "is the release ready" question..

Just my 2c.

Thanks,

Stephen

2009/9/4 Joshua D. Drake <jd@commandprompt.com>:

On Thu, 2009-09-03 at 12:00 -0400, Robert Haas wrote:

And /me pokes Brendan Jurd.  :-)

Hah! I almost listed him. /me adds a poke to Brendan Jurd.

/me stirs from sleep to announce "huh? whaddyawant?"

Seriously though, I have been keeping an eye on this thread, and I
think it's heading in an interesting and positive direction.

Still I'm a little unclear on what would be expected of, and indeed
what I could contribute to, the "release team" effort.

So far in the thread I've seen mention of
deciding/announcing/enforcing project deadlines, managing commit
fests, beta testing and beta-to-release items. Is that about the
right idea?

Cheers,
BJ

On Wed, Sep 02, 2009 at 07:22:27PM -0400, Robert Haas wrote:

On Wed, Sep 2, 2009 at 5:55 PM, Josh Berkus<josh@agliodbs.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.

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.

Seeing your performance and involvement in the project so far, I
would be ready to agree with you here ;)

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 agree, I see no reason for core being the one group to enforce
deadlines. Put together a release team and have it take care of
enforcing deadlines (ruthlessly if need be).

Kristian.

-- 
Kristian Larsson                                        KLL-RIPE
+46 704 264511			              kll@spritelink.net

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

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.

I wouldn't really hold that up as a shining example of a core decision. :)
Heck, I still can't understand it - the majority of core is decidely
for changing the name back to "Postgres" (some adamantly so), but somehow
as a committee they manage to reach the opposite conclusion?

Time to start lobbying for the name change again I suppose. As Bruce said
two years ago in August 2007:

<quote>
What I think we will find in two years it that many
will wish we had made the change pre-8.3 because in
two years we will be even more entrenched than we are now.

The bottom line is that the pronunciation/marketing problem with the
name "PostgreSQL" is not going to change --- it is only going to get
worse.
</quote>

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200909102043
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkqpnr8ACgkQvJuQZxSWSsht+ACfeD+Cy/uG4a+zMQEwSvahao5i
jNAAniSu/y7vazK+L9cKGQTHlQaGw8Pa
=eeVM
-----END PGP SIGNATURE-----

Greg,

Time to start lobbying for the name change again I suppose. As Bruce said
two years ago in August 2007:

Man, you are a masochist, aren't you?

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

"Greg Sabino Mullane" <greg@turnstep.com> writes:

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.

I wouldn't really hold that up as a shining example of a core decision. :)

The point of core's action then was to put a stop to an unproductive
flamewar. Which it did. Could we please not restart that?

regards, tom lane

Selena Deckelmann wrote:

On Thu, Sep 3, 2009 at 9:00 AM, Robert Haas<robertmhaas@gmail.com> wrote:

Yeah, I'm game, though I'm hoping not to become the guy who spends all
his time doing release planning, because I like writing code, too.
Hopefully Selena won't mind my mentioning that she sent me a private
email expressing some interest in this area, too.

Not at all! My schedule is largely open this fall and winter, and I
have a patch or two that I aught to finish soonish as well.

FYI, my schedule in the next few months is not good. I just returned
from 19 days of traveling (mostly vacation), and will be attending
conferences two weeks in October and two weeks in November.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +