[python-committers] Triage perms for Elvis

[R. David Murray]

At Yuri's request I've given Elvis triage privileges on the tracker.
I don't anticipate any objections, given the work he's done on
What's New and other things.

--David
___
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] 3.7.0b1 status

[R. David Murray]

On Wed, 31 Jan 2018 03:17:47 -0500, Ned Deily  wrote:
> in not more than 24 hours from now.  If you wish, feel free to merge
> new commits into the master branch for release in 3.8, with the
> understanding that any also destined for 3.7.0 will need to be
> cherrypicked after the 3.7 branch is available.  Other branches (3.6,
> 2.7) are unaffected.

Hmm.  I merge something and put on the backport 3.6 label and just
merged that...and I have no idea if the 3.7 merge was before or
after the b1 cutoff.  Is there some way to get git to tell us which
commits are possible candidates for cherry picking after the branch
is created so that we don't miss any?  Otherwise I fear we may
end up with some bug fixes that get in to 3.8 and 3.6 but not 3.7.

--David
___
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] Security: please enable 2-factor authentication on GitHub and your email

[R. David Murray]

On Mon, 11 Dec 2017 14:56:21 -0500, Donald Stufft  wrote:
> 
> > On Dec 11, 2017, at 2:52 PM, R. David Murray  wrote:
> > 
> > If 2fa is required for contribution to CPython, I'll stop
> > contributing. 
> 
> I’m curious why? I have it on and 99% of the time you don’t even
> notice because you’re already logged into GitHub and pushes/pulls
> don’t require it.

I had to use 2FA when working for a corporate client, and it was
very annoying.  The fact that pushes and pulls don't require it
helps, but also makes it considerably less important.

But I suppose that fundamentally I do not want my security tied to a
possession.

--David
___
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] Security: please enable 2-factor authentication on GitHub and your email

[R. David Murray]

On Mon, 11 Dec 2017 14:52:54 -0500, "R. David Murray"  
wrote:
> Indeed.  If 2fa is required for contribution to CPython, I'll stop
> contributing.  Granted, I haven't done many merges lately, but a few
> is a bigger number than zero :)

And in case you think this means I don't consider security important:
I have been using strong, unique-per-site passwords (and in many cases
unique usernames/emails) for many years, and I run my own email server.

--David

Aside: something I have never understood is the relatively recent
craze for enter-username-first-then-go-to-password-screen.  Most of the
implementations I have encountered tell you if the username is unknown.
That reduces the cracker's search space by a considerable amount.  Using
your email address as the account id has the same problem, magnified.
I had already started using unique usernames/emails before that trend
happened, to battle spam, but it certainly reinforced my motivation for
doing so.  I unfortunately haven't gotten around to backfilling a lot
of the sites I did sign up to using my primary email address :(
___
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] Security: please enable 2-factor authentication on GitHub and your email

[R. David Murray]

On Mon, 11 Dec 2017 18:14:41 +, Paul Moore  wrote:
> On 11 December 2017 at 18:03, Donald Stufft  wrote:
> > So yea, it’s not as good as 2FA only everywhere, but the specific
> > circumstances around these specific credentials makes it a reasonable
> > usability trade off to allow them.
> 
> Cool. Security is always a usability vs security trade-off, and the
> main thing here is not to push the balance too far - we need to
> consider the potential issue of putting people off from contributing
> as well as the risk of security compromises. (Open source is a hobby
> activity for me - when it starts to feel too much like the day job, I
> start getting twitchy :-))

Indeed.  If 2fa is required for contribution to CPython, I'll stop
contributing.  Granted, I haven't done many merges lately, but a few
is a bigger number than zero :)

--David
___
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] Mentoring Julien Palard (core), Cheryl Sabella (bug) and Sanyam Khurana (bug)

[R. David Murray]

On Sat, 09 Dec 2017 14:12:52 +0100, Victor Stinner  
wrote:
> I asked them to ask me to double check before merging a pull request
> (Julien) or closing a bug (Cheryl and Sanyam).

When I have promoted people to triage in the past I have not had them
check with me before making changes, but instead simply encouraged them
to ask me questions if they had doubts.  I base this on the advice I
was given my Martin von Loewis when he gave me triage privileges however
many years ago it was.  He said (paraphrased) "Don't be afraid to use
this power.  It is worse to to be tentative and not do the work than it
is to do the work and make mistakes.  All tracker changes are reversible,
so don't be afraid to make changes."

The point is, in Martin's judgement (and I have had no reason to doubt
it in the years that have followed) is that it is a far more common
problem for newly promoted people to be afraid to screw up than it is
for someone to go rogue and not listen when communicated with.  In my
experience the latter has happened only once, and we have a lot of
people with triage privileges.

--David
___
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] Official python-dev docker images

[R. David Murray]

On Thu, 07 Dec 2017 13:00:31 -0500, Barry Warsaw  wrote:
> Brett and I want to promote this more widely within the Python
> community as the “official Python Docker image” that projects can use
> in their own testing environments, or base their own images on it.  We
> wanted to give you guys a heads up first to get your feedback, and
> maybe thoughts on the best places to promote this, e.g. on the
> python.org website or other places.

Well, the place to get a python Docker image listed would be
https://hub.docker.com/_/python/.  That's the first google hit for python
docker, and it already has a host of images available.  How does yours
differ from those?  It sounds like it is by having multiple versions
and tox so you can test your library/ap against multiple Python
versions using a single container.  That does sound useful :)

But, be careful with names.  "official Python Docker image" sounds like
what one would use when one wants to *run* a python application in a docker
container, which is what the images that are currently listed on the
page mentioned above seem directed at.

--David
___
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] Requirements to get the "bug triage" permission?

[R. David Murray]

On Wed, 06 Dec 2017 18:11:44 +0100, Victor Stinner  
wrote:
> Ok, thanks Ezio and David. I completed my list:
> https://github.com/vstinner/cpython_core_tutorial/blob/master/core_developer.rst#bug-tracker

s/loose/lose/

I would say your list comprises the skills for the "ideal triager" rather
than "good triager", since I think someone can be a good triager without
being and expert in a *all* of the skills you list in that section.
I would expect a triager to develop facility with all those skills,
but not necessarily to have them before they get granted privileges.
(I'd say the second, fourth, fifth, and last are more or less
the minimum to start with, although I'd drop the "which files should
be updated to fix the issue" for that minimum set.)

> My initial question is to know if bug triage permission can be seen as
> a first "award" / "badge" to recognize that contributions of someone
> are useful. Contributions can only be made of code pull requests, or
> another "project" tightly coupled to CPython like the documentation,
> the development workflow, etc.
> 
> My problem is now that the list of requirements is very long. It's
> like you should already practice triage for weeks before being seen as
> ready to get the triage power.
> 
> So do you think that it's bad idea to use triage as an award? Or is it
> just a matter of adjusting requirements?

Yes I think it is a bad idea to "use it" as an award.  It is not an
award, it is a functional set of privileges.  It *can be* part of the
on-boarding process for a contributor who eventually becomes a core dev,
though, and in that path it functions as an award of sorts.

> I have a few people in mind that I would like to give them triage
> permission, but I don't know that they contributed much to the bug
> tracker. I don't expect them to be active on the bug tracker neither.

It they are not going to be active on the bug tracker, why do you want
to give them triage permissions?  If they haven't been active at least
a little bit on the bug tracker, how do you know they are good candidate
to be a triager?

What do they need the privileges for?  I'm not necessarily saying they
shouldn't get them, I want to explore the why in order to inform this
discussion.  But, if you just want to give it to them as an award and
for no other reason, I'd vote no.  If you want a badge to give them,
maybe we make up a badge ;)

--David
___
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] Adding Ivan Levkivskyi as a core committer

[R. David Murray]

On Wed, 06 Dec 2017 08:43:56 -0800, Guido van Rossum  wrote:
> I think I figured it out -- I invited him to the python org on GitHub.
> Anything else?

He needs to subscribe to this mailing list, and the developers.rst in
the devguide repo should get an update.

That's all I can think of, since ssh keys are now handled by github,
but if there are other github things that need done I might not know
them ;)

Ah, it's all (or should be) in coredev.rst.  I don't see anything else
that needs done, though he should read that doc.

--David
___
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] Requirements to get the "bug triage" permission?

[R. David Murray]

On Mon, 20 Nov 2017 18:54:50 +0100, Victor Stinner  
wrote:
> I identified some active contributors and I would like to offer them
> to get the "bug triage" permission. What's the requirements to give
> such permissions to someone?

Currently it is "someone with the power to do it decides to give it out".
Should we have more detailed/conscious requirements?  Perhaps so.

> IMHO the requirements are quite low:
> 
> * at least one commit merged in Python
> * signed the CLA

I have never looked for either of these when giving out triage.  I can
see that having signed the CLA is probably a good idea, but I see no
reason to have getting a patch merged be a requirement.

> * be nice and respectful
> * don't close a bug if it's not well understood to not "loose"
> information (closed bugs are ignored in search by default, and hidden
> from the main page).

Personally my criteria is heavy on "be nice and respectful", coupled
with observing that they have posted comments on issue that demonstrate
an understanding of our code culture...specifically, commenting that a bug
should be closed (and why) and I agree with them, and demonstrating an
understanding of what python versions a bug applies to (enhancement
versus bug fix, when to backport a bug fix and when not).

How it generally works for me is that I think, "this person knows
what they are talking about, they ought to be able to close this issue
themselves instead of my having to do it for them".  Then I pull up a
list of all the issues they are nosy on, and look at their comments to
see if they are consistently polite and respectful, know what they are
talking about, and explain their reasoning well.  If I don't see any
red flags, I give them triage.

> Did it happen in the past that we removed the bug triage permission to
> someone who abused this power?

Only once that I'm aware of.

> Maybe we can give some guide lines on how to behave on the bug tracker?

Enhance the bug triage section of the devguide, by all means :)

--David
___
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] Enabling depreciation warnings feature code cutoff

[R. David Murray]

On Mon, 06 Nov 2017 13:25:09 -0600, Neil Schemenauer  
wrote:
> On 2017-11-06, R. David Murray wrote:
> > I'm curious which ones you are seeing it in?  It could be we are
> > operating in different problem spaces :)
> 
> In the last few months: Pillow, docutils, dateutil.  Some of them
> could have been PendingDeprecationWarning, I'm not sure.  I had that
> enabled as well.  So, maybe the warnings would have been fixed once
> they became DeprecationWarning.  The fact that unittest enables the
> warnings should help a lot.

We're using at Pillow and dateutil without seeing any warnings
(without Pending on), so I suspect your speculation is correct.

--David
___
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] Enabling depreciation warnings feature code cutoff

[R. David Murray]

On Mon, 06 Nov 2017 12:51:45 -0600, Neil Schemenauer  
wrote:
> Another idea is to have venv to turn them on by default or, based on
> a command-line option, do it.  Or, maybe the unit testing frameworks
> should turn on the warnings when they run.

Unit test frameworks, including at least unittest, do.

> The current "disabled by default" behavior is obviously not working
> very well.  I had them turned on for a while and found quite a
> number of warnings in what are otherwise high-quality Python
> packages.  Obviously the vast majority of developers don't have them
> turned on.

It's working great for me.  I've only run into warnings in one package,
and I wouldn't call that one high quality.  And we use a lot of packages
in our current project.

I'm curious which ones you are seeing it in?  It could be we are
operating in different problem spaces :)

--David
___
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] [Python-Dev] Reminder: 12 weeks to 3.7 feature code cutoff

[R. David Murray]

On Mon, 06 Nov 2017 11:46:48 +1000, Nick Coghlan  wrote:
> On 6 November 2017 at 02:02, Yury Selivanov  wrote:
> > On Fri, Nov 3, 2017 at 11:30 PM, Nick Coghlan  wrote:
> >> The current lack of DeprecationWarnings in 3.6 is a fairly major
> >> oversight/bug, though:
> >
> > There's no oversight.  We had PendingDeprecationWarning for
> > async/await names in 3.5, and DeprecationWarning in 3.6.  You just
> > need to enable warnings to see them:
> 
> Gah, seven years on from Python 2.7's release, I still get caught by
> that. I'm tempted to propose we reverse that decision and go back to
> enabling them by default :P
> 
> If app devs don't want their users seeing deprecation warnings, they
> can silence them globally during app startup, and end users can do the
> same in PYTHONSTARTUP for their interactive sessions.

I'm glad you are only tempted and have not actually proposed it :)

--David
___
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] Requesting reviews

[R. David Murray]

On Fri, 06 Oct 2017 09:09:01 -0700, Mariatta Wijaya  
wrote:
> The windows team is notified because the PR includes changes to PCBuild/*

If you get a review request that says your review was requested "as a
code owner", then it was an auto-request, it wasn't actually requested
by the person named in the message (which I agree is confusing).

You can look through the diff to check for changes to PC, PCBuild, msi,
or nuget to see if there are windows changes you do want to review.
The config for the auto-review-requests is in .github/CODEOWNERS; the
current windows team entries are:

# Windows
/PC/  @python/windows-team
/PCBuild/ @python/windows-team

# Windows installer packages
/Tools/msi/   @python/windows-team
/Tools/nuget/ @python/windows-team
___
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] Minor followup to the pynvm discussion

[R. David Murray]

A link to a possibly-interesting-in-this-context project was just posted
to the pmem mailing list:

https://arrow.apache.org/

This is a standard for communicating data structures between processes
with zero-copy semantics, and is backed by the person who created Python
Pandas.  I thought Davin in particular might find this interesting if
he isn't already aware of it.

--David
___
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] I just gave Gareth Rees traige privileges on the tracker

[R. David Murray]

I haven't actually heard back from him yet since I just emailed him,
but I've never had anyone turn down triage privs :)

The trigger was that I closed two issues this week that he comment on
that it would have been nice if he had been able to just close himself.
I've looked at some of his other tracker contributions as well, and they
look to be of high quality.  He hasn't made a huge number of contributions
on the tracker, so I'm hoping this will encourage him to continue to be
more active ;)

I wasn't sure if a note like this would be considered noise on this list,
but Victor told me in IRC that it helps him notice people, so I agreed
I should post here.

--David
___
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] Dismiss review if a PR is modified

[R. David Murray]

On Tue, 18 Jul 2017 23:13:41 -, Brett Cannon  wrote:
> Do realize that setting is part of requiring a review for pull requests:
> https://help.github.com/articles/enabling-required-reviews-for-pull-requests/.
> So in order to get this we would require all PRs, core dev or not, to
> receive an approving review from another core developer (I don't think an
> approving review from just anyone counts towards the minimum approval).
> There might be around this, but it will require some testing to make sure
> (see
> https://github.com/python/core-workflow/issues/94#issuecomment-316224864).

Ah, I thought we were already doing that, but of course we aren't.
Nevermind :)

--David
___
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] My (positive) feedback on the new CPython workflow

[R. David Murray]

On Tue, 18 Jul 2017 12:24:13 +0200, Victor Stinner  
wrote:
> I'm just not unconfortable with the fact that an approval is kept even
> if the PR is modified after the review :-/ I would expect a list a
> notice "changed modified after the review" or something like that. At
> least, for my own reviews, to remind me to review again.

This could be changed if we have consensus to do so.  Github has a
setting that will cause existing approvals to be "dismissed" if
a new commit is pushed.

> Compared to Rietveld, GitHub review tool is as "a good" (not much
> better, not much worse). Sometimes, I'm lost in reviews: my comments
> are hidden, I have to unfold many widgets. But it's not that bad. It
> seems like avoiding rebase works around some of these issues.

I much prefer rietveld over github reviews, but I also much prefer the
integration between the bug tracker and github over the minimal
integration we had for rietveld.  Thanks to all the people who made
that happen, and especially Brett for leading it.

--David
___
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] link from github to bpo?

[R. David Murray]

On Sat, 24 Jun 2017 00:33:13 -, Brett Cannon  wrote:
> On Fri, 23 Jun 2017 at 09:28 R. David Murray  wrote:
> 
> > On Wed, 21 Jun 2017 13:37:22 -0700, Mariatta Wijaya <
> > mariatta.wij...@gmail.com> wrote:
> > > PR 2304 is merged. "View Details" still exists (scroll all the way down).
> > >
> > > When the PR is not yet merged (e.g.
> > > https://github.com/python/cpython/pull/2316), the UI looks different.
> > > Click 'Show all checks' to get the link back to bpo.
> >
> > Odd, I don't see a 'show all checks' on that PR.  And I usually have to
> > click 'show all checks' on open PRs (at least if the checks have all
> > passed) in order to get to the bedevere link.
> >
> 
> Go to the entry representing Larry's merge and click on the "View details"
> button. That will expand to show all of the status checks that were done
> when the PR was merged (in this instance there was no issue number so you
> won't see a "Details" link for the bedevere/issue-number check).

Ah, thank you, now I understand.  Obviously, this was not..obvious :)

--David
___
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] link from github to bpo?

[R. David Murray]

On Wed, 21 Jun 2017 13:37:22 -0700, Mariatta Wijaya  
wrote:
> PR 2304 is merged. "View Details" still exists (scroll all the way down).
> 
> When the PR is not yet merged (e.g.
> https://github.com/python/cpython/pull/2316), the UI looks different.
> Click 'Show all checks' to get the link back to bpo.

Odd, I don't see a 'show all checks' on that PR.  And I usually have to
click 'show all checks' on open PRs (at least if the checks have all
passed) in order to get to the bedevere link.

--David
___
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] link from github to bpo?

[R. David Murray]

On Wed, 21 Jun 2017 10:02:58 -0700, Mariatta Wijaya  
wrote:
> Yes, for that PR, scroll down and click the "View Details" button.
> Click the Details link next to bedevere/issue number status check.
> It will take you to the issue in bpo.

Note that this will only exist if the PR is still open (not closed, not
merged).

> There is also an open issue in bedevere, where the link will be added at
> the bottom of the PR message.
> https://github.com/python/bedevere/issues/3 (I believe Brett is working on
> it :)  )

And this should fix the problem mentioned above :)

--David
___
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] Revert changes which break too many buildbots

[R. David Murray]

On Thu, 15 Jun 2017 13:31:39 +1000, Nick Coghlan  wrote:
> On 15 June 2017 at 00:40, Victor Stinner  wrote:
> > So I would like to set a new rule: if I'm unable to fix buildbots
> > failures caused by a recent change quickly (say, in less than 2
> > hours), I propose to revert the change.
> 
> I'm not necessarily opposed to such a policy change, but if folks
> really want guaranteed green post-merge buildbots for all platforms
> (rather than just guaranteed green for Linux & Windows, sometimes red
> for everything else), then I think a better place to focus effort
> would be in making it easier for us to test things across the full
> BuildBot fleet in pre-merge CI.

I've long thought that reversion should be the policy.

I'm all in favor of making it easier to run the custom builders on a PR,
of course, but I think the policy change is orthogonal to that.  It's not
like that change represents effort that would otherwise be devoted to
making using the custom build easier...Victor is putting out the effort
to monitor the buildbots already and clearly intends to continue to do
so regardless.  Being able to revert will make the job he has taken on
(thank you Victor!) easier.

--David
___
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] Proposing Carol Willing to become a core developer

[R. David Murray]

+1

--David
___
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] Feedback on the new CPython workflow

[R. David Murray]

On Wed, 17 May 2017 11:35:29 -0700, Mariatta Wijaya  
wrote:
> It's possible, but remember not all PRs have bpo-issue, eg those with
> trivial label.
> In that case, what should the backport branch be?
> So we might end up with two backport branch name patterns, eg
> `backport-bpo--` and `backport-sha1` for the trivial PRs ?

I don't think it is a problem for the bpo issue number to be missing if
there isn't one.  (I presume you meant 'backport-bpo--sha1` for the
BPO alternative.)  But how abut using the github PR number in that case?

--David
___
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] Github reviews are cannibalizing BPO

[R. David Murray]

On Thu, 04 May 2017 17:44:46 -, Brett Cannon  wrote:
> (And just so I can claim I stated this publicly at some point; our Roundup
> installation I think runs on Python 2.6 and Roundup itself has not been
> ported to Python 3, so I don't know what we want to do if Roundup doesn't
> make the switch by 2020.)

There is intent to port, and some movement, but the number of people
actively working on Roundup is small.  As in single digits small.  Of
one hand.

--David

PS: our roundup runs on 2.6 because that's what the host OS version
provides.  Roundup is planning to drop 2.6 support in the next release,
so we're going to have to deal with *that* *before* 2020 :)
___
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] Github reviews are cannibalizing BPO

[R. David Murray]

On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg"  wrote:
> On 02.05.2017 04:25, Nick Coghlan wrote:
> > On 2 May 2017 at 08:32, Christian Heimes  wrote:
> >> This brings me to my questions
> >>
> >> 1) Should we try to move discussion back to BPO or are we fine with
> >> having major decisions just in Github PRs?
> >>
> >> 2) How can we retain enough information on BPO to keep it useful as
> >> research database for past decisions?
> > 
> > It's OK to have the discussions on GitHub, but one of the
> > responsibilities of reviewers is to ensure that significant design
> > decisions are summarised on the related tracker issue for future
> > reference.
> 
> I don't think that's a good idea, since the core devs then
> have to check what's good discussion to have on Github PRs
> and what not.
> 
> IMO, it's much easier for everyone to just always point people
> to BPO for discussions and keep PRs reserved for code reviews.

I agree with Mark-Andre here.  It will take effort on our part to
make our culture be "discuss on BPO", but it will produce a much
superior history to what github PRs produce, so I think it is worth it.

--David
___
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] Regarding reviewing test cases written for tabnanny module

[R. David Murray]

On Mon, 10 Apr 2017 21:53:44 -0700, Guido van Rossum  wrote:
> - When the contributor makes multiple local commits without pushing to the
> PR, I recommend using --amend unless they have several commits that
> actually are logically distinct and relevant to the reviewer. (--amend is
> especially important when fixing lint bugs or typos).
> 
> - Please don't use --amend across pushes to the PR
> 
> - It's OK to just pull+rebase and then use git push -f, but honestly
> pull+merge is fine too
> 
> - When responding to a review please NEVER use commit --amend, that's where
> reviewing becomes painful

In the devguide PR addressing this issue, I suggested we just say that
one should never force push to the PR.  I can see that a force
push after a rebase *before* addressing review comments would be fine,
but maybe it would be better to prefer merge since we're going to
squash at the end anyway.

> - It's up to the reviewer who merges to rewrite the commit message: the
> reviewer usually has a much better sense for what info in the commit
> message will still be interesting a month or a year from now than the
> contributor. (Often just copying the original comment from the top of the
> PR is adequate.)

Some of our core committers need to learn to do this :)

--David
___
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] I have blocked Wes Turner from the Python org on GitHub

[R. David Murray]

On Sat, 01 Apr 2017 15:08:27 -0400, Alex Gaynor  wrote:
> I'll be another voice saying that the CoC isn't the right mechanism -- the
> CoC is for harassment and abuse (at least, most community's CoCs are, the
> Python one is pretty vague).
> 
> That said, I have no problem with the action taken, banning people who are
> extremely unproductive is a necessary step for open source communities, and
> one I think we are all extremely reticent to take, so much so that it got
> it's own chapter in the excellent book, Producing Open Source Software:
> http://producingoss.com/en/difficult-people.html

Add my voice to this set.  I agree especially with Alex's second
paragraph above, so I really appreciate Brett being willing to take
this on.

Regardless of whether or not Python's CoC technically covers this case
(I'm not going to argue that one way or another), as Alex observed:
in the world we currently live in that term has way to much freight
attached to be appropriate for the issue we have with Wes.  That's
sad, because it means it doesn't actually matter all that much what
the CoC actually *says* :(.

--David
___
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] 4 weeks with the new workflow: what needs changing?

[R. David Murray]

On Fri, 24 Mar 2017 14:29:13 +0100, Antoine Pitrou  wrote:
> 
> By the way, how do I fetch remote changes for a branch without pulling
> it into the working copy?  e.g. I'd like to do "git fetch origin 3.5" or
> "git fetch origin/3.5", but that doesn't seem to work...

"git fetch origin 3.5" seems to work fine for me.  Maybe I don't
understand what you are trying to do?

--David
___
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] 4 weeks with the new workflow: what needs changing?

[R. David Murray]

On Wed, 15 Mar 2017 22:56:33 -0400, Yury Selivanov  
wrote:
> It's not just long waiting times (although it's a huge factor), it's 
> that you have to create temporary branches for cherry-picks. With 
> scripts or without, it's a lot of bookkeeping. Also, interacting with a 
> console is still much more convenient than using web tools (at least for 
> me).

+100 :)

--David
___
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] 4 weeks with the new workflow: what needs changing?

[R. David Murray]

On Mon, 13 Mar 2017 12:48:30 -0400, Yury Selivanov  
wrote:
> Yesterday I was working on a few asyncio PRs and a bug in async/await.  
> All PRs required cherry-picking.  Again, I was spending significant 
> amount of time just creating branches/PRs for cherry-picking.  Again 
> waiting for CI checks (even thougn I always run the test suite before I 
> push).  In the end of the day, I was so frustrated and discouraged that 
> I just stopped working on CPython.

Branch management was always the most time consuming part of committing,
even under HG.  But github has clearly made it worse.  Personally I doubt
I'm going to do any backports if I'm required to go visit some web pages
to do it.  That doesn't matter much, since I don't have much time for
contribution and have done very few checkins in a good while (even before
the switch).  But Brett was hoping that github would make it *easier* to
get stuff merged, and from my perspective that is only true for doc fixes
(which, granted, is a help :), while making it harder for code fixes.

So, I think the backport-bot should probably be the top priority of
whoever has time to work on this (which, unfortunately, is not me :(

Being able to backport without going through the PR process would also
make sense to me (and I thought we were going to be able to do that),
but I'm not involved enough in the conversations to know the downsides
of that.

--David
___
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] 4 weeks with the new workflow: what needs changing?

[R. David Murray]

On Sun, 12 Mar 2017 11:37:21 -, Paul Moore  wrote:
> I don't have a problem with the new "PRs attached to this issue" field
> - that's of course important to have. But is there any way to not have
> them generate emails (probably on a per-user basis, as I'm sure
> there's people who appreciate emails when PRs are added)? I guess the
> other option is a client-side filter, but I'm not sure how easy it
> would be to do something like that.

Kind of telling that Nick asked for a "notify when PR created" feature,
and you are asking for it to be disabled :)  Yes, it would need to be
a per-user setting, and currently it is not (it is a global setting
in Roundup).

I'm sure upstream would accept a patch to add a per-user setting for
this (and other things!).  Since the nosy emails are generated by a
reactor (a code snippet specific to the tracker instance) it wouldn't
even *need* to go upstream, and wouldn't be all that hard to write,
I think.  I'm not volunteering, though, not enough time :(

Maybe with the new docker tracker-test-setup that Maciej and Ezio have
refined we'll be able to get more volunteers interested in working
on the tracker codebase.  When they are ready it could use a bit more
visibility (a posting to python-dev and one to core-mentorship, say).

--David
___
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] New ncoghlan-bpo-29537-NEWS branch?

[R. David Murray]

On Thu, 09 Mar 2017 18:32:13 +, Brett Cannon  wrote:
> On Thu, 9 Mar 2017 at 04:07 Nick Coghlan  wrote:
> 
> > On 9 March 2017 at 19:30, Victor Stinner  wrote:
> >
> > Do we need need a kind of sandbox repository for experiments?
> >
> >
> > Mine aren't experiments, they're temporary branches from using the online
> > editor for minor fixups (GitHub doesn't give you the option to put those in
> > your fork if you have merge access on the main repo).
> >
> 
> In general I expect none of those branches to live longer than 24 hours as
> the PRs they were created for should be merged in less than an hour. If a
> branch is older than a day then it means someone probably forgot to delete
> the branch after merging a PR.

If it isn't already in the devguide (I have to admit I haven't really
read the new guide yet), once you end up pulling one of those branches
into your remotes, it will stay there until you do:

git remote prune 

The above will delete any local copies of branches that have been
deleted in .

--David
___
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] autoconf 2.70

[R. David Murray]

On Thu, 24 Nov 2016 12:22:00 +0100, Victor Stinner  
wrote:
>  I know that tracking generated files is not pure, but it's very
> convenient, so please keep them: configure, Python/importlib.h,
> Python/importlib_external.h, etc.!
> 
> When testing Python on some "custom" operating systems, I already had
> enough issues to compile Python :-) For example, on OpenIndiana,
> Python wanted to rebuild the grammar but the system Python was 2.6
> which didn't work (I don't recall the details). Moreover, the "make
> touch" command didn't work neither :-)

Right, tracking those artifacts is a long standing policy and exists
for good reasons.  Our policy is that the committed changes should
be done with the "right" version of the tool to minimize churn, and
I think we should maintain that policy even if we sometimes screw up.

(I thought we had actually introduced a check for it in the Makefile, but
I guess not...that would make it inconvenient for someone to intentionally
use a different version for a custom build.)

--David
___
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] 3.6 branch now open only for 3.6.0 release critical fixes and doc updates!

[R. David Murray]

On Tue, 22 Nov 2016 13:47:35 -0500, Ned Deily  wrote:
> On Nov 22, 2016, at 12:59, Brett Cannon  wrote:
> > I think for me what made everything click was realizing that we used
> > to say "until rc1 is cut, treat it as the beta phase", while Ned is
> > saying "since b4 is the last beta, we are now working towards the
> > RC". I actually think Ned's approach is mentally more consistent as
> > we are always working towards the next release which should specify
> > the commit rules, while historically we have worked as if the *last*
> > release dictated the commit rules *unless* it was for the final
> > release.
> 
> Yes, thanks, Brett!  That is indeed my way of thinking about the
> release and I think it is also consistent with how we describe the
> Release Candidate stage in the Developer's Guide.

OK, fair enough.  It's a change in our development style, but a
reasonable one.  I (and Victor I presume) were fooled by the fact that
it is a change, but it wasn't obvious that it was.

If we wish to use this going forward (and I think that would be
reasonable), then we should document it.

Being who we are (precisionist programmers), the inconsistency between
"beta release cuts off features" and "last beta before RC cuts off
non-release-critical fixes" does produce some cognitive dissonance.
I've seen the RC described as "the first beta that might be turned into
the production release", and if you think of it that way it makes it
easier to remember that we're restricting commits in order to produce that
"special beta".  That is probably better, conceptually, than producing
an RC that we fully expect will require release-critical bug fixes because
we just committed a bunch of non-release-critical bug fixes, just
so cutoff-when-the-name-changes stays consistent.

--David
___
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] 3.6 branch now open only for 3.6.0 release critical fixes and doc updates!

[R. David Murray]

On Tue, 22 Nov 2016 02:24:37 -0500, Ned Deily  wrote:
> On Nov 22, 2016, at 02:02, Ned Deily  wrote:
> > On behalf of the Python development community and the Python 3.6 release
> > team, I'm pleased to announce the availability of Python 3.6.0b4. 3.6.0b4
> > is the last planned beta release of Python 3.6, the next major release of
> > Python. [...]
> 
> OK, all of the release engineering for 3.6.0b4 is complete.  The 3.6
> branch in the cpython repo is now available again but, as noted,
> *only* for reviewed release critical fixes appropriate for the 3.6.0
> final and for final 3.6.0 doc updates!
> 
> Again, until 3.6.0rc1 is tagged, scheduled to happen in two weeks on
> 2016-12-05, please do *not* push non release-critical code of any kind
> to the 3.6 branch; after rc1 is tagged, the 3.6 branch will be open
> for 3.6.1 changes.  Please use these two weeks to thoroughly review
> and, as necessary, update the What's New In Python 3.6 document
> (thanks, Elvis and Yuri, for editing it once again!) and all other
> release documentation.
> 
> Any additional testing you can do and/or encourage others to do of the
> new and old components of 3.6 and with with third-party packages will
> be appreciated.  Please document anything you think *might* be a
> release critical problem in the bug tracker marking them as "release
> blocker".  Assuming no unresolved release critical problems arise, the
> final two steps will be the release candidate in 2 weeks and then,
> again assuming no release critical problems are identified in it, the
> final release on 12-16.
> 
> Please contact me if you have any questions about what may or may not
> be appropriate to push during these final days before the release.


I'm sorry, but I find this confusing. It wasn't what I understood
your previous email to mean, which means I didn't read it carefully
enough and saw it through a filter of my preconceptions.

Essentially, you are making B4 act like RC1 except that you are expecting
there to be fixes, and making RC1 act like RC2 with hopes that it really
is final.  That's fine, but we really ought to have named them RC1 and
RC2 in that case.

I'm not suggesting you change your plan now, except that you should *not*
open the 3.6 branch for commits until after *final* is released, in case
another RC is required.  Unless you plan to branch and cherry pick for an
"RC2" if it is needed, which would be fine, but you should say that :)

If we in fact miss something in this really-an-RC phase (RC0?) that
is revealed by the testing of RC1, then I strongly recommend against
making changes to RC1 and then releasing the result as final without
external testing.  We've had a brown bag release in the past by doing
that, for what we thought were "safe" fixes.  Any "extra" RC period can
be really short, though.

--David
___
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] 3.6.0 Beta Phase Development

[R. David Murray]

 - python-dev

On Mon, 12 Sep 2016 20:15:06 -0400, Ned Deily  wrote:
> 2016-12-04 3.6.0 release candidate 1 (3.6.0 code freeze)
> 
> 2016-12-16 3.6.0 release (3.6.0rc1 plus, if necessary, any dire emergency 
> fixes)

IMO, if any dire emergency fixes are necessary there should be an rc2,
which then becomes the release version.  But I understand that the goal
is to have *no* dire emergency fixes, and so be able to go right from
rc1 to release.

In particular, I am reading your policy on rc1 to mean that unlike in
the past, even if someone reports "a bug" in rc1, it won't be fixed in
3.6.0 unless it is a "break the world" regression or a "brown bag release"
level problem.  Anything less significant will just get shipped.

Is that correct?

--David
___
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] Is it just me or is the tip broken at the moment?

[R. David Murray]

On Thu, 07 Jul 2016 11:15:29 -0500, Zachary Ware  
wrote:
> On Thu, Jul 7, 2016 at 11:03 AM, Steven D'Aprano  wrote:
> > I'm wondering if I've broken something at my end, or if everyone is
> > seeing the same error.
> 
> Works fine for me.  Have you rebuilt since pulling?  If a simple
> 'make' doesn't do it for you, try an hg purge before redoing configure
> and make.  If you don't have the purge extension enabled, you can
> enable it for one command like so: `hg --config extensions.purge=
> purge --all`.  Note that `hg purge --all` will remove all untracked
> files, so be sure you don't have any stray files in the repo that you
> want to keep.

I've never had a need to use hg purge.  'make distclean' has always
been enough for me in these situations.

--David
___
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] [Python-Dev] [RELEASED] Python 3.4.5 andPython 3.5.2 are now available

[R. David Murray]

On Mon, 27 Jun 2016 12:51:07 -0700, Steve Dower  wrote:
> I hoped by informing the lists we'll be able to address concerns as
> they come up, but I'd rather not have a semi-permanent instruction to
> ignore a virus scanner :)

Good point.  I actually thought about that a few hours after I sent
the email :)

--David
___
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] [Python-Dev] [RELEASED] Python 3.4.5 and Python 3.5.2 are now available

[R. David Murray]

On Mon, 27 Jun 2016 08:25:40 -0700, Steve Dower  wrote:
> On 26Jun2016 1932, Larry Hastings wrote:
> > https://www.python.org/downloads/release/python-352/
> > ...
> > /p.s. There appears to be a small oops with the Windows installers for
> > 3.5.2--uploaded to the wrong directory or something.  They'll be
> > available soon, honest!
> 
> I've already submitted a false positive report, so I expect an update to 
> correct it at some point in the future, but please do not be alarmed to 
> see this warning when installing Python 3.5.2, or when scanning any 
> earlier version of 3.5.
> 
> Feel free to contact me off-list or steve.dower at microsoft.com if you 
> have concerns.

Should there be a note about this on the download page(s)?

--David
___
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] bugs.python.org, job status, and contributors (aka not core devs)

[R. David Murray]

On Mon, 06 Jun 2016 20:25:22 +0300, =?UTF-8?Q?Berker_Peksa=C4=9F?= 
 wrote:
> On Mon, Jun 6, 2016 at 7:41 PM, Ethan Furman  wrote:
> > Question:  I noticed a couple issues on b.p.o that were being closed by
> > contributors (not core-devs, not their own issues).
> >
> > Should non-core-devs be closing issues that do not belong to them?
> 
> Yes, but they should provide enough information (commit hash, issue
> number etc.) about their reasons to close those issues.

Right.  In general though when one is closing an issue there isn't a
commit hash to note unless that has already been noted by the commit
bot, in which case it is likely to be a core dev doing the close since
they did the commit.  An issue number would be cited in the case of
a duplicate, yes.  There are other reasons to do a close, and those
reasons should be stated clearly in an accompanying comment.  That
goes for core devs as well as triage people, obviously :)

I'm assuming here that you are amplifying that non-committers can close,
not that you are saying that there are some who are not commenting on
why they are doing the close.

> Also slightly off-topic, but we should be more transparent about
> giving people triage rights on the tracker. I'm seeing some unknown
> people (at least they are unknown to me) who assign issues to
> themselves without knowing what the field is about.

Some while back we made the decision to be fairly liberal in handing out
tracker privs for triage.  If there are people who are not following the
devguide with regards to triage, let us know here and we can discuss it
and mentor them.  Triage privs can only be given out by some core devs,
so you can find out who and why by posting here.  Well, unless it is
someone from long enough ago that we've all forgotten about them :)

We've talked about having a 'triage capable' symbol to go with our
core dev and contributer agreement symbols, but no one has implemented
it yet.

--David
___
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] I broke the 3.5 branch, apparently

[R. David Murray]

I don't understand how it happened, but apparently I got a merge commit
backward and merged 3.6 into 3.5 and pushed it without realizing what
had happened.  If anyone has any clue how to reverse this cleanly,
please let me know.  (There are a couple people at the sprints looking
in to it, but the mercurial guys aren't here so we are short on experts).

My apologies for the mess :(

--David
___
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] Promote Xavier de Gaye as a core developer

[R. David Murray]

On Tue, 24 May 2016 17:28:00 +0200, Victor Stinner  
wrote:
> 2016-05-24 15:42 GMT+02:00 R. David Murray :
> > PS: with respect to Victor's script wish, one of the reasons I'm suggesting
> > paul.j3 is that very few of his patches have been committed, and they
> > should be.
> 
> Oh, it looks like a chicken-and-egg issue. We are not enough
> reviewers, but we need reviews to get new reviewers? :-)

Yes, exactly :)

--David
___
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] Promote Xavier de Gaye as a core developer

[R. David Murray]

On Tue, 24 May 2016 00:22:07 -0400, Ned Deily  wrote:
> In article <20160523174004.cb04eb14...@webabinitio.net>,
>  "R. David Murray"  wrote:
> > +1 from me as well.  I'd just put him on my shortlist of people to
> > consider.  I haven't gone over his patch history, but the two or three
> > I've looked at before were high quality and cognizant of our culture.
> > I think the Android support pretty much cinches the deal :)
> 
> David,
> 
> I believe we had a discussion a while back about a few other potential 
> new core developers.  But, other than subsequently adding Davin, I don't 
> know of anything that has happened with regard to the earlier 
> discussions.  Is it time to discuss your shortlist?

Sure.  I might even be able to mentor someone.

My current shortlist is eryksun and paul.j3.  I've finally got time to
monitor the bugs a bit more now, so I hope I'll notice some others in
a while.

Assuming Paul is interested, I could be his mentor, if others agree his
patches are good enough.  I'd like other people to actually look...it's
been a while since I've reviewed any of his patches, or the design
decisions he's advocating with respect to argparse.  (Steven appears to
be awol.)

--David

PS: with respect to Victor's script wish, one of the reasons I'm suggesting
paul.j3 is that very few of his patches have been committed, and they
should be.
___
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] Promote Xavier de Gaye as a core developer

[R. David Murray]

On Sun, 22 May 2016 14:23:08 +0200, Victor Stinner  
wrote:
> 2016-05-22 11:42 GMT+02:00 Stefan Krah :
> > +1. The Android patches are very good -- he would be the ideal maintainer.
> 
> The Android work looks to become something serious. To make the
> Android support official, we need a buildbot, but let's discuss that
> on python-dev later ;-)
> 
> Cool, already three +1 (ignoring my own +1). I will wait until friday
> to give time to other to give their opinion on Xavier's promotion.
> 
> I'm now also reading https://docs.python.org/devguide/coredev.html to
> see the next steps ;-)

+1 from me as well.  I'd just put him on my shortlist of people to
consider.  I haven't gone over his patch history, but the two or three
I've looked at before were high quality and cognizant of our culture.
I think the Android support pretty much cinches the deal :)

--David
___
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] Making the PSF CoC apply to core developers

[R. David Murray]

On Fri, 04 Mar 2016 21:31:44 +, Brett Cannon  wrote:
> I guess I'm just worried about the health of this project. I'm doing what I
> can through the migration to GitHub to make it easier for others to get
> involved while making it easier for us to accept the work of others, but
> the maintenance and health of this team worries me. For instance, if you
> look at the developer's log you will notice we only gained 2 core devs for
> all of 2015 and the last one was August 2015:
> https://docs.python.org/devguide/developers.html. 2013 was the next slowest
> year with 4, but most years are much closer to 10 than 0. We also still
> have no female or minority members.

Remember how new committers happen: current committers notice their
contributions on the tracker, suggest they be given the commit bit and
offer to mentor them, and we take a poll.  The critical bits here are
(1) noticing and (2) being willing to mentor.  So, if we want more
committers, current ones need to put forth the effort to monitor active
bugs, evaluate prospects, and recommend and mentor them.  And hopefully
do some mentoring via the bug tracker to get more people commit-bit ready.

This is a catch 22: we need more active committers in order to get
more active committers.  But we know that; that question is what to do
about it.

I the past few years I've monitored the bug tracker fairly closely, and
watched for good prospects, and recommended or inspired the recommendation
of several.  Right now I don't have the time to monitor the bug tracker
the way I had been and watch people the way I had been, so I won't be
in a position to recommend anyone for the next while

--David

PS: Actually, let me throw out that the people that had been at the
top of my list before I stopped were eryksun, paul.j3 (for argparse),
and davin (for multiprocessing).  And I suspect maciej.szulik is also a
candidate once we've seen a few more patches from him.  (And I need
to find the time to review the ones he has already submitted in the
email area.)

Someone or ones should look at tracker activity by username and see if
they can find some more candidates.
___
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] Making the PSF CoC apply to core developers

[R. David Murray]

On Fri, 04 Mar 2016 21:31:44 +, Brett Cannon  wrote:
> The discussion about the Code of Conduct has sputtered out, so I'm going to
> assume those who care to speak up have at this point. It seems to me that
> the general agreement is that putting python-dev and bugs.python.org under
> the CoC might not solve any real issues we currently have, but it won't
> hurt anything either (and both python-committers and python-ideas are
> already covered). And since the CoC might make some people feel more
> comfortable in participating, that means going ahead and flipping on the
> CoC where we reasonably can.

I guess I have one more thing to say.

Thinking about this, I realized that in fact this emphasis on the CoC is
making me feel less like contributing.  I doesn't feel like a large
effect, but it is real[*].  Just thought you should know :)

--David

[*] I think it is a feeling of annoyance, like I'm being nagged for
no good reason, inclining me to turn my attention away instead of joyfully
engaging.  Talking about how welcoming the Python community is, and how we
can be more so, engenders joy.  Talking about codes of conduct engenders
annoyance.  Regardless of the reality, it *feels* like the bureaucrats
have moved in and are squashing the native aliveness of the community.
___
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] Making the PSF CoC apply to core developers

[R. David Murray]

On Tue, 01 Mar 2016 19:00:21 +, Brett Cannon  wrote:
> I don't want this discussion to drag on forever as CoC discussions tend to,

Agreed, I made my point and don't otherwise feel a need to engage in
further discussion.  Unless someone pushes one of my buttons, I
suppose :)

> Now obviously I could be totally wrong and this isn't an actual barrier for
> getting women or ethnic minorities to participate in Python's development.

Yeah, there's no way to know, as far as I can see.  But I think our
*being* welcoming is way, *way* more important than our *saying* we are
welcoming.

--David
___
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] Making the PSF CoC apply to core developers

[R. David Murray]

On Tue, 01 Mar 2016 04:10:08 +, Brett Cannon  wrote:
> On Mon, 29 Feb 2016 at 18:01 Steven D'Aprano  wrote:
> > So let me make it clear: Brett, and the other list maintainers, you're
> > not listening. Even if I'm a minority of one out of the whole community,
> > your words say "of course we care what you think" but your actions say
> > "actually no, we couldn't care less". You might not have intended it
> > that way, but nevertheless that's the way it is.
> >
> 
> I see where the issue came in: I simply considered the discussion on the
> CoC already settled. As you pointed out in your second paragraph, the

Just so Steven doesn't think he's a minority of one, let me say that I
too find CoCs problematic.  I have a code of conduct, and it applies to my
*life*.  For shorthand, you could call it "being a gentleman", but a more
modern term might be "being civil".  Do I fail to live up to my personal
code occasionally?  Yes, and I hope people call me on it when I do fail.
Do I care what code of conduct the organization has promulgated?  No.
It has no affect on my behavior, nor will it.  At most, it might drive
me from the community if it is ever used against me.

Referencing a CoC will only work at all with those who are self-governed
by a personal code of civility.  Yet all such people need is to have it
pointed out to them that they have been uncivil, with reference to the
universal code of civility and/or a civil discussion about civility in
the immediate context.

Those who are not already self-governed by a personal code of civility
will not be bound by the CoC, though they may give it lip service and
carry on a long, probably uncivil, argument about the rules embodied in
the CoC.

Against those who are not self-governed, only power plays, which
ultimately probably means expulsion by technical means, will work...and
what matters it if you reference that expulsion to a specific code of
conduct, or the universal one?

How it actually matters is that people who are not civil will "rules
lawyer" you on the specific one if you have one and you attempt to use it
to police their behavior.  Worse, they will use it to "rules lawyer" people
they don't like or whose opinions they object to.

When things get bad enough that a call to (universal) civility is not
enough, ultimately someone has to make the call.  That person might
as well do it based on their own moral code, as the "owner" of the
resource[*], and not have to try to justify it based on some specific set
of rules-on-paper.  They are going to take flak for making the decision
anyway, so why hand the uncivil an extra weapon?

Note that I am not saying that there aren't/weren't problems.  Those
problems need to be (and are) addressed *universally* by a change in
civic culture via the cultural dialog that is always going on around us.
Discussions of what civility is in the context of specific incidents are
an important part of that.  Specific codes of conduct, on the other hand,
very often make the problem *worse*, and delay the implementation of
beneficial cultural shifts, because they attempt to freeze the rules,
very often do it badly, and thus become instead a weapon in the hands
of the uncivil and/or the power hungry.

All that said, the Python CoC is not a bad restatement of parts of the
universal code, so it is hopefully less subject to this abuse than
others that I have seen.  For that I am thankful.  As I am thankful
that the Python community rarely has conflicts that rise to the level of
intransigent uncivility.  The fundamental civility of this community is
one of the things that I value about it, even if it isn't quite perfect :)

--David

[*] Yes, in our case that is ultimately Guido, as Brett indicated.
___
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] Deprecation Policy PEP

[R. David Murray]

On Tue, 02 Feb 2016 15:33:58 +0200, Ezio Melotti  wrote:
> On Sat, Jan 30, 2016 at 5:36 AM, Guido van Rossum  wrote:
> > Following the lead of 2.7.10 and 2.7.11 we could continue with 3.10, 3.11, 
> > etc.
> >
> 
> I think we should continue with 3.10, 3.11, etc.
> Changing the major version should be done for incompatible changes,
> and just doing it after 3.9 will probably just create confusion for
> both users that will wonder if it's incompatible with Python 3 and for
> things like the executable name.
> Hopefully we won't need to jump to Python 4 for a long time.
> 
> > I also want the 3->4 transition to feel like a non-event for most
> > users. How we'll do that I don't know yet, but I want it to be a lot
> > smoother than 2->3.

I think Guido's point is that we shouldn't *make* incompatible changes,
and that the 4.0 transition should be smooth so that people learn we are
committed to that.  This is potentially analogous to the linux
transition from 2.x to 3.x, despite the fact that it goes against the
rules of semantic versioning.

That said, I don't view removing deprecated things as a incompatible
change, since code that has dealt with the deprecations will run on both
the version before (usually versions plural) and the version after the
removal.  Whether we should do a mass removal in 4.0 (or the first post
2.7 release) is a question, and so far the sense I get of the community
is that there is not even close to a consensus on that.  But it would
give a semantic versioning meaning to the change from 3.x to 4.x,
without actually being all that disruptive.  On the other hand, a mass
removal would be more disruption than removals spaced over several
releases, so FUD might well arise as an issue, as you say.

Regardless though, the name is an issue :)

So, I guess I see the arguments between going 3.9->4.0 vs 3.9->3.10
as fairly balanced and don't have a strong preference.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

[R. David Murray]

On Tue, 05 Jan 2016 01:26:58 +, "Gregory P. Smith"  wrote:
> On Mon, Jan 4, 2016 at 12:34 PM R. David Murray 
> wrote:
> 
> > to have to do some extra work to make the hash links work in the bug
> > tracker, since I don't think there's any a priori way to distinguish
> > between hg hashes and git hashes.
> >
> 
> Just ignore the remote possibility of short 32-bit hash prefix collisions
> (possible, but infrequent): the way to resolve that is when a hash lookup
> fails, to look it up in a translation index of former hg hashes.
>  practical.  good enough.

Yes, collision is not the problem, it's that you can't distinguish them
without a lookup table or something.  Which means we have to do more
than just change the URL in the existing linkifier, which was my point.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

[R. David Murray]

On Mon, 04 Jan 2016 18:18:02 +, Brett Cannon  wrote:
> On Mon, 4 Jan 2016 at 09:50 Eli Bendersky  wrote:
> >
> > I have to admit that I'm not a big expert on Mercurial --> Git converters
> > and the way I maintain this mirror may not be the best approach, so I
> > encourage you folks to find a VCS guru to look into this for the "real"
> > transition.
> >
> 
> That will be one of the early steps of the transition. :)

Maybe The PSF could fund Eric Raymond to do this?  He's got
beyond-the-basics tooling, and a fair bit of experience converting
large projects.  He might even be able to clean up the older (svn)
history along the way, although that might be too much to hope for ;)

(Oh, and let me mention this while I'm thinking about it: we're going
to have to do some extra work to make the hash links work in the bug
tracker, since I don't think there's any a priori way to distinguish
between hg hashes and git hashes.)

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] I am nos selectable in the bugtracker

[R. David Murray]

On Fri, 11 Dec 2015 22:50:12 +0100, Jesus Cea  wrote:
> After sending my new SSH key I have recovered "push" abilities in the
> mercurial repository, but it looks like I am not present in the bug
> tracker "assigned to" field.

I see jcea there.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Committer missing :)

[R. David Murray]

On the other hand, docs.python.org/devguide/developers.html still will
(and does).

On Sun, 06 Dec 2015 17:09:25 -0800, Benjamin Peterson  
wrote:
> Indeed, if you have no keys around, the (automatically generated)
> committers.txt file will not list you.
> 
> 
> On Sun, Dec 6, 2015, at 17:05, Jesus Cea wrote:
> > I was trying to push a patch but it seems I am not a committer anymore.
> > My name vanished of  and the
> > tracker.
> > 
> > I guess I had a DSA key in hg.python.org and those are not valid
> > anymore, but looks like I am not a documented committer anymore in order
> > to send a new 2048 bits RSA key.
> > 
> > I don't know if this is a mistake or a decision. Just let me know.
> > 
> > -- 
> > Jesús Cea Avión _/_/  _/_/_/_/_/_/
> > j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
> > Twitter: @jcea_/_/_/_/  _/_/_/_/_/
> > jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
> > "Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
> > "My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
> > "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
> > 
> > ___
> > python-committers mailing list
> > python-committers@python.org
> > https://mail.python.org/mailman/listinfo/python-committers
> > Email had 1 attachment:
> > + signature.asc
> >   1k (application/pgp-signature)
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] New installed Python builders

[R. David Murray]

On Mon, 23 Nov 2015 19:11:15 +0200, Serhiy Storchaka  
wrote:
> On 23.11.15 18:00, R. David Murray wrote:
> > On Mon, 23 Nov 2015 00:58:01 -0600, Zachary Ware 
> >  wrote:
> > I haven't looked at this, but unless the buildbot does *not* have write
> > access to the installed directories (ie: the install was done as another
> > user) it isn't really doing a full installed python test.
> 
> Yes, but at least it catches cases where some files are not installed. 
> There were few issues with this.

True.  Something incomplete in this vein is better than nothing.  I'm
Not sure you should call it "Installed" though, as that will be a bit
misleading.  Most of the "can't run the tests on installed python" bugs
are because the tree is read-only (obviously, not all of them!).
Maybe call it "local install"?  Wordy, I know, but more accurate.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] New installed Python builders

[R. David Murray]

On Mon, 23 Nov 2015 00:58:01 -0600, Zachary Ware  
wrote:
> Hi,
> 
> Inspired by a couple of issues about testing installed Python that
> popped up this morning (#25694 and #25696), I've set up a new set of
> builders[1] to build, install, and test the installed Python.  They
> run on the same slave that runs my "x86 Gentoo Non-Debug with X"
> builders.
> 
> If you are interested, please have a look at how they do what they do,
> and let me know if you see any issues with how it's set up.  Since the
> 3.x builder is not failing, I'm not sure whether the issues have been
> fixed or if I messed something up in the setup :)
> 
> [1] 
> http://buildbot.python.org/all/builders/x86%20Gentoo%20Installed%20with%20X%203.x
> 
> http://buildbot.python.org/all/builders/x86%20Gentoo%20Installed%20with%20X%203.5
> 
> http://buildbot.python.org/all/builders/x86%20Gentoo%20Installed%20with%20X%203.4
> 
> http://buildbot.python.org/all/builders/x86%20Gentoo%20Installed%20with%20X%202.7

I haven't looked at this, but unless the buildbot does *not* have write
access to the installed directories (ie: the install was done as another
user) it isn't really doing a full installed python test.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Python 3.6 Release Schedule Details

[R. David Murray]

On Thu, 01 Oct 2015 22:24:18 -0400, Ned Deily  wrote:
> Another change has been to add a fourth beta and drop the third
> release candidate.  My gut feeling from the past several releases is
> that a lot of feature code does not get checked in until close to the
> b1 feature code cutoff so that extending the beta phase should result
> in more testing exposure for all features.  And I would like to reduce
> the amount of churn during the release candidate phase: a worthy goal
> is to make no changes after rc1, so that an rc2 would be be made only
> if absolutely necessary.

I would like to be wrong, but I think this is unrealistic.  The reality
seems to be that there are a significant number of people (especially on
the Windows side, if I'm guessing correctly) who do not test until we
get to RC1.  IIRC we had a number of changes between RC1 and RC2, and a
non-trivial number of changes between RC2 and RC3 this time around.

That said, I do feel the amount of pre-release testing, even in the beta
part of the cycle, has increased steadily in the past two or three
releases, which is great to see.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] [Python-Dev] How are we merging forward from the Bitbucket 3.5 repo?

[R. David Murray]

On Sun, 16 Aug 2015 11:24:32 -0400, "R. David Murray"  
wrote:
> On Sun, 16 Aug 2015 00:13:10 -0700, Larry Hastings  wrote:
> >  3. After your push request is merged, you pull from
> > bitbucket.com/larry/cpython350 into hg.python.org/cpython and merge
> > into 3.5.  In this version I don't have to do a final null merge!
> > 
> > I'd prefer 3; that's what we normally do, and that's what I was 
> > expecting.  So far people have done 1 and 2.

Thinking about this some more I realize why I was confused.  My
patch/pull request was something that got committed to 3.4.  In that
case, to follow your 3 I'd have to leave 3.4 open until you merged the
pull request, and that goes against our normal workflow.

Maybe my patch will be the only exception...

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] [Python-Dev] How are we managing 3.5 NEWS?

[R. David Murray]

The 3.5.0 patch flow question also brings up the question of how we
are managing NEWS for 3.5.0 vs 3.5.1.  We have some commits that
are going in to both 3.5.0a2 and 3.5.1, and some that are only going
in to 3.5.1.  Currently the 3.5.1 NEWS says things are going in to
3.5.0a2, but that's obviously wrong.

Do we relabel the section in 3.5.1 NEWS as 3.5.1a1?  That would leave us
with the 3.5.1 NEWS never having the last alpha sections from 3.5.0,
which is logical but might be confusing (or is that the way we've done
it in the past?)  Do we leave it to the RM to sort out each individual
patch when he merges 3.5.0 into the 3.5 branch?  That sounds like a lot
of work, although if there are few enough patches that go into the
alphas, it might not be too hard.

Either way, that final 3.5.0 merge is going to require an edit of the
NEWS file.

Larry, how do you plan to handle this?

--David

PS: We'll also need an answer to this question for the proposed new
NEWS workflow of putting the NEWS items in the tracker.  We'll probably
need to introduce x.y.z versions into the tracker.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] [Python-Dev] How are we merging forward from the Bitbucket 3.5 repo?

[R. David Murray]

On Sun, 16 Aug 2015 00:13:10 -0700, Larry Hastings  wrote:
> 
> 
> So far I've accepted two pull requests into 
> bitbucket.com/larry/cpython350 in the 3.5 branch, what will become 
> 3.5.0rc2.  As usual, it's the contributor's responsibility to merge 
> forward; if their checkin goes in to 3.5, it's their responsibility to 
> also merge it into the hg.python.org/cpython 3.5 branch (which will be 
> 3.5.1) and default branch (which right now is 3.6).
> 
> But... what's the plan here?  I didn't outline anything specific, I just 
> assumed we'd do the normal thing, pulling from 3.5.0 into 3.5.1 and 
> merging.  But of the two pull requests so far accepted, one was merged 
> this way, though it cherry-picked the revision (skipping the pull 
> request merge revision Bitbucket created), and one was checked in to 
> 3.5.1 directly (no merging).
> 
> I suppose we can do whatever we like.  But it'd be helpful if we were 
> consistent.  I can suggest three approaches:
> 
>  1. After your push request is merged, you cherry-pick your revision
> from bitbucket.com/larry/cpython350 into hg.python.org/cpython and
> merge.  After 3.5.0 final is released I do a big null merge from
> bitbucket.com/larry/cpython350 into hg.python.org/cpython.
>  2. After your push request is merged, you manually check in a new
> equivalent revision into hg.python.org/cpython in the 3.5 branch. 
> No merging necessary because from Mercurial's perspective it's
> unrelated to the revision I accepted.  After 3.5.0 final is released
> I do a big null merge from bitbucket.com/larry/cpython350 into
> hg.python.org/cpython.
>  3. After your push request is merged, you pull from
> bitbucket.com/larry/cpython350 into hg.python.org/cpython and merge
> into 3.5.  In this version I don't have to do a final null merge!
> 
> I'd prefer 3; that's what we normally do, and that's what I was 
> expecting.  So far people have done 1 and 2.
> 
> Can we pick one approach and stick with it?  Pretty-please?

Pick one Larry, you are the RM :)

The reason you got different things was that how to do this was
under-specified.  Which of course we didn't realize, this being a new
procedure and all.

That said, I'm still not sure how (3) works.  Can you give us a step by
step like you did for creating the pull request?  Including how it
relates to the workflow for the other branches?  (What I did was just do
the thing I normally do, and then follow your instructions for creating
a pull request using the same patch I had previously committed to 3.4.)

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] A possible solution to the Misc/NEWS merging problem

[R. David Murray]

On Tue, 11 Aug 2015 14:58:45 +1200, Robert Collins  
wrote:
> On 11 August 2015 at 10:38, Brett Cannon  wrote:
> > We have all been there: you fix something in some maintenance branch, do
> > your `hg pull` into the default branch, and everything but Misc/NEWS merges
> > cleanly. You typically revert Misc/NEWS, commit your forward-ported change
> > to default, and then move on with your life. It would be much easier if
> > Misc/NEWS was never an issue.
> ...
> > The whole point of this email is to let everyone know that this is the plan
> > and should be coming in a couple of months (I'm also hoping to make a
> > decision about a new overall workflow by 2016, but I need to hear back from
> > Donald first about whether the proposed timeline for a test instance will
> > work for him). If you hate this idea so much that it will cause you to stop
> > contributing to Python then let me know, otherwise I'm going to assume
> > people are either happy with this approach or will begrudgingly accept it.
> 
> Clearly I should join the core-workflow list.
> 
> Has anyone put forward the 'standard' solution other projects use: to
> extract NEWS entries from commit logs?

Yes, and we will doubtless allow for the tracker field to be populated
from specially tagged commit message paragraphs.  But the commit log is
*not* the NEWS file, and commit log entries cannot be edited, so the
source for the NEWS file has to be somewhere else...thus the tracker
fields.

Note that IMO it should never be the case that a commit log entry is the
*same* as a NEWS entry: the two serve different purposes and have
different audiences.  The full commit message should be wordier.  But
allowing committers to put a tagged paragraph in a commit message so they
don't have to also update the tracker is a fine idea.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Having issues updating a checkout

[R. David Murray]

According to the infrastructure list/#python-infra, there is currently
some instability in the load balancers.  That is probably the source of
these errors.

On Sun, 09 Aug 2015 14:45:27 -0400, Ned Deily  wrote:
> > On Aug 9, 2015, at 14:19, Brett Cannon  wrote:
> > 
> > Anyone else seeing this?
> > 
> >   pulling from ssh://h...@hg.python.org/cpython 
> >   remote: ssh_exchange_identification: Connection closed by remote host 
> >   abort: no suitable response from remote hg!
> > 
> > My laptop is fairly new so I'm trying to eliminate any way it might be my 
> > setup instead of the servers.
> 
> You are not alone.  Both Steve Dower and I have seen similar problems within 
> the last four hours or so; it appears to be intermittent.
> 
> --
>   Ned Deily
>   n...@acm.org -- []
> 
> 
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

[python-committers] erykun

[R. David Murray]

FYI I just granted Developer privs on the tracker to eryksun (real name
unknown), after wondering why s/he hadn't just closed an issue s/he
commented on and thereby finding s/he didn't have them yet.

Someone to keep an eye on, IMO.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] "Gratuitous"? incompatibilities in the "fix only" releases

[R. David Murray]

On Thu, 30 Jul 2015 00:11:53 +0200, Jesus Cea  wrote:
> On 29/07/15 18:50, Guido van Rossum wrote:
> > I believe that in this particular case, the bug was fixed (by tightening
> > the requirements for headers) because the bug can lead to security
> > vulnerabilities. I think you can find more by Googling for keywords like
> > "http header injection". The more recent Python 2.7 bugfix releases have
> > specific exemptions from the backwards compatibility requirements for
> > security fixes -- because their lifespan will still be many years (EOL
> > of 2.7 is summer 2020).
> 
> That argument is valuable but it fails when considering that this fix
> will be present in 3.4.4 too, with a normal EOL. I am OK with that,
> though. As I said, I sent my first message for policy verification and
> to raise awareness.

No, the security bug fix conditional exception applies to all
maintenance releases.  The big (PEP required) exception for 2.7 was that
the *API* changed in 2.7 in certain ways.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] "Gratuitous"? incompatibilities in the "fix only" releases

[R. David Murray]

On Wed, 29 Jul 2015 13:41:09 -0400, Terry Reedy  wrote:
> On 7/29/2015 1:01 PM, Robert Collins wrote:
> > On 30 July 2015 at 04:50, Guido van Rossum  wrote:
> >> I believe that in this particular case, the bug was fixed (by tightening 
> >> the
> >> requirements for headers) because the bug can lead to security
> >> vulnerabilities. I think you can find more by Googling for keywords like
> >> "http header injection". The more recent Python 2.7 bugfix releases have
> >> specific exemptions from the backwards compatibility requirements for
> >> security fixes -- because their lifespan will still be many years (EOL of
> >> 2.7 is summer 2020).
> >
> > Yeah - this is a security issue, and unfortunately its one that can
> > break programs [or rather, expose how they were broken already at an
> > earlier and less susceptible point].
> >
> > As a new committer, I'd like to double check my understanding of the policy:
> >
> > https://docs.python.org/devguide/devcycle.html#maintenance-branches
> > "...
> > The only changes allowed to occur in a maintenance branch without
> > debate are bug fixes. Also, a general rule for maintenance branches is
> > that compatibility must not be broken at any point between sibling
> > minor releases (3.4.1, 3.4.2, etc.).
> 
> Since bug fixes break code that depends on the bug (as happened in this 
> case), the second rule appears to be written too strongly.  It really 
> needs a short paragraph.  Bug fixes should only break code depending on 
> the bug. Bug fixes must not change existing non-buggy features and 
> should not introduce new features.  Non-security bug fixes that break 
> too much code deemed to be reasonable are sometimes deferred to the next 
> release.

No, I don't think it is too strong.  Normally even code that depends on
the bug should not be broken.

The calculus is necessarily a work of art:  how likely is this bug fix
to break working code?  If the bug fixes something that previously
raised an error, it is (usually) a no-brainer.  If it fixes an erroneous
result it is a judgement call based on how likely fixing it is to break
working code, but usually it would get fixed.  If it fixes an erroneous
behavior it is again a judgement call, but weighted toward not going in
to a maintenance release.  Bugs judged too likely to break working code
get fixed in feature releases (and mentioned in What's New).

>  > For both rules, only rare
> > exceptions are accepted and must be discussed first."
> >
> > Where should these things be discussed? I've been discussing with
> > other committers on the issues in the issue tracker. Is this
> > sufficient? What is the social norm?

Usually the bug tracker is enough, with escalation to python-dev if
there is a core-committer disagreement.  For security issues, the
security team should get involved in any decision, and their decision is
pretty much final.  I believe they automatically get notified if
'security' is selected for behavior...if not we should make it so.

> Feature additions like adding a new parameter to fix a bug should be 
> discussed on pydev.  For instance, difflib.SequenceMatcher gained the 
> autojunk parameter in 2.7.1.  I believe the pydev discussion included 
> "Is the issue a bug?" (yes) and "Does it need fixing in the current 
> release?" (yes, it generated multiple bug reports). I believe being 
> early in the long 2.7.x series and the last change to fix in 2.x played 
> a role.

This would be a very exceptional case.  I remember a discussion, I don't
remember the approval of an API change.  Changing the API in a minor
release *except* for security issues is not normally acceptable.
I'd be curious to read the reasoning behind this one.

So, the rule in the devguide is accurate, except that it should note
that exceptions are made for fixing security related issues.  That is,
the calculus about not breaking working code is given a lot less weight,
because the goal of the bug fix is to patch a security hole.  We find
it OK to break working code in order to make that code less vulnerable
to a known attack.  Although still try very hard *not* to break working
code, if at all possible.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] getting help with the hgaccounts alias

[R. David Murray]

I'm willing to volunteer for this.  I understand how this stuff works,
and no, it doesn't take much time per request...

On Wed, 22 Jul 2015 17:29:25 -, Brett Cannon  wrote:
> Maybe once a month, if that. But there have been times when people have
> sent in keys and it has taken a week or so to get them set up which seems
> too long.
> 
> On Wed, Jul 22, 2015 at 10:28 AM Ronald Oussoren 
> wrote:
> 
> >
> > > On 22 Jul 2015, at 19:23, Brett Cannon  wrote:
> > >
> > > I think the only people on it are Antoine, Georg, and myself. Antoine
> > has said he has left python-dev, Georg is often busy with school, and I'm
> > on a temp machine for a few weeks so I can't add any SSH keys for a while
> > (heck I'll probably need new ones installed on my behalf once I have a
> > permanent machine).
> > >
> > > Is anyone up for helping with adding SSH keys for people? It's basically
> > taking someone's key as an attachment in an email, making sure it's RSA and
> > not DSA, and then either creating a new file in a specific repo for them or
> > appending it to their existing key file.
> > >
> > > P.S.: And I don't even remember how to get people added to the group of
> > people who can add keys, so I probably need to find that out as well if
> > anyone steps forward. =)
> >
> > How often does this come up?  This doesn’t sound like something that
> > requires a lot of time to do.
> >
> > Ronald
> >
> >
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

[python-committers] Speaking of noticing tracker activity

[R. David Murray]

In the recent thread on python-dev Nick mentioned our dependence on
people noticing active contributors on the tracker.  In that regard I'd
like to recommend people take a look at the work of Martin Panter
(vadmium).

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)

[R. David Murray]

On Thu, 14 May 2015 07:15:34 -0700, Larry Hastings  wrote:
> I'll start experimenting with the workflow(s) and will add documentation 
> to the Dev Guide.
> 
> The fun starts next weekend,

By "next weekend" you mean "the weekend after this coming weekend",
right?  (These calendar idioms always confuse me.)

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Code review tool 500 error

[R. David Murray]

On Wed, 13 May 2015 15:43:17 -0400, Yury Selivanov  
wrote:
> I can't post messages to the code review tool -- it shows
> me 500 error page.

Are you doing it from the front page?  I think that doesn't work.
In-line comments plus "publish comments" does work.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Do people prefer pushing feature repos or one massive patch?

[R. David Murray]

On Thu, 02 Apr 2015 09:31:08 -0700, Guido van Rossum  wrote:
> Where I come from we always squash. More detailed history is preserved in
> the code review tool (which keeps a snapshot every time you bounce it back
> to the reviewer). Looking at my own sub-commits when I'm working on a
> complex feature or bug fix, they are often checkpoints with no particular
> significance except that the code is syntactically correct, and a common
> reason for doing a sub-commit is when I've got to attend to something else
> (e.g. a meeting).

I think a lot depends on the personal style of the committer.  I don't
do checkpoint commits, but only (try to do) commits where everything
works and the tests pass, and the commit is reviewable as a single unit.
I don't think there's a right or wrong way to do this, I think it
depends on how the person doing it thinks and organizes their work best.
I don't see a lot of value in preserving the history of someone who uses
the checkpoint-commit style, but I do see potential value in preserving
the history of someone who uses the atomic-commit style.  Perhaps we
should leave it up to the committer, based on that guideline?  (Given
our other preferences, I think a rebased commit would be the way to go
if history is preserved.)

But, if we feel a need to pick just one, I'd pick squashed.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Proposing Paul Moore for commit privileges

[R. David Murray]

On Sat, 14 Mar 2015 20:23:03 -, Brett Cannon  wrote:
> Paul has been participating on python-dev for quite a while, he is a
> committer on pip, and (co-)author on 5 PEPs. At this point I think it would
> be prudent for Paul to have commit privileges if for any other reason than
> to help manage the code related to his PEPs. But on top of that I bet Steve
> wouldn't mind more help managing Windows-specific stuff.

+1

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Mark Lawrence

[R. David Murray]

On Sun, 05 Oct 2014 14:47:06 -0400, Benjamin Peterson  
wrote:
> On Sun, Oct 5, 2014, at 14:42, Serhiy Storchaka wrote:
> > On 05.10.14 21:15, Benjamin Peterson wrote:
> > > "BreamoreBoy" is back on tracker touching hundreds of issues without
> > > adding any new information. This is certainly not the first time. Can we
> > > ban him?
> > 
> > I think it would be enough just to say him stop. He is not malicious.
> 
> I did. http://bugs.python.org/issue18372#msg228613
> 
> > 
> > Actually there was few cases when his reminders was helpful.
> 
> That's true, though, I'm not sure noise is worth the few issues that are
> closed.

It is certainly true that I for one ignore anything with his name on it,
because most of the time it is noise and it isn't worth the effort
to figure out which ones aren't noise.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

[python-committers] cherry picking after rc

[R. David Murray]

Larry, saw your discussion on IRC with Georg about what to cherry pick
into the release clone before issuing final.  IMO you shouldn't cherry
pick anything, since I believe there have been *zero* issues opened that
said that the RC was broken.  IMO the only differences between the last
RC and final should be things that would otherwise cause a "brown bag
release" (ie: broken as shipped)[*].  Bug fixes subsequent to the RC
(including doc fixes) should just wait until the next release.

Of course, I am one of the more pedantic of the developers about this
topic, and have not served as an RM, so your mileage may vary :)

--David

[*] And I would argue that you then should have another RC before the
(then unchanged except for version number) final, but I've given up on
that :)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Commit rights for Robert Collins

[R. David Murray]

On Mon, 22 Sep 2014 10:51:27 +0100, Michael Foord  
wrote:
> Robert Collins is volunteering to help with maintenance and improvement 
> of unittest. He's probably known to many of you, but Robert is the 
> creator of subunit, testtools and many Python libraries particularly in 
> the area of testing.
> 
> I'd like Robert to have commit rights for this purpose. He's already 
> submitted quite a few fixes and patches. Most recently issue 16662.
> 
> http://bugs.python.org/issue16662
> 
> Robert is an experienced and accomplished Python developer, so won't 
> need much mentoring beyond learning our development processes (which 
> branches to merge to, when a bug fix can be backported etc). In as much 
> as he needs any mentoring I'm more than happy to work with Robert.

+1

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] [Python-Dev] [RELEASE] Python 3.4.2rc1 is now available

[R. David Murray]

(Trimmed CC)

I couldn't reproduce this, nor did I see it in any of the stable
buildbots when Larry reported he had an issue with it.  Now that he's
pushed his branch, the buildbots are red with it.  So...Larry broke
it, but it is not obvious how.  Could it be something wrong with the
pydoc topics update for the release?

On Mon, 22 Sep 2014 16:58:50 +0200, Victor Stinner  
wrote:
> Someone broke test_pydoc. Example:
> http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.4/builds/481/steps/test/logs/stdio
> 
> Victor
> 
> 2014-09-22 16:15 GMT+02:00 Larry Hastings :
> >
> >
> > On behalf of the Python development community and the Python 3.4 release
> > team, I'm chuffed to announce the availability of Python 3.4.2rc1.   Python
> > 3.4.2 has many bugfixes and other small improvements over 3.4.1.  One new
> > feature for Mac OS X users: the OS X installers are now distributed as
> > signed installer package files compatible with the OS X Gatekeeper security
> > feature.
> >
> > You can download it here:
> >
> > https://www.python.org/download/releases/3.4.2
> >
> >
> > Be seeing you,
> >
> >
> > /arry
> >
> > ___
> > python-committers mailing list
> > python-committers@python.org
> > https://mail.python.org/mailman/listinfo/python-committers
> >
> ___
> Python-Dev mailing list
> python-...@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/rdmurray%40bitdance.com
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Proposing Berker Peksag for push privileges

[R. David Murray]

I have emailed Berker to (among other things) send in his keys
and introduce himself here after signing up.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

[python-committers] Proposing Berker Peksag for push privileges

[R. David Murray]

I'd like to propose that we give Berker Peksag push privileges.  He's
provided a number of good quality patches and done good review work on
other issues, and has been an active contributor for quite some time.
IMO we've reached the point where it will be easier to let him push
patches.  (We've already had at least one instance of a committer
assuming he already could.)

I volunteer to act has his mentor for learning how to push to the
repository &c.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Small change to tracker 'resolution'

[R. David Murray]

On Wed, 16 Apr 2014 10:53:53 -0400, "R. David Murray"  
wrote:
> On Tue, 15 Apr 2014 23:21:41 -0400, Terry Reedy  wrote:
> > On 4/15/2014 9:45 PM, Ethan Furman wrote:
> > > On 04/15/2014 05:55 PM, R. David Murray wrote:
> > >>
> > >> [...] I've changed the text associated with the 'invalid' resolution
> > >> to read 'not a bug' [...]
> > >
> > > Nice.
> > >
> > > Any chance of changing the 'committed/rejected' text to something else?  
> > > :)
> > 
> > Like 'finished'? 'completd'? 'done'? or even 'closed'?
> 
> Yes, dealing with committed/rejected, and indeed the whole stage/status
> workflow, is on the list to be addressed.

As an immediate improvement (pending further work) I've changed
the label from 'committed/rejected' to 'resolved'.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] New mailing list for workflow/workflow infrastructure discussion/tasks

[R. David Murray]

On Wed, 16 Apr 2014 18:02:31 -0400, Terry Reedy  wrote:
> On 4/16/2014 4:49 PM, R. David Murray wrote:
> > Apologies for the cross post, but I want to make sure committers who
> > aren't reading python-dev for one reason or another see this:
> >
> > Based on a number of conversations at PyCon, we've created a new mailing 
> > list:
> >
> > https://mail.python.org/mailman/listinfo/core-workflow
> 
> Will it be a public list, accessible via gmane, or subcription-only?

Public.  Ned has already submitted a request to get it added to gmane.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

[python-committers] New mailing list for workflow/workflow infrastructure discussion/tasks

[R. David Murray]

Apologies for the cross post, but I want to make sure committers who
aren't reading python-dev for one reason or another see this:

Based on a number of conversations at PyCon, we've created a new mailing list:

   https://mail.python.org/mailman/listinfo/core-workflow 

The purpose of this list is to facilitate the conversations and coordinate
the work that needs to happen to improve our development workflow.
Nick's PEP is one piece of this conversation, but there are many other
aspects to it as well.

Here is the list description:

This is a place to discuss and work on improvements to the CPython core
development workflow and the infrastructure that supports that workflow.
This includes changes to the roundup interface and functionality, rietveld,
mercurial, buildbots, and any other infrastructure we may add.  It also
includes discussing how we use these tools, and most importantly how we use
these tools to integrate the community beyond the core developers into the
workflow that gets patches committed to the python repository.  This means
that it also includes discussions of the process of bringing in new
contributors, including how we use the core-mentorship list, as well as how
we organize ticket triage, and how we make use of external resources such
as openhatch.  Discussions of documentation and how we organize and
maintain the documentation are also appropriate.

Anyone who is interested helping with this, or who wants to keep up with the
evolution of our thoughts on these topics, are invited to sign up to the
mailing list.

We will of course check in with python-dev and/or python-committers
as appropriate.

--David

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Small change to tracker 'resolution'

[R. David Murray]

On Tue, 15 Apr 2014 23:21:41 -0400, Terry Reedy  wrote:
> On 4/15/2014 9:45 PM, Ethan Furman wrote:
> > On 04/15/2014 05:55 PM, R. David Murray wrote:
> >>
> >> [...] I've changed the text associated with the 'invalid' resolution
> >> to read 'not a bug' [...]
> >
> > Nice.
> >
> > Any chance of changing the 'committed/rejected' text to something else?  :)
> 
> Like 'finished'? 'completd'? 'done'? or even 'closed'?

Yes, dealing with committed/rejected, and indeed the whole stage/status
workflow, is on the list to be addressed.

It is very redundant to have to set both 'closed' and
'committed/rejected', so one suggestion, that we could implement right
away, would be to simply delete that option, and then status gets left
at 'commit review' when the bug is closed.  (Or if you don't like that
you could put it back to unset.)  Later I think we may want to merge
status and stage, but we'll consider that as a part of a bigger review
of the workflow.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

[python-committers] Small change to tracker 'resolution'

[R. David Murray]

In a discussion at the sprints today Nick observed that 'invalid' was a
resolution that carried a rather negative subtext ("your bug report was
invalid", ie: "you made a mistake") , and that Red Hat used 'not a bug',
which we all agreed was much more descriptive of the actual resolution.

So, I've changed the text associated with the 'invalid' resolution
to read 'not a bug' instead.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] [RELEASED] Python 3.4.0 release candidate 1

[R. David Murray]

On Tue, 11 Feb 2014 01:01:38 -0800, Ethan Furman  wrote:
> On 02/10/2014 11:43 PM, Larry Hastings wrote:
> >
> > On behalf of the Python development team, I'm delighted to announce
> > the first release candidate of Python 3.4.
> 
> Yay!!
> 
> Question:  Now that we are in the RC phases, only critical bug fixes are 
> allowed?

Only critical fixes go into the next RC, yes (I don't know when Larry
is going to branch 3.4).  Further, every such patch must be reviewed by
at least two committers[*] (which may include the submitter), and signed
off on by the release manager.

Of course, what counts as "critical" sometimes gets debated :)

--David

[*] this is what the "commit review" stage is really for.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Code review tool (rietveld) bug

[R. David Murray]

On Mon, 27 Jan 2014 14:52:16 -0500, Yury Selivanov  
wrote:
> Hello,
> 
> I'm having difficulty with replying to a message in rietveld.
> 
> Here's a screenshot of the exception: http://goo.gl/70iQ5v
> (AttributeError at /review/20356/publish)
> 
> Is this a known issue? Maybe I'm doing something wrong?

There have been occasional problems with the email interface in our
rietveld instance.  I'm not sure if your traceback matches the other
problems, and I don't remember if those problems were actually solved.
If you restart your session (starting from the bug tracker) does the
problem reproduce?

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] PEP 462: Workflow automation for CPython

[R. David Murray]

On Sat, 25 Jan 2014 09:35:46 -0800, Eli Bendersky  wrote:
> On Sat, Jan 25, 2014 at 7:13 AM, R. David Murray wrote:
> 
> > On Sat, 25 Jan 2014 06:59:19 -0800, Eli Bendersky 
> > wrote:
> > > workplace we had a similar process screwed on top of Jenkins - private
> > test
> > > runs wherein you provide a branch to CI and the CI tests that branch. In
> > > fact, when your test may affect many different architectures, such "try
> > > jobs" are the only way to do unless you really want to build & test a
> > > branch on a few different OSes.
> > >
> > > Once again, this almost always requires some dedicated developers for
> > > watching the tree (Chromium has sheriffs, gardeners, etc.), I'm not sure
> > we
> > > have that for the CPython source.
> >
> > What do sheriffs and gardeners do?
> >
> 
> I started replying but then remembered that it's actually all described
> here - http://www.chromium.org/developers/tree-sheriffs
> If you're interested in such things (build farms, CI, "process") that page
> and links from it should provide you with a lot interesting information

I didn't read past the first part of that, where it said "closes,
throttles and opens the tree" and "tracks down people responsible
for breakage".  This is emphatically *not* the Zuul model, from
what Nick has said.  In Zull, patches don't get *in* to the tree
unless the buildbots are all green with the patch applied (so, no
unit-test-discovered "breakage" can occur in the tree).

Donald answered my question about flaky tests: if a flaky test causes
the failure, whoever is trying to get it integrated can trigger a new
run (referencing the bug that documents the flaky test), and if that
run passes, the patch gets committed.

This makes much more sense to me than the 'sheriff' approach, which is
essentially what we have now, albeit with no formally appointed sheriffs,
and no tree closures.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] PEP 462: Workflow automation for CPython

[R. David Murray]

On Sat, 25 Jan 2014 06:59:19 -0800, Eli Bendersky  wrote:
> On Sat, Jan 25, 2014 at 6:54 AM, Dirkjan Ochtman  wrote:
> 
> > On Sat, Jan 25, 2014 at 2:49 PM, Eli Bendersky  wrote:
> > > Interesting. Chromium has something kind-of similar, named "commit
> > queue",
> > > for developers without actual commit access. Once they get an LGTM, the
> > > thing rolls automatically. In fact, core developers often find it useful
> > too
> > > because the Chromium tree is sometimes closed ("red"). We don't really do
> > > the latter in Python, which carries a problem we'll probably need to
> > resolve
> > > first - how to know that the bots are green enough. That really needs
> > human
> > > attention.
> >
> > Another interesting (and relevant, I think) concept from the Mozilla
> > community is the Try Server, where you can push a work-in-progress
> > patch to see how it does on all the platforms. I.e. it runs all the
> > same tests that build slaves run, but the repository it works against
> > isn't accessible publicly, so you can try your work without breaking
> > the main tree.
> >
> 
> Yep, Chromium has try-jobs too, thanks for reminding me. And in a previous

So do we.  We don't use them much, but that's probably because they are
a relatively new feature of the buildbot farm (the 'custom' builders).

> workplace we had a similar process screwed on top of Jenkins - private test
> runs wherein you provide a branch to CI and the CI tests that branch. In
> fact, when your test may affect many different architectures, such "try
> jobs" are the only way to do unless you really want to build & test a
> branch on a few different OSes.
> 
> Once again, this almost always requires some dedicated developers for
> watching the tree (Chromium has sheriffs, gardeners, etc.), I'm not sure we
> have that for the CPython source.

What do sheriffs and gardeners do?

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] PEP 462: Workflow automation for CPython

[R. David Murray]

On Sat, 25 Jan 2014 06:35:59 -0800, Eli Bendersky  wrote:
> On Sat, Jan 25, 2014 at 6:14 AM, R. David Murray wrote:
> 
> > On Sat, 25 Jan 2014 05:49:56 -0800, Eli Bendersky 
> > wrote:
> > > do the latter in Python, which carries a problem we'll probably need to
> > > resolve first - how to know that the bots are green enough. That really
> > > needs human attention.
> >
> > By "that needs human attention", do you mean: dealing with the remaining
> > flaky tests, so that "stable buildbots are green" is a binary decision?
> > We strive for that now, but Nick's proposal would mean we'd have to
> > finally buckle down and complete the work.  I'm sure we'd make some new
> > flaky tests at some point, but in this future they'd become show-stoppers
> > until they were fixed.  I think this would be a good thing, overall :)
> >
> 
> Non-flakiness of bots is a holy grail few projects attain. If your bots are
> consistently green with no flakes, it just means you're not testing enough
> :-)

How does OpenStack do it, then?  I haven't actually looked at Zuul yet,
though it is on my shortlist.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] PEP 462: Workflow automation for CPython

[R. David Murray]

On Sat, 25 Jan 2014 05:49:56 -0800, Eli Bendersky  wrote:
> do the latter in Python, which carries a problem we'll probably need to
> resolve first - how to know that the bots are green enough. That really
> needs human attention.

By "that needs human attention", do you mean: dealing with the remaining
flaky tests, so that "stable buildbots are green" is a binary decision?
We strive for that now, but Nick's proposal would mean we'd have to
finally buckle down and complete the work.  I'm sure we'd make some new
flaky tests at some point, but in this future they'd become show-stoppers
until they were fixed.  I think this would be a good thing, overall :)

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

[python-committers] svn.python.org SSL cert is expired

[R. David Murray]

So all the buildbots are red for the moment.

A mixture of red and green would have been more appropriate for
today, I think :)

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] 3.4 beta releases and the tracker

[R. David Murray]

On Mon, 02 Dec 2013 17:59:15 -0500, Terry Reedy  wrote:
> On 12/2/2013 5:54 PM, Ethan Furman wrote:
> 
> > Is there an easy way to focus on tracker issues that can be worked on
> > now that feature-freeze is in effect?
> 
> Search (default) Status: open for Type: behavior or Components: 
> documenation.

If you are feeling adventurous, you can also check out how Roundup
constructs its search URLs, and construct one by hand that searches for
all types *except* 'enhancement' or 'performance'.  But searching
for just 'behavior' should get you more than enough to work on.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Anatoly has been warned about his behaviour potentially leading to his loss of tracker privileges

[R. David Murray]

On Sun, 01 Dec 2013 19:29:25 +0100, mar...@v.loewis.de wrote:
> 
> Quoting "R. David Murray" :
> 
> > You should have the necessary privileges on the tracker now, since I
> > think you ought to.  (I don't have them on the meta-tracker, so Martin
> > will need to handle that one.)
> 
> I've restricted anatoly's access there; I've also given you the
> Admin role on that tracker.

Thanks.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Anatoly has been warned about his behaviour potentially leading to his loss of tracker privileges

[R. David Murray]

On Sun, 01 Dec 2013 18:11:47 +0100, mar...@v.loewis.de wrote:
> 
> Quoting "R. David Murray" :
> 
> > On the other hand, I'm not actually sure what kind of access is left
> > when you remove all the roles from a user.  I did notice the other day
> > that email to the tracker still seems to work for new issues (I think
> > it was a new issue, I don't remember the sequence of events for sure),
> > so we may in fact still need to create a new role for this situation.
> 
> I just experimented with this a bit. Removing the User role will also mean
> that you lose the ability to log in ("You are not allowed to login");
> I think it might be better to give the "Anonymous" role (meaning that
> it makes no difference whether you are logged in or not).

That makes sense to me.  Done.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Anatoly has been warned about his behaviour potentially leading to his loss of tracker privileges

[R. David Murray]

On Sun, 01 Dec 2013 12:12:08 +1000, Nick Coghlan  wrote:
> I don't appear to have the necessary tracker access to actually move
> his account to read-only status, though (this change should be made on
> the meta-tracker as well).

You should have the necessary privileges on the tracker now, since I
think you ought to.  (I don't have them on the meta-tracker, so Martin
will need to handle that one.)

On the other hand, I'm not actually sure what kind of access is left
when you remove all the roles from a user.  I did notice the other day
that email to the tracker still seems to work for new issues (I think
it was a new issue, I don't remember the sequence of events for sure),
so we may in fact still need to create a new role for this situation.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Anatoly has been warned about his behaviour potentially leading to his loss of tracker privileges

[R. David Murray]

On Fri, 29 Nov 2013 14:41:22 -0800, Ned Deily  wrote:
> 
> On Nov 29, 2013, at 13:51 , Antoine Pitrou  wrote:
> 
> > On ven., 2013-11-29 at 13:16 -0800, Ned Deily wrote:
> 
> >> Why is it that we find him so annoying, enough to advocate fairly
> >> drastic measures like banning?  There have been and will be others who
> >> behave similarly.
> > I've only been here since 2006 or so, but I can't remember someone
> > behaving like that on such a frequent and long-lived basis. He does
> > stand out.
> 
> I think he stands out in part because we've spotlighted him.

I don't.  There is *no one* else whose name on an email or bug tracker
issue makes my stomach clench up right away(*).  This is based on my
personal interactions with him, not anything I've heard from others.

The most telling thing is that there are times when he is perfectly
reasonable and pleasant.  So it's not like he doesn't know how.
He chooses not to be.

--David

(*) I've gotten better at dealing with this; the negative reaction
doesn't last nearly as long as it used to.  That doesn't make it any
more fun when he's being unpleasant, though.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Anatoly has been warned about his behaviour potentially leading to his loss of tracker privileges

[R. David Murray]

On Fri, 29 Nov 2013 13:16:32 -0800, Ned Deily  wrote:
> 
> On Nov 29, 2013, at 12:12 , Guido van Rossum  wrote:
> 
> > The question is, how effective will the alternative solution
> > (banning him) be? I worry that it's just going to make things worse.
> 
> I think that is a legitimate concern and likely outcome.
> 
> > The key thing to understand here is that you can't win an argument
> > with Anatoly. You can only avoid *getting* into one.
> 
> Right.  We can't change other people's behavior.  We can at best
> encourage change.  In this case, I'm doubtful that banning would serve
> as an encouragement.  I understand the many of us get annoyed and
> frustrated by his comments and the multiple re-opening of the tracker
> issue thing the other day was certainly uncalled-for behavior on his
> part.  But it was likely fueled in part by people's reaction to his

Since his multiple re-openings really are a trigger for us, one possible
mitigation (*not* solution) would be to set up a special tracker account
type just for Anatoly that does not have authorization to edit any
tracker fields once the issue is created.

This is a half-joking suggestion, but only half.

> comments.  I think the more important issue here is not his behavior
> but our behavior in how we react to behavior like this.  *That* is
> something we can reasonably try to change.  Why is it that we find him
> so annoying, enough to advocate fairly drastic measures like banning?

He does not evidence any respect for the community, and so we not only
get defensive, we want to attack back.

> There have been and will be others who behave similarly.  I don't
> propose to try to answer that question: it's one that each of us will
> have our own answer to.

I think that if he is not banned it is important to call him out on
his actions *politely* when his tone is insulting instead of polite, to
indicate to the rest of the community that we value a polite environment.
Other people have changed their behavior when we have done this.
Anatoly has not.  But the message to the rest of the community makes it
worth doing even when Anatoly himself doesn't change.

However...ignoring him can be tough.  Engaging his *valid* points without
letting emotion color the interaction is tougher.  Calling him out on
his bad behavior without letting the emotion in is the toughest.

So yeah, he's a problem no matter which way you slice it.  As Ned
says maybe doing our best to set a good example is the best course.

I'm not against banning him myself, but I'm not particularly for it,
either.  I don't know *what* the best course is here.

--David

PS: Maybe we could set up some mailing list software that, every time
Anatoly starts a new thread, and periodically during it, it posts
an "Anatoly FAQ"? 

Yes, that one *is* 100% a joke.  Or at least 99%.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Your buildbots are out of memory

[R. David Murray]

On Thu, 24 Oct 2013 17:08:11 +0200, Antoine Pitrou  wrote:
> On 2013-10-24 16:59, R. David Murray wrote:
> > 
> > However, it looks like someone has added some tests that use more tmp 
> > space,
> > since the amount of /tmp that exist has been fine up until this point,
> > and the runs on 2.7 and 3.3 are still working.
> > 
> > I can increase /tmp, but I wonder if there is a new test that should
> > be protected with the largefile resource.  Perhaps not,
> > /tmp is currently 16MB on those bots, and I'm not sure what we
> > consider 'large' for test files.
> 
> For test files, I would consider "large" to start around 100MB or more 
> :-)
> 16MB is less than the size of a Python process executing regrtest...
> It's incredibly small.

It's the default value for the /tmp in-memory filesystem on
linux vserver, and like I said it has been enough up to this point.
(Yes it fills up sometimes, but that's because of test failures
in the bsddb tests that don't clean up properly.)

Anyway, based on Antoine's opinion, I've increased the size to 120MB.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Your buildbots are out of memory

[R. David Murray]

On Thu, 24 Oct 2013 10:12:07 -0400, Brett Cannon  wrote:
> FYI if you didn't know

You mean disk space?  I don't get notified automatically when /tmp fills
up with test detritus.  I suppose I should set something up.

However, it looks like someone has added some tests that use more tmp space,
since the amount of /tmp that exist has been fine up until this point,
and the runs on 2.7 and 3.3 are still working.

I can increase /tmp, but I wonder if there is a new test that should
be protected with the largefile resource.  Perhaps not,
/tmp is currently 16MB on those bots, and I'm not sure what we
consider 'large' for test files.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] [RELEASED] Python 3.4.0a2

[R. David Murray]

On Mon, 09 Sep 2013 14:45:51 +0200, Antoine Pitrou  wrote:
> Le Mon, 9 Sep 2013 14:30:50 +0200,
> Victor Stinner  a écrit :
> > 2013/9/9 Larry Hastings :
> > > Python 3.4 includes a range of improvements of the 3.x series,
> > > including hundreds of small improvements and bug fixes.  Major new
> > > features and changes in the 3.4 release series so far include:
> > >
> > > * PEP 446, changing file descriptors to not be inherited by default
> > >in subprocesses
> > 
> > The title of the PEP is "Make newly created file descriptors
> > non-inheritable". It has an impact on all functions creating files and
> > sockets not only the subprocess module.
> 
> I don't think Larry's description is wrong. "Non-inheritable" is a
> shorthand for "non-inheritable in subprocesses" with "subprocesses"
> taken in the general sense (i.e. not only created with the subprocess
> module).

Not wrong, but definitely confusing.  It is worth clarifying *somehow*
that this does not apply only to the subprocess module, which is what
a naive (or fast) reader will assume.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Reminder: Python 3.4 alpha 1 release is Saturday August 3

[R. David Murray]

On Thu, 25 Jul 2013 13:07:59 -0700, Larry Hastings  wrote:
> It's about nine days from now.  I expect to tag the release late next 
> week.  So if you're doing any major brain surgery, please finish it up 
> in the next week or so.

FYI I'm planning on working on some non-trivial stuff for the email
package in August, but it will all go in the "provisional" part of the
library, which will stay provisional for 3.4.  As with the existing
provisional code, it will involve moving some bits of code from the
existing classes into policy hooks on the backward compatibility
policy, and then implementing new features using those same hooks on
the provisional policies.  I don't expect there to be any instability
(that is not some trivial mistake) in the non-provisional code, as the
changes there will be pretty small, and the email package has fairly
extensive tests.

Nothing will land before the Alpha 1 date, and everything should (I
hope!) land before Alpha 2.

--David
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] [Infrastructure] [Pydotorg] XSS security issue

[R. David Murray]

On Mon, 15 Jul 2013 18:02:35 +0200, Antoine Pitrou  wrote:
> On 2013-07-15 17:16, R. David Murray wrote:
> > 
> >> I will make the password available to whoever is in charge, (Or they
> >> can just change the password themselves I don't care).
> > 
> > I think the user should just be retired.  My guess is that it dates 
> > from
> > a time when we were less worried about bad actors coming in and 
> > trashing
> > things just for the fun of it.  What I don't know is if there is some
> > script somewhere depending on it being a valid user.  For now, I've
> > removed its access roles, and we'll see if anything breaks.
> 
> Isn't it the user for automatic Roundup updates from hg pushes?

No, that one is python-dev.  Push updates are still working.

--David
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers