13.06.18 23:46, Victor Stinner пише:
It's not like Pablo proposed the idea himself and force to get this
feature merged. Pablo just implemented an idea proposed by two other
core developers.

It looks like Pablo implements ideas for which he does not fully understand the consequences and the drawbacks. Well, his skills are not bad, but we don't need more half-baken features in the stdlib, it is better to have less but more qualitative features that fit well with the rest of the stdlib.

I don't see anything wrong here. It's not uncommon that a newly merged
feature is still discussed, and I don't see anything wrong with
Pablo's behaviour here. I don't see how we could prevent such further
discussions on posix_spawn(). At least, I don't see how Pablo could
prevent these issues.

My point was that if you count the number of merged PRs, you should exclude reverted and unfinished works.

At the end, I really like the final commit:

It adds a new rounding mode (_PyTime_ROUND_UP), write a non-trivial
function test for negative timeout, has a good NEWS entry, etc.

Pablo showed that he is able to implement large change and fix all
cases, not a single case. IMHO it's a good example, rather than a bad
example :-)

It is just that more than a half of this work was made by you.

Many of other PRs are documentation fixes.
Is it an issue?

No, but these PRs are much easier. And some of them just add the documentation for features added in other PRs and should not be count separately.

I think Pablo will be good core developer and agree with the description
given by Victor. But it seems that he still needs to learn something about
what changes are good for Python.
Ok, I account your -1 vote.

Actually just -0. After dropping reverted PRs I have no enough information still for having a strong opinion. But I have no strong objections if you hold on to him.

In private, I told Pablo that I consider that the main
difference between a core developer and a contributor is that core
developers are expected to spend more time on reviews and mentoring.

The main difference is that the core developer constantly make decisions about his own and foreign patches. It is responsible for quality of merged code.

IMHO the purpose of adding a new core developer is reducing the burden for other core developers. He/she can take a part of the work, make qualified reviews and merge PRs without involving attention of BDFL or other core developers. For now, Pablo's PRs add the work for core developers.