On Fri, Jun 12, 2015 at 1:21 AM, Simon Riggs si...@2ndquadrant.com wrote:
Deciding WHAT goes in the next release? is what Committers do, by
definition.
It seems strange to have a different mailing list for WHEN is the next
release needed?, so those two things should be combined.
Core team
On Tue, Jun 9, 2015 at 6:35 PM, Bruce Momjian br...@momjian.us wrote:
There has been some confusion by old and new community members about the
purpose of the core team, and this lack of understanding has caused some
avoidable problems. Therefore, the core team has written a core charter
and
On Thu, Jun 11, 2015 at 3:22 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I think #1 is the part that we seem to have the most trouble with. It
seems easily fixable: establish a new mailing list for that task (say
pgsql-release) and get all the current -core in there, plus the set of
On 12 June 2015 at 06:48, Noah Misch n...@leadboat.com wrote:
On Thu, Jun 11, 2015 at 03:47:06PM -0300, Alvaro Herrera wrote:
Bruce Momjian wrote:
http://www.postgresql.org/developer/core/
After going over this a few times, there is one thing that strikes me
that nobody has
On Thu, Jun 11, 2015 at 03:47:06PM -0300, Alvaro Herrera wrote:
Bruce Momjian wrote:
http://www.postgresql.org/developer/core/
After going over this a few times, there is one thing that strikes me
that nobody has mentioned: the list of tasks mentioned there has one
that's completely
On 06/11/2015 05:08 PM, Peter Geoghegan wrote:
On Thu, Jun 11, 2015 at 9:49 AM, Andrew Dunstan and...@dunslane.net wrote:
JoshB: Advocacy. There is a strong argument that does not need to be a
core position.
I strongly disagree with this. On the contrary, I think there is a very good
On Thu, Jun 11, 2015 at 9:49 AM, Andrew Dunstan and...@dunslane.net wrote:
JoshB: Advocacy. There is a strong argument that does not need to be a
core position.
I strongly disagree with this. On the contrary, I think there is a very good
argument that FOR such a position in core.
+1.
--
On Thu, Jun 11, 2015 at 4:26 PM, Robert Haas robertmh...@gmail.com wrote:
Timing *decisions* are not made by -core, as I've told you in the
past. They are made by the packagers who do the actual work, based on
suggestions from -core.
You have told me that in the past, and I do not accept
On 06/11/2015 08:26 AM, Robert Haas wrote:
Timing *decisions* are not made by -core, as I've told you in the
past. They are made by the packagers who do the actual work, based on
suggestions from -core.
You have told me that in the past, and I do not accept that it is true.
The suggestions
On 06/11/2015 07:12 AM, Robert Haas wrote:
Hopefully this will be helpful to people.
I believe the core team is suffering from a lack of members who are
involved in writing, reviewing, and committing patches. Those things
are not core functions of the core team, as that charter
On 06/11/2015 12:29 PM, Joshua D. Drake wrote:
JoshB: Advocacy. There is a strong argument that does not need to be a
core position.
I strongly disagree with this. On the contrary, I think there is a very
good argument that FOR such a position in core.
cheers
andrew
--
Sent via
On Thu, Jun 11, 2015 at 12:13 PM, Joshua D. Drake j...@commandprompt.com
wrote:
This is crap. I am on the packagers list. Core always asks what people think
and no it is not always accepted. There have been many times that the
release has been pushed off because of resources available or new
On 06/11/2015 09:49 AM, Andrew Dunstan wrote:
On 06/11/2015 12:29 PM, Joshua D. Drake wrote:
JoshB: Advocacy. There is a strong argument that does not need to be a
core position.
I strongly disagree with this. On the contrary, I think there is a very
good argument that FOR such a
On Thu, Jun 11, 2015 at 6:29 PM, Joshua D. Drake j...@commandprompt.com
wrote:
On 06/11/2015 07:12 AM, Robert Haas wrote:
Hopefully this will be helpful to people.
I believe the core team is suffering from a lack of members who are
involved in writing, reviewing, and committing patches.
On 06/11/2015 10:10 AM, Magnus Hagander wrote:
Magnus: Committer, primary Windows dude and reviews patches here and
there.
Not sure that's a fair title at this point. Both Andrew and Michael seem
to be doing more of that than me these days, for example. (I do review
patches here and
On Thu, Jun 11, 2015 at 12:29 PM, Joshua D. Drake j...@commandprompt.com
wrote:
However, the core team needs to know when it should initiate a
release, and to do that it needs to understand the impact of bugs that
have been fixed and bugs that have not been fixed. The recent
discussion of
On 06/11/2015 10:20 AM, Robert Haas wrote:
True but that isn't the fault of core outside of communication. The hackers,
reviewers and committers of those patches should be required to communicate
with core in a way that expresses the true severity of a situation so core
can make a:
Management
Bruce Momjian wrote:
There has been some confusion by old and new community members about the
purpose of the core team, and this lack of understanding has caused some
avoidable problems. Therefore, the core team has written a core charter
and published it on our website:
On 06/11/2015 11:47 AM, Alvaro Herrera wrote:
After going over this a few times, there is one thing that strikes me
that nobody has mentioned: the list of tasks mentioned there has one
that's completely unlike the others. These are related to human
relations:
Acting as a conduit for
On Thu, Jun 11, 2015 at 2:50 PM, Josh Berkus j...@agliodbs.com wrote:
On 06/11/2015 11:47 AM, Alvaro Herrera wrote:
After going over this a few times, there is one thing that strikes me
that nobody has mentioned: the list of tasks mentioned there has one
that's completely unlike the others.
Robert Haas wrote:
The release process has multiple parts:
1. Deciding that we need to do a release, either because $BUG is
really bad or because we have security fixes to release or because
enough time has gone by.
2. Updating translations and time zones and release notes and stamping
On Thu, Jun 11, 2015 at 11:13 AM, Dave Page dp...@pgadmin.org wrote:
Yes, and we have recently been discussing how best to solicit those
opinions this year.
Great!
As a non-core team member, I find it quite frustrating that getting a
release triggered requires emailing a closed mailing list.
22 matches
Mail list logo
