[python-committers] CI problem on old pull request

[Xiang Zhang]

I have just encountered a problem in PR1958. The appveyor CI prevents me from 
merging it. I can't see no way to disabling it or rerunning it, no details 
link. And is it possible to apply our new CIs, like vsts to it now?

Regards
Xiang Zhang
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] CI problem on old pull request

[Victor Stinner]

Hi,

It happened sometimes to me one month ago, but then it was fine. The
workaround is to close/reopen the PR. The best way is to use AppVeyor
UI, but here there was no AppVeyor link from the PR.

Close/Reopen worked: AppVeyor is now running.
https://ci.appveyor.com/project/python/cpython/build/3.8build17701

2018-06-15 10:15 GMT+02:00 Xiang Zhang :
> And is it possible to apply our new CIs, like vsts to it now?

VSTS is not perfect neither :-) See for example
https://bugs.python.org/issue33782

Victor
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Vote to promote Pablo Salingo Salgado as core developer

[Serhiy Storchaka]

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:
https://github.com/python/cpython/commit/2c15b29aea5d6b9c61aa42d2c24a07ff1edb4b46

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.


___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] CI problem on old pull request

[Xiang Zhang]

Thanks. It's working as expected now. :-)




On 06/15/2018 16:59, Victor Stinner wrote:
Hi,

It happened sometimes to me one month ago, but then it was fine. The
workaround is to close/reopen the PR. The best way is to use AppVeyor
UI, but here there was no AppVeyor link from the PR.

Close/Reopen worked: AppVeyor is now running.
https://ci.appveyor.com/project/python/cpython/build/3.8build17701

2018-06-15 10:15 GMT+02:00 Xiang Zhang :
> And is it possible to apply our new CIs, like vsts to it now?

VSTS is not perfect neither :-) See for example
https://bugs.python.org/issue33782

Victor
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Vote to promote Pablo Salingo Salgado as core developer

[Serhiy Storchaka]

15.06.18 05:05, Nathaniel Smith пише:

On Thu, Jun 14, 2018 at 4:40 AM, Berker Peksağ  wrote:

This isn't about my or someone else's high standards. We keep saying
we need more triagers and reviewers, and we keep promoting people who
didn't do any issue triaging and code review. It's not fair to
contributors who have spent so much time working on these areas.

Surely the solution is to promote more people who do those things, not
to turn away people making other contributions? We need more
contributors of all kinds.


It is not necessary to be a core developer for been a productive 
contributor. You only need to be a core developer for doing a work that 
can be made only by a core developer. This is mainly merging your own 
and others PRs after a thorough reviewing.


___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] How to Increase Triage and Code Review Activity? (was: Vote to promote Pablo Salingo Salgado as core developer)

[Eric Snow]

On Thu, Jun 14, 2018 at 8:06 PM Nathaniel Smith  wrote:
> On Thu, Jun 14, 2018 at 4:40 AM, Berker Peksağ  
> wrote:
> > This isn't about my or someone else's high standards. We keep saying
> > we need more triagers and reviewers, and we keep promoting people who
> > didn't do any issue triaging and code review. It's not fair to
> > contributors who have spent so much time working on these areas.

Just to be clear, Berker, I really appreciate the time folks
(including you) put into the more thankless (and often tedious) tasks
like bug triage and code review (and triaging buildbot failures).  I
for one need to spend more of my open-source time on that.  No one
should ever feel like they have to do more than their fair share.

> Surely the solution is to promote more people who do those things, not
> to turn away people making other contributions? We need more
> contributors of all kinds.

I agree completely.  However, Berker's concern is a real (and honest)
one, regardless of its bearing on accepting new core developers.  It
also reflects a real, continuing problem: a shortage of folks doing
bug triage/curation and code review.  Unfortunately, this has a chain
reaction effect by discouraging people from pursuing more involvement
in core development.  For instance, if someone creates a PR but it
sits there for a year they eventually give up.  On the other hand,
sometimes aspiring core contributors question the value of giving a PR
a review if a core committer is going to review it themself before
possibly merging.  (I realize there are good reasons for any code
review, but that is the reaction I've gotten from people on occasion.)

The consequent question is how to get more people resolving open
tracker issues and giving PR reviews?  Off-hand, I'm not sure. :/
We've discussed this before and it's probably time to discuss it
again.  Any ideas?

-eric
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Missing In Action

[Victor Stinner]

Hi,

Last months, we debated about the number of *active* core developers.

The problem is that there are 3 lists and each has different numbers
of core developers: 90 according to GitHub, 170 according to
bugs.python.org.

* https://github.com/orgs/python/teams/python-core/members
* 
https://bugs.python.org/user?iscommitter=1&@action=search&@sort=username&@pagesize=300
* https://devguide.python.org/developers/

I propose to move inactive core developers to a new list (ex:
"Inactive Core Developers") and remove their permission for security
reasons. If the core developer shows up, they will just have to ask a
GitHub administrator (like Brett Cannon) to be added again.

My intent is to enhance security and better track of the current
number of active core developers.

In practice, it should only mean removing these inactive developers
from the list of core developers on bugs.python.org. To make sure that
a developer can become again a core developer, we should track that we
dropped their priviledge. We can add new section in the devguide,
near:
https://devguide.python.org/developers/#permissions-dropped-on-request

There are already two lists of inactive core developers in the
devguide: "Permissions Dropped on Request" and "Permissions Dropped
after Loss of Contact".

I propose to start by removing all core developers who didn't migrate
to GitHub yet, since it's a simple way to check if they are active
since February 2017.

I can work on a concrete list of developers, but it seems like it will
take me some time. Some developers are cores according to
bugs.python.org but I cannot find them in the devguide list. Some
developers are no longer core devs according to devguide, but still
core in bugs.python.org. There are some inconsistencies.

Victor
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Missing In Action

[Victor Stinner]

"Missing In Action"

Oh. After I sent my email, I checked the translation of "Missing In
Action". It means more or less "lost", but it seems to be commonly
associated to war:

https://en.wikipedia.org/wiki/Missing_in_action
"a casualty classification assigned to combatants, military chaplains,
combat medics, and prisoners of war who are reported missing during
wartime or ceasefire"

I don't recall where I heard the expression, but I didn't mean that
inactive developers are dead :-) I'm quite sure that there is life
after Python. Right?

Victor
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Maintenance Tasks

[Victor Stinner]

Hi,

At FOSDEM (last February), I saw an interesting talk by VM (Vicky) Brasseur:
"Passing the Baton: Succession planning for FOSS leadership"

She explains that the maintenance of a project should be splited into
small tasks, and that each task should be done by at least two people.
Why at least two, and not only one? Well, sometimes you may want to
take holiday, one of your family member may become sick, or maybe you
are simply bored and wants to do something else. You may have heard
about the "bus factor", but I dislike this name because it sounds like
a very unlikely event, whereas people leaving for whatever reason is
common.

It's also about documenting what you are doing to be able to pass the
task to someone else. What should be documented? Well, here is where
the second player matters: document enough until someone else is
autonomous on the task.

What are Python maintenance tasks? I identified the following tasks:
http://pythondev.readthedocs.io/maintenance_tasks.html

Copy of my list:

* `Review and merge pull requests
`_. The merge action is
restricted to core developers.
  Maintainers: active core developers (June 2018: around 34 core devs).
* `Bug triage `_: closing a bug requires the
bug triage
  permission. Maintainers: active core developers.
* `Check for buildbot failures
  `_:
  Read logs of each buildbot failure, check if the failure is known. If the
  failure is known, maybe mention the new failure in the existing bug.
  Otherwise, open a new bug. Then reply to the email with a link to the bug.
  Maintainers: Victor Stinner, Pablo Salingo Salgado.
* Run bugs.python.org: fix bugs, deploy new version. See the
  `meta bug tracker `_ for bugs
  of bugs.python.org itself (not for Python bugs). Roundup is going to be
  deployed in a Docker container on OpenShift. Maintainers:
  Ezio Melotti, Brett Cannon, Maciej Szulik.
* `Run pythontest.net `_. Maintainers: ?
* Run GitHub bots. Maintainers: Brett Cannon and Mariatta Wijaya.
* Update vendored external libraries. Maintainers: ?
* Update unicodedata on new Unicode release. Latest update (Unicode 11.0):
  https://bugs.python.org/issue33778. Maintainer: Benajamin Peterson.

I likely forget many tasks, since "maintenance" is a large topic and
there are some tasks that are only be done rarely (like releases?).


By the way, I also started to list known administrators. Some actions
require administrators who are the only ones allowed to do actions.

* Mailing lists: create a new mailing list. Maintainer: "postmaster" (who is
  the current postmaster?).
* Bug tracker: give "bug triage permission". Administrators: Ezio Melotti,
  Ned Deily(?), R. David Murray.
* GitHub cpython: add new core developers. Administrators: Brett Cannon,
  Ned Deily, others(?).


I chose to start discussing maintenance tasks with core developers
only (python-committers mailing list) since many tasks are reserved to
(or at least currently done by) core developers. And I'm not sure that
the concept of "maintenance tasks" makes sense, so I prefer to start
discussing it with smaller audience :-)

Note: The talk title is "Passing the Baton: Succession planning for
FOSS leadership", but I don't ask here your BDFL to pass the baton ;-)
I'm talking about the rest of talk.

Victor
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Missing In Action

[Victor Stinner]

This idea also comes from Brett Cannon who proposed something similar:
https://mail.python.org/pipermail/python-committers/2018-June/005526.html

Victor

2018-06-16 1:59 GMT+02:00 Victor Stinner :
> Hi,
>
> Last months, we debated about the number of *active* core developers.
>
> The problem is that there are 3 lists and each has different numbers
> of core developers: 90 according to GitHub, 170 according to
> bugs.python.org.
>
> * https://github.com/orgs/python/teams/python-core/members
> * 
> https://bugs.python.org/user?iscommitter=1&@action=search&@sort=username&@pagesize=300
> * https://devguide.python.org/developers/
>
> I propose to move inactive core developers to a new list (ex:
> "Inactive Core Developers") and remove their permission for security
> reasons. If the core developer shows up, they will just have to ask a
> GitHub administrator (like Brett Cannon) to be added again.
>
> My intent is to enhance security and better track of the current
> number of active core developers.
>
> In practice, it should only mean removing these inactive developers
> from the list of core developers on bugs.python.org. To make sure that
> a developer can become again a core developer, we should track that we
> dropped their priviledge. We can add new section in the devguide,
> near:
> https://devguide.python.org/developers/#permissions-dropped-on-request
>
> There are already two lists of inactive core developers in the
> devguide: "Permissions Dropped on Request" and "Permissions Dropped
> after Loss of Contact".
>
> I propose to start by removing all core developers who didn't migrate
> to GitHub yet, since it's a simple way to check if they are active
> since February 2017.
>
> I can work on a concrete list of developers, but it seems like it will
> take me some time. Some developers are cores according to
> bugs.python.org but I cannot find them in the devguide list. Some
> developers are no longer core devs according to devguide, but still
> core in bugs.python.org. There are some inconsistencies.
>
> Victor
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Maintenance Tasks

[Victor Stinner]

> At FOSDEM (last February), I saw an interesting talk by VM (Vicky) Brasseur:
> "Passing the Baton: Succession planning for FOSS leadership"

Sorry, I forgot the link to the video and slides:
https://fosdem.org/2018/schedule/event/community_passing_the_batton_foss_leadership/

Victor
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Missing In Action

[Serhiy Storchaka]

16.06.18 03:03, Victor Stinner пише:


Oh. After I sent my email, I checked the translation of "Missing In
Action". It means more or less "lost", but it seems to be commonly
associated to war:


Good illustration of the loss in translation. :-)

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Missing In Action

[Serhiy Storchaka]

16.06.18 02:59, Victor Stinner пише:


The problem is that there are 3 lists and each has different numbers
of core developers: 90 according to GitHub, 170 according to
bugs.python.org.

* https://github.com/orgs/python/teams/python-core/members
* 
https://bugs.python.org/user?iscommitter=1&@action=search&@sort=username&@pagesize=300
* https://devguide.python.org/developers/


There is also a list of experts:

* https://devguide.python.org/experts/

It contains not only core developers, but third-party experts. Some 
names are flagged with "(inactive)" or a star.


___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/