From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: community decision-making & 8.5 |
Date: | 2009-09-02 11:57:20 |
Message-ID: | 4A9E5DA0.4030904@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2009-09-02 12:02:46 | window functions maybe bug |
Previous Message | Sergey Konoplev | 2009-09-02 11:18:31 | Feature request: DEFAULT as input value of function argument |