Re: The purpose of the core team

On Thu, Jun 11, 2015 at 12:29 PM, Joshua D. Drake <jd(at)commandprompt(dot)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