Thread: The purpose of the core team
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:
http://www.postgresql.org/developer/core/
Hopefully this will be helpful to people.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +
On Tue, Jun 9, 2015 at 6:35 PM, Bruce Momjian <bruce@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 published it on our website: > > http://www.postgresql.org/developer/core/ > > 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 illustrates. 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 multixacts seems to indicate that the number of core team members who had a clear understanding of the issues was zero, which I view as unfortunate. The core team also needs to make good decisions about who should be made a committer, and the people who are doing reviews and commits of other people's patches are in the best position to have an informed opinion on that topic. As a non-core team member, I find it quite frustrating that getting a release triggered requires emailing a closed mailing list. I am not a party to all of the discussion on my request, and the other people who might know whether my request is technically sound or not are not party to that discussion either. I disagreed with the decision to stamp 9.4.3 without waiting for b6a3444fa63519a0192447b8f9a332dddc66018f, but of course I couldn't comment on it, because it was decided in a forum in which I don't get to participate, on a thread on which I was not copied. I realize that, because decisions about whether to release and when to release often touch on security issues, not all of this discussion can be carried on in public. But when the cone of secrecy is drawn in so tightly that excludes everyone who actually understands the technical issues related to the proposed release, we have lost our way, and do our users a disservice. I am not sure whether the solution to this problem is to add more people to the core team, or whether the solution is to move release timing decisions and committer selection out of the core team to some newly-created group. But I believe that change is needed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Jun 11, 2015 at 3:12 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Tue, Jun 9, 2015 at 6:35 PM, Bruce Momjian <bruce@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 published it on our website: >> >> http://www.postgresql.org/developer/core/ >> >> 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 illustrates. > 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 multixacts seems to indicate that the number of core > team members who had a clear understanding of the issues was zero, > which I view as unfortunate. The core team also needs to make good > decisions about who should be made a committer, and the people who are > doing reviews and commits of other people's patches are in the best > position to have an informed opinion on that topic. Yes, and we have recently been discussing how best to solicit those opinions this year. > As a non-core team member, I find it quite frustrating that getting a > release triggered requires emailing a closed mailing list. It does not, unless you're talking about a security release. You might have to prod people if they overlook an email on -hackers, but you can certainly suggest releasing updates there. > I am not a > party to all of the discussion on my request, and the other people who > might know whether my request is technically sound or not are not > party to that discussion either. I disagreed with the decision to > stamp 9.4.3 without waiting for > b6a3444fa63519a0192447b8f9a332dddc66018f, but of course I couldn't > comment on it, because it was decided in a forum in which I don't get > to participate, on a thread on which I was not copied. All of the technical discussion was done outside -core, in lists on which you are a member. We simply discussed the possible impacts of scheduling constraints given our personal availability to deal with the release process, and the possible PR impact of waiting. Even then I think there were all of maybe half a dozen short comments on the thread. > I realize > that, because decisions about whether to release and when to release > often touch on security issues, not all of this discussion can be > carried on in public. But when the cone of secrecy is drawn in so > tightly that excludes everyone who actually understands the technical > issues related to the proposed release, we have lost our way, and do > our users a disservice. > > I am not sure whether the solution to this problem is to add more > people to the core team, or whether the solution is to move release > timing decisions and committer selection out of the core team to some > newly-created group. But I believe that change is needed. 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. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Jun 11, 2015 at 11:13 AM, Dave Page <dpage@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. > > It does not, unless you're talking about a security release. You might > have to prod people if they overlook an email on -hackers, but you can > certainly suggest releasing updates there. I certainly can suggest it in a variety of ways on a variety of mailing lists. Getting it to happen is a different thing. > 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 from -core are always accepted, or as near as makes no difference. So in effect, -core decides. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Jun 11, 2015 at 4:26 PM, Robert Haas <robertmhaas@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 that it is true. > > The suggestions from -core are always accepted, or as near as makes no > difference. So in effect, -core decides. No, that means we have some very committed people handling the release process, who are mostly able to put in the effort on the dates suggested, and on the odd occasion when they can't for some reason, we (core and packagers) figure out the best date for everyone involved. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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 from -core are always accepted, or as near as makes no > difference. So in effect, -core decides. Robert, 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 information being provided. There have also been plenty of well worn FOSS arguments on that list to make sure that everything is done in a mature, reliable and professional way. JD -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564 PostgreSQL Centered full stack support, consulting and development. Announcing "I'm offended" is basically telling the world you can't control your own emotions, so everyone else should do it for you.
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 illustrates. Bruce: Committer, maintains pg_upgrade and reviews patches here and there. Magnus: Committer, primary Windows dude and reviews patches here and there. Peter: Committer, reviews patches not only on -hackers but also -docs Tom: Enough said Dave: Committer, agreed that he doesn't do much -hackers work but I guarantee you he provides a unique perspective to the rest of his group due to his management of PgAdmin and an entire team at EDB. JoshB: Advocacy. There is a strong argument that does not need to be a core position. In short, I don't agree with you. > 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 multixacts seems to indicate that the number of core > team members who had a clear understanding of the issues was zero, 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 decision. > which I view as unfortunate. The core team also needs to make good > decisions about who should be made a committer, and the people who are > doing reviews and commits of other people's patches are in the best > position to have an informed opinion on that topic. Which happens. > > As a non-core team member, I find it quite frustrating that getting a > release triggered requires emailing a closed mailing list. I am not a > party to all of the discussion on my request, and the other people who > might know whether my request is technically sound or not are not > party to that discussion either. Nor should you be. This idea that all communications must be open is a joke and shows a lack of maturity in a community. There are things that must be discussed in private for many reasons. Now, if you are saying that core isn't reaching out directly to people involved in suspect work to make a quality decision that may be one thing but I also know that happens. > I disagreed with the decision to > stamp 9.4.3 without waiting for > b6a3444fa63519a0192447b8f9a332dddc66018f, but of course I couldn't > comment on it, because it was decided in a forum in which I don't get > to participate, on a thread on which I was not copied. We do not all have to agree and further there is nothing stopping you from commenting on -hackers. If enough people agree with you, core is going to listen. > I realize > that, because decisions about whether to release and when to release > often touch on security issues, not all of this discussion can be > carried on in public. But when the cone of secrecy is drawn in so > tightly that excludes everyone who actually understands the technical > issues related to the proposed release, we have lost our way, and do > our users a disservice. > We can't lose our way when this is the way it has always been. > I am not sure whether the solution to this problem is to add more > people to the core team, or whether the solution is to move release > timing decisions and committer selection out of the core team to some > newly-created group. But I believe that change is needed. > If you have a people problem and you add people, you only have a bigger people problem. In terms of timing and committer selection, core does a very good job. Core has been around longer than you have and has shown great respect, maturity and management skills with most (not all of course) aspects of this community. There is one change to core that I (and I know others) would like to see: They should be serve a finite term and be elected. Sincerely, JD -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564 PostgreSQL Centered full stack support, consulting and development. Announcing "I'm offended" is basically telling the world you can't control your own emotions, so everyone else should do it for you.
On Thu, Jun 11, 2015 at 12:13 PM, Joshua D. Drake <jd@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 > information being provided. There have also been plenty of well worn FOSS > arguments on that list to make sure that everything is done in a mature, > reliable and professional way. I think I've gotten sucked into arguing about something I don't really want to argue about. I agree that -core is always very polite when they asked on -packagers, and that -core would probably move the release date if subscribers to -packagers asked them so to do. I also do not dispute Dave's statement that PostgreSQL's packagers are very committed. That is certainly true. From what I can see they bend over backwards to get the job done, which is great. Now, I cannot personally recall, nor find in my email archives, an occasion on which -packagers asked for the release date to be moved. But you or others may be able to, and that is fine, but it's not what I'm unhappy about. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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
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 position in core. In the past, absolutely. However we have a very strong and powerful advocacy network now including two non-profits that are heavily involved. That said, I am not advocating that the the position be removed as much as stating that in my opinion it isn't necessary. JD -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564 PostgreSQL Centered full stack support, consulting and development. Announcing "I'm offended" is basically telling the world you can't control your own emotions, so everyone else should do it for you.
On Thu, Jun 11, 2015 at 6:29 PM, Joshua D. Drake <jd@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. Those things
are not core functions of the core team, as that charter illustrates.
Bruce: Committer, maintains pg_upgrade and reviews patches here and there.
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 there, but not as much as I'd like)
Peter: Committer, reviews patches not only on -hackers but also -docs
Tom: Enough said
Dave: Committer, agreed that he doesn't do much -hackers work but I guarantee you he provides a unique perspective to the rest of his group due to his management of PgAdmin and an entire team at EDB.
Dave is not and never was a committer on the actual postgresql code - only on other subprojects.
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 there, but not as much as I'd like) > > > Peter: Committer, reviews patches not only on -hackers but also -docs > > Tom: Enough said > > Dave: Committer, agreed that he doesn't do much -hackers work but I > guarantee you he provides a unique perspective to the rest of his > group due to his management of PgAdmin and an entire team at EDB. > > > > Dave is not and never was a committer on the actual postgresql code - > only on other subprojects. Thank you for the clarification. JD -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564 PostgreSQL Centered full stack support, consulting and development. Announcing "I'm offended" is basically telling the world you can't control your own emotions, so everyone else should do it for you.
On Thu, Jun 11, 2015 at 12:29 PM, Joshua D. Drake <jd@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 multixacts seems to indicate that the number of core >> team members who had a clear understanding of the issues was zero, > > 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 decision. I feel I've been making an honest and sincere effort do that with limited success. If you're confident that that is my fault rather than a sign of any possible problem with core, then I certainly respect your right to hold that opinion. >> As a non-core team member, I find it quite frustrating that getting a >> release triggered requires emailing a closed mailing list. I am not a >> party to all of the discussion on my request, and the other people who >> might know whether my request is technically sound or not are not >> party to that discussion either. > > Nor should you be. This idea that all communications must be open is a joke > and shows a lack of maturity in a community. There are things that must be > discussed in private for many reasons. You are arguing against a straw man, since I explicitly said they should not be. What I know, though, is that over the last four weeks, four committers and one other contributor worked round the clock for days to fix MultiXact bugs and test the fixes, and after that, it emerged that (at least as far as I can tell) nobody from core was even reading the -hackers thread closely enough to understand what problems we were actually fixing, or even the long commit message I wrote explaining it. I think it's silly to argue that there is no need for any overlap between the set of people who know why we need to do a release and the set of people deciding when to do it, but if I am in the minority, then so be it. >> I disagreed with the decision to >> stamp 9.4.3 without waiting for >> b6a3444fa63519a0192447b8f9a332dddc66018f, but of course I couldn't >> comment on it, because it was decided in a forum in which I don't get >> to participate, on a thread on which I was not copied. > > We do not all have to agree and further there is nothing stopping you from > commenting on -hackers. If enough people agree with you, core is going to > listen. It doesn't do much good when you only find out about the decision after it has been made. > There is one change to core that I (and I know others) would like to see: > > They should be serve a finite term and be elected. In the rest of the email, you seemed to be arguing that there were no problems with core and that everything is working great. Here you are saying perhaps some change would be helpful and constructive for the project. I agree with the latter position, but not the former. On the question of whether that means elections or something else, I don't know what is best. I am honestly not trying to completely overturn the apple cart here. Obviously, many things that core has done - and is doing - for the project have worked out very well. The fact that things are not perfect is, as you say, to be expected. And certainly I appreciate the time that everyone puts into this project, which for the core team members adds up to a whole lot of time over very many years. Nevertheless, our release scheduling has been sluggish; Andres mentioned to me one occasion on which it took, IIRC, two months before we did a release of a fix for a data-corrupting multixact bug, which I think is too long; and there was a gap of more than 6 months between 9.3.5 and 9.3.6, which IMHO is too long even if no individual top-priority issue was fixed during that time. The fact that the core team (and the packagers!) are very dedicated is not a reason not to talk about these problems and how to fix them. I don't believe that we need to completely change the current system in order to make things better, but I don't believe that we need to change nothing, either. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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 decision. > > I feel I've been making an honest and sincere effort do that with > limited success. I have no disagreement with this statement. Bruce, you and I have all been advocating slowing down a bit (when it comes to the recent releases), we are obviously in the minority. Instead of a huge thread of complaining from a bunch of people how about we just say, "These are the productive steps I would like to see" Here are a few of mine: 1. I would like to see core elected to terms. I think the terms should be multi-year but no more than 2 or 3 years. 2. I would like to see more transparent discussion from core. This is a fine line. We shouldn't be talking about potential security issues publicly. On the other hand there is question about whether or not core had any business putting out the statement on the Russian conference. Note: I am not saying whether I agree or disagree with the statement. I am only talking about whether or not it was appropriate for core to handle it. 3. I would like to see core institute a different release policy. I think something similar to Ubuntu would be a big boon for us. 4. I would like to see core be a strictly technical committee. I think that advocacy and such with guidance from the community including core should be reflective of the community as a whole. JD -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564 PostgreSQL Centered full stack support, consulting and development. Announcing "I'm offended" is basically telling the world you can't control your own emotions, so everyone else should do it for you.
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: > > http://www.postgresql.org/developer/core/ > > Hopefully this will be helpful to people. 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 confidential communication. Making policy announcements. Managing permissions for commits,infrastructure, etc. Handling disciplinary issues. Making difficult decisions when consensus is lacking. while this one is highly technical: Coordinating release activities. It seems that only this last one is where most people seem to have a problem. I wonder if it makes sense to create a separate group that handles release activites -- the "release team." -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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 confidential communication. > Making policy announcements. > Managing permissions for commits, infrastructure, etc. > Handling disciplinary issues. > Making difficult decisions when consensus is lacking. > > while this one is highly technical: > Coordinating release activities. > > It seems that only this last one is where most people seem to have a > problem. I wonder if it makes sense to create a separate group that > handles release activites -- the "release team." De-facto, this is Packagers. Which is maybe not the best system, but it's what we're doing now. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Thu, Jun 11, 2015 at 2:50 PM, Josh Berkus <josh@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. These are related to human >> relations: >> >> Acting as a conduit for confidential communication. >> Making policy announcements. >> Managing permissions for commits, infrastructure, etc. >> Handling disciplinary issues. >> Making difficult decisions when consensus is lacking. >> >> while this one is highly technical: >> Coordinating release activities. >> >> It seems that only this last one is where most people seem to have a >> problem. I wonder if it makes sense to create a separate group that >> handles release activites -- the "release team." > > De-facto, this is Packagers. Which is maybe not the best system, but > it's what we're doing now. 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 version numbers and building tarballs. 3. Packaging and releasing tarballs. 4. Writing and publicizing the release announcement. #3 happens on pgsql-packagers and AFAICT it works fine. The problems are primarily with #1, and sometimes with #2 to the extent that Tom and Peter pretty much do them every time, so if they're not available, nobody else can step in. I have no complaints about #4. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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 > version numbers and building tarballs. > 3. Packaging and releasing tarballs. > 4. Writing and publicizing the release announcement. > > #3 happens on pgsql-packagers and AFAICT it works fine. The problems > are primarily with #1, and sometimes with #2 to the extent that Tom > and Peter pretty much do them every time, so if they're not available, > nobody else can step in. I have no complaints about #4. I am familiar with the part of #2 that Peter does, so I could do that in case of need. Not sure about the tzdata updates, but I expect that it should be reasonably straightforward. Stamping version numbers and building tarballs are tasks now scripted, so I think any well-documented release officer could do them also. Of that bunch, writing the release notes seems the most difficult. 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 active committers. That group would handle tasks #1 and #2 above. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Jun 11, 2015 at 3:22 PM, Alvaro Herrera <alvherre@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 > active committers. That group would handle tasks #1 and #2 above. +1. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Jun 11, 2015 at 9:49 AM, Andrew Dunstan <andrew@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. -- Peter Geoghegan
On 06/11/2015 05:08 PM, Peter Geoghegan wrote: > On Thu, Jun 11, 2015 at 9:49 AM, Andrew Dunstan <andrew@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. FYI, what do I mostly for Core is: a) Press Relations b) Corporate Relations Both of those need to be handled by a core team member, because they often fall under the "confidential contact" portion of Core's duties, or require nonpublic knowledge of things like security releases. I agree that general advocacy can certainly be handled outside core, and should be -- and, for that matter, is. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
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 unlike the others. These are related to human > relations: > > Acting as a conduit for confidential communication. > Making policy announcements. > Managing permissions for commits, infrastructure, etc. > Handling disciplinary issues. > Making difficult decisions when consensus is lacking. > > while this one is highly technical: > Coordinating release activities. Quite so. Deciding "it's time for a release" requires the same knowledge and skills as deciding "it's time to commit patch P", yet we have a special-case decision procedure. A release does require people acting in concert for a span of a few days, but that precise scheduling is work for an administrative assistant, not work befitting -core. > It seems that only this last one is where most people seem to have a > problem. I wonder if it makes sense to create a separate group that > handles release activites -- the "release team." I think the decision to initiate or revoke release scheduling belongs in the same forum as patch development, usually -hackers or -security. We'd need to pick a way to clearly signal the discussion's conclusion, analogous to how a pushed commit unambiguously disposes a patch proposal. The balance of coordinating release activities is mechanical, and -packagers seems adequate for it.
On 12 June 2015 at 06:48, Noah Misch <noah@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 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 confidential communication.
> Making policy announcements.
> Managing permissions for commits, infrastructure, etc.
> Handling disciplinary issues.
> Making difficult decisions when consensus is lacking.
>
> while this one is highly technical:
> Coordinating release activities.
Quite so. Deciding "it's time for a release" requires the same knowledge and
skills as deciding "it's time to commit patch P", yet we have a special-case
decision procedure. A release does require people acting in concert for a
span of a few days, but that precise scheduling is work for an administrative
assistant, not work befitting -core.
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.
> It seems that only this last one is where most people seem to have a
> problem. I wonder if it makes sense to create a separate group that
> handles release activites -- the "release team."
I think the decision to initiate or revoke release scheduling belongs in the
same forum as patch development, usually -hackers or -security. We'd need to
pick a way to clearly signal the discussion's conclusion, analogous to how a
pushed commit unambiguously disposes a patch proposal. The balance of
coordinating release activities is mechanical, and -packagers seems adequate
for it.
Packagers should be about "HOW do we make the next release", which is separate from the above.
Ultimately, "How" effects "When", but "When is it needed?" is an earlier thought.
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
<div dir="ltr">+1 <br /><div class="gmail_extra"><br /><div class="gmail_quote">On Thu, Jun 11, 2015 at 5:12 PM, Robert Haas<span dir="ltr"><<a href="mailto:robertmhaas@gmail.com" target="_blank">robertmhaas@gmail.com</a>></span> wrote:<br/><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue,Jun 9, 2015 at 6:35 PM, Bruce Momjian <<a href="mailto:bruce@momjian.us">bruce@momjian.us</a>> wrote:<br /> >There has been some confusion by old and new community members about the<br /> > purpose of the core team, and thislack of understanding has caused some<br /> > avoidable problems. Therefore, the core team has written a core charter<br/> > and published it on our website:<br /> ><br /> > <a href="http://www.postgresql.org/developer/core/"rel="noreferrer" target="_blank">http://www.postgresql.org/developer/core/</a><br/> ><br /> > Hopefully this will be helpful to people.<br/><br /> I believe the core team is suffering from a lack of members who are<br /> involved in writing, reviewing,and committing patches. Those things<br /> are not core functions of the core team, as that charter illustrates.<br/> However, the core team needs to know when it should initiate a<br /> release, and to do that it needs tounderstand the impact of bugs that<br /> have been fixed and bugs that have not been fixed. The recent<br /> discussionof multixacts seems to indicate that the number of core<br /> team members who had a clear understanding of theissues was zero,<br /> which I view as unfortunate. The core team also needs to make good<br /> decisions about who shouldbe made a committer, and the people who are<br /> doing reviews and commits of other people's patches are in the best<br/> position to have an informed opinion on that topic.<br /><br /> As a non-core team member, I find it quite frustratingthat getting a<br /> release triggered requires emailing a closed mailing list. I am not a<br /> party to allof the discussion on my request, and the other people who<br /> might know whether my request is technically sound ornot are not<br /> party to that discussion either. I disagreed with the decision to<br /> stamp 9.4.3 without waitingfor<br /> b6a3444fa63519a0192447b8f9a332dddc66018f, but of course I couldn't<br /> comment on it, because it was decidedin a forum in which I don't get<br /> to participate, on a thread on which I was not copied. I realize<br /> that,because decisions about whether to release and when to release<br /> often touch on security issues, not all of thisdiscussion can be<br /> carried on in public. But when the cone of secrecy is drawn in so<br /> tightly that excludeseveryone who actually understands the technical<br /> issues related to the proposed release, we have lost our way,and do<br /> our users a disservice.<br /><br /> I am not sure whether the solution to this problem is to add more<br/> people to the core team, or whether the solution is to move release<br /> timing decisions and committer selectionout of the core team to some<br /> newly-created group. But I believe that change is needed.<br /><span class="HOEnZb"><fontcolor="#888888"><br /> --<br /> Robert Haas<br /> EnterpriseDB: <a href="http://www.enterprisedb.com"rel="noreferrer" target="_blank">http://www.enterprisedb.com</a><br /> The Enterprise PostgreSQLCompany<br /><br /><br /> --<br /> Sent via pgsql-hackers mailing list (<a href="mailto:pgsql-hackers@postgresql.org">pgsql-hackers@postgresql.org</a>)<br/> To make changes to your subscription:<br/><a href="http://www.postgresql.org/mailpref/pgsql-hackers" rel="noreferrer" target="_blank">http://www.postgresql.org/mailpref/pgsql-hackers</a><br/></font></span></blockquote></div><br /></div></div>
On Fri, Jun 12, 2015 at 1:21 AM, Simon Riggs <simon@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 members have sometimes taken the position that this is already so; that releases should be discussed on pgsql-hackers and pgsql-security as appropriate to the driver. In theory, this may be fine, but in practice, it doesn't seem to be working very well right now. > Packagers should be about "HOW do we make the next release", which is > separate from the above. > > Ultimately, "How" effects "When", but "When is it needed?" is an earlier > thought. +1. Completely agreed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company