[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 <don...@stufft.io> wrote:
> 
> > On Dec 11, 2017, at 2:52 PM, R. David Murray <rdmur...@bitdance.com> 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" <rdmur...@bitdance.com> 
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 <nas-pyt...@arctrix.com> 
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] 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 <br...@python.org> wrote:
> On Fri, 23 Jun 2017 at 09:28 R. David Murray <rdmur...@bitdance.com> 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 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.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 <victor.stin...@gmail.com> 
wrote:
> 2016-05-24 15:42 GMT+02:00 R. David Murray <rdmur...@bitdance.com>:
> > 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 <n...@python.org> wrote:
> In article <20160523174004.cb04eb14...@webabinitio.net>,
>  "R. David Murray" <rdmur...@bitdance.com> 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] 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] We will be moving to GitHub (hopefully) in 2016

[R. David Murray]

On Tue, 05 Jan 2016 01:26:58 +, "Gregory P. Smith" <g...@krypto.org> wrote:
> On Mon, Jan 4, 2016 at 12:34 PM R. David Murray <rdmur...@bitdance.com>
> 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] 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 <storch...@gmail.com> 
wrote:
> On 23.11.15 18:00, R. David Murray wrote:
> > On Mon, 23 Nov 2015 00:58:01 -0600, Zachary Ware 
> > <zachary.ware+py...@gmail.com> 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] 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 rdmur...@bitdance.com 
wrote:
 On Sun, 16 Aug 2015 00:13:10 -0700, Larry Hastings la...@hastings.org 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 merging forward from the Bitbucket 3.5 repo?

[R. David Murray]

On Sun, 16 Aug 2015 00:13:10 -0700, Larry Hastings la...@hastings.org 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 robe...@robertcollins.net 
wrote:
 On 11 August 2015 at 10:38, Brett Cannon bcan...@gmail.com 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 n...@acm.org wrote:
  On Aug 9, 2015, at 14:19, Brett Cannon bcan...@gmail.com 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

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

[R. David Murray]

On Wed, 29 Jul 2015 13:41:09 -0400, Terry Reedy tjre...@udel.edu wrote:
 On 7/29/2015 1:01 PM, Robert Collins wrote:
  On 30 July 2015 at 04:50, Guido van Rossum gu...@python.org 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] Gratuitous? incompatibilities in the fix only releases

[R. David Murray]

On Thu, 30 Jul 2015 00:11:53 +0200, Jesus Cea j...@jcea.es 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

[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] Code review tool 500 error

[R. David Murray]

On Wed, 13 May 2015 15:43:17 -0400, Yury Selivanov yselivanov...@gmail.com 
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 gu...@python.org 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

[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] Mark Lawrence

[R. David Murray]

On Sun, 05 Oct 2014 14:47:06 -0400, Benjamin Peterson benja...@python.org 
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

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 victor.stin...@gmail.com 
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 la...@hastings.org:
 
 
  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 Tue, 15 Apr 2014 23:21:41 -0400, Terry Reedy tjre...@udel.edu 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] 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] New mailing list for workflow/workflow infrastructure discussion/tasks

[R. David Murray]

On Wed, 16 Apr 2014 18:02:31 -0400, Terry Reedy tjre...@udel.edu 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] 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 et...@stoneleaf.us 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] PEP 462: Workflow automation for CPython

[R. David Murray]

On Sat, 25 Jan 2014 09:35:46 -0800, Eli Bendersky eli...@gmail.com wrote:
 On Sat, Jan 25, 2014 at 7:13 AM, R. David Murray rdmur...@bitdance.comwrote:
 
  On Sat, 25 Jan 2014 06:59:19 -0800, Eli Bendersky eli...@gmail.com
  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 05:49:56 -0800, Eli Bendersky eli...@gmail.com 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

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

[R. David Murray]

On Sat, 25 Jan 2014 06:35:59 -0800, Eli Bendersky eli...@gmail.com wrote:
 On Sat, Jan 25, 2014 at 6:14 AM, R. David Murray rdmur...@bitdance.comwrote:
 
  On Sat, 25 Jan 2014 05:49:56 -0800, Eli Bendersky eli...@gmail.com
  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] 3.4 beta releases and the tracker

[R. David Murray]

On Mon, 02 Dec 2013 17:59:15 -0500, Terry Reedy tjre...@udel.edu 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 18:11:47 +0100, mar...@v.loewis.de wrote:
 
 Quoting R. David Murray rdmur...@bitdance.com:
 
  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 ncogh...@gmail.com 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 13:16:32 -0800, Ned Deily n...@acm.org wrote:
 
 On Nov 29, 2013, at 12:12 , Guido van Rossum gu...@python.org 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] 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 n...@acm.org wrote:
 
 On Nov 29, 2013, at 13:51 , Antoine Pitrou anto...@python.org 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] Your buildbots are out of memory

[R. David Murray]

On Thu, 24 Oct 2013 10:12:07 -0400, Brett Cannon br...@yvrsfo.ca 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] Your buildbots are out of memory

[R. David Murray]

On Thu, 24 Oct 2013 17:08:11 +0200, Antoine Pitrou anto...@python.org 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] 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 la...@hastings.org 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 11:09:08 +0300, Michael Foord mich...@voidspace.org.uk 
wrote:
 
 On 15 Jul 2013, at 11:05, M.-A. Lemburg m...@python.org wrote:
 
  Who would be the one to contact for issues like these ?
  
  The case is rather urgent, since the XSS can be used for stealing
  session cookies on *.python.org.
  
  The sorting by password issue is a more obscure one. Just removing
  the feature to sort by password should be enough to solve it.
 
 Technically it's an infrastructure issue (cc'd), but fixing the code of 
 roundup is hardly their domain.
 
 Ezio Melotti (cc'd) did a lot of work on the Python installation of roundup, 
 so he may have a better idea.
 
 We have a security mailing list but that is mainly intended for security 
 issues in the language:
 
   secur...@python.org secur...@python.org

The OP also emailed security (which I heard about via IRC, I'm not
on that list).

Ezio is a Roundup developer, so he is indeed the best person to look
at the XSS issue, since it is a Roundup problem and not specific to
the Tracker.  I can take a look too but he is more knowledgeable
than I about roundup itself.

There is another problem which is specific to our tracker and which is the
bigger issue right at the moment.  We have a 'nobody' user with a blank
password and Developer privileges.

I'm about to go out, so I don't want to make a change that might break
something right this moment, but anyone with the Coordinator role
could take this on if they want to do it right now:  remove either the
Developer role, or both roles, from that user and see what happens.
I suspect that user should not exist at all, but I don't know for sure.

--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 08:22:40 -0400, Donald Stufft don...@stufft.io wrote:
 So I was able to log in to the nobody account without a password
 (Why is this even possible?). It gave me powers to edit users and some
 other shit. I added a password to the nobody account since these lists
 are publicly available and if I can get into that user so can others.

Ah, I didn't realize you could edit users (I thought that was
Coordinator role) or I would have changed the password myself.

 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.

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

Re: [python-committers] Policy for committing to 2.7

[R. David Murray]

On Sat, 22 Jun 2013 15:35:41 -0400, Barry Warsaw ba...@python.org wrote:
 On Jun 22, 2013, at 12:02 PM, Eli Bendersky wrote:
 
 I may be missing something, but do we have a policy of what we're supposed
 to commit to the 2.7 branch at this point? I was under the impression that
 it's only bug fixes, documentation, and maybe tests. But it seems that
 there are developers who see it otherwise.
 
 Strongly agree.  One additional allowed category of changes are build system
 fixes, e.g. so that 2.7 can still be built on newer versions of operating
 systems it already supports.
 
 It would be great if we could document this somewhere - the 2.7 branch is
 not a usual bugfix-mode branch, I realize, and hence maybe there's some
 special treatment it deserves.
 
 IMO, Benjamin being the 2.7 RM has ultimate[1] say in the matter.  I'm very
 glad he's conservative in what he allows in the branch.

My understanding is that there is an additional category that we allow
beyond what Barry mentioned:  things that add support for stuff that
is analogous to the build enhancements:  platform changes we really want
to support that are trivial to add.  The non-controversial example of
this is adding mime types.  The somewhat more controversial (but we've
done it, IIRC) is adding support for new browsers (ie: Chrome) to the
webbrowser module.

But IMO we should be considering the 2.7 branch to be starting to harden
into immobility at this point.  The bar for even bug fixes to be applied
to 2.7 should be higher than for 3.3, and should continue to get higher
still as time passes.

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

Re: [python-committers] what's going on with Misc/NEWS?

[R. David Murray]

On Fri, 24 May 2013 18:39:16 +0200, Antoine Pitrou solip...@pitrou.net 
wrote:
 Brett wrote:
  Of course, we've talked about doing something like this before, it's
  just never irritated anyone enough for them to sit down and *write*
  the associated NEWS file generator, or the code to split the existing
  NEWS file for the active branches :)
 
  I think that's overly complicated.
 
 Agreed. I'm not surprised Twisted uses something like that :-), but we
 don't need
 that level of complexity.
 
  I don't see why we need anything
  more than simply NEWS/3.4, NEWS/3.3, etc. and just split the files per
  feature release since that's the interest (and merge) boundary.
 
 You'll have to copy stuff by hand, though, if you don't want to rely on the
 merge machinery. So we have two possible file layouts:
 
 * (current) a single Misc/NEWS is merged from branch to branch. Pro: hg merge
 copies the text for you. Con: hg merge sometimes screws up and you have to
 clean up a large conflict.
 
 * a dedicated Misc/NEWS-x.y per major version. Pro: no merge conflicts ever.
 Con: you have to copy the message by hand when merging a bug fix to the upper
 branch. Con: it's easy to forget to copy the message (hg won't yell if you
 don't
 do it), so people *will* forget (and it's annoying grunt work for those who
 notice it).
 
 The major con with the current scheme *might* be solved by a dedicated hg
 extension, but someone needs to have enough free time and passion to try and
 write it :-)

I agree with Antoine here.  I'd rather deal with the occasional conflicts
(which goes: revert Misc/NEWS change, copy news entry) and get automatic
merge some of the time, rather than have to *always* remember to copy
the news entry, with no warning if I forget.  The current way either
the merge works[*], or you get an error reminding you you have to do the
revert/copy dance.

--David

[*] So far I haven't had a case of what sometimes happened in svn,
where the merge would appear to work but would be in the wrong
section. I think this is because we moved stuff to HISTORY, or it
may be that hg merge is just smarter than svn merge.
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] what's going on with Misc/NEWS?

[R. David Murray]

On Fri, 24 May 2013 15:26:29 -0400, Brett Cannon br...@python.org wrote:
 On Fri, May 24, 2013 at 2:27 PM, Antoine Pitrou solip...@pitrou.net wrote:
  Le vendredi 24 mai 2013 à 14:23 -0400, Brett Cannon a écrit :
   You'll have to copy stuff by hand, though, if you don't want to rely on 
   the
   merge machinery. So we have two possible file layouts:
  
   * (current) a single Misc/NEWS is merged from branch to branch. Pro: hg 
   merge
   copies the text for you. Con: hg merge sometimes screws up and you have 
   to
   clean up a large conflict.
 
  But hg won't let you simply revert;
 
  hg rev -r branch name Misc/NEWS
 
 I'll add that to the devguide if it works for me next time.
 
I find that I also have to do:

hg resolve -m Misc/NEWS

which I find to be a really obnoxious mis-feature of hg.

  Do you mean Mics/NEWS doc typos?
 
 No I mean typos in the docs. For instance, I found a missing
 parenthesis in the docs for some module, but backporting it is enough
 of a pain that I don't want to bother. The only reason I did this one
 for sys is because it clarified semantics.

You're adding a NEWS entry for a single character doc typo?  No wonder
you don't like making doc fixes :)

I only make news entries for doc changes when they are major or are
changes to the doc *system*.

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

Re: [python-committers] what's going on with Misc/NEWS?

[R. David Murray]

On Fri, 24 May 2013 15:16:24 -0600, Gregory P. Smith g...@krypto.org wrote:
 On May 24, 2013 2:55 PM, Antoine Pitrou solip...@pitrou.net wrote:
 
  Le vendredi 24 mai 2013 à 16:22 -0400, Brett Cannon a écrit :
   
I don't understand why it's painful to backport. Can you explain?
  
   If I make a very minor fix to the docs I have to:
  
   # In a 3.3 checkout
   Fix docs
   Compile docs
   Add Misc/NEWS entry
   hg ci -m repeat what I just said in Misc/NEWS
   hg push
   cd ../default
   hg merge 3.3
   Fix/revert Misc/NEWS (at least)
   Compile docs (if fix is needed)
   hg ci
   hg push
 
  I honestly don't understand why you would mention doc fixes (even major
  ones) in Misc/NEWS. It's not a useful piece of information to have
  there. People want to know about bug fixes because they are affected by
  bugs, but doc fixes??
 
 I think you misunderstood what he meant. Misc/NEWS is documentation. I
 believe he meant he won't fix typos in NEWS due to the make pain involved.

No, he really meant he created a news entry for a doc change.  For a
reasonable reason, in the example he gave :)

But you certainly don't need a news entry for typos, or most other
doc changes, IMO.

 I'm the same way. I want nothing to do with news when making my changes
 because it ALWAYS gets in the way for any change not being done on
 head/default/tip only. If anything I prefer to leave news entries out of
 the commit they are related to to avoid news merges going wrong from
 messing up the real change. Hopefully I remember to write a news entry for
 it after the fact.

In the subversion days almost every merge I did had a NEWS conflict.
With hg, I only get a merge conflict if the most recent change to NEWS
is a 3.3-only entry.  So, maybe half the time.  (I suppose if people
are really sticking entries in randomly I might start seeing more
conflicts...)

I have no objection to the process being improved if someone is willing
to do the scripting to improve it.  I personally would prefer not to
simply have the files have different names, meaning I'd have to copy the
news entry all the time instead of half the time.  But my objection is
only about -0.25, so if more people prefer making the file names different
in the absence of a better scripted solution, I'll live with it :)
I just hope we don't start losing NEWS entries as as result.

Oh, and my news entries are almost never the same as my commit one-lines,
partly because I keep the commit line to *one* line, whereas the NEWS
entry is typically two to three.  Keeping the first commit line to one
line makes reading the log easier, IMO; but I suppose since not everybody
does that it's really just a quirk :)

But even without that the messages would different.  As someone else
mentioned, I feel that the audiences are different...and in the commit
message I assume that you are seeing the list of changed files as well,
to give you context for the commit message that isn't present in the
NEWS entry.

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

Re: [python-committers] Please don't commit to 3.2 branch anymore

[R. David Murray]

On Sat, 30 Mar 2013 13:41:39 +0100, Jesus Cea j...@jcea.es wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 28/03/13 08:55, Georg Brandl wrote:
  with 3.2.4 being the last regular 3.2 maintenance release and the
  rc out of the door, the 3.2 branch should only be committed to for
  security releases.  So please don't commit anything there anymore.
  To help everyone remember, I've configured the push hook to reject
  changesets to the 3.2 branch.
 
 What is the procedure for commiting security fixes?. Is it documentes
 anywhere?

This is the first time we've been in the situation of having a
security-only branch in Mercurial (other than 2.7, which is its own head).
So I don't believe we have articulated a procedure yet.

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

Re: [python-committers] SSH fingerprint

[R. David Murray]

Note that I believe ECDSA is now the default for host keys for OpenSSH.
At the least, my systems (Gentoo) switched to them after an upgrade a
a bit a go.

--David

On Mon, 25 Mar 2013 13:29:48 +0100, Christian Heimes christ...@python.org 
wrote:
 Am 25.03.2013 05:51, schrieb Jeffrey Yasskin:
  You missed that ECDSA != DSA.
 
 Yeah, Elliptic Curve DSA is as secure as RSA while using much shorter
 keys. ECDSA verification used to be much slower so you may want to
 prefer RSA for short time connections like hg pull and push.
 
 Christian
 ___
 python-committers mailing list
 python-committers@python.org
 http://mail.python.org/mailman/listinfo/python-committers
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] [Infrastructure] test suite dependencies on www.python.org

[R. David Murray]

On Wed, 20 Mar 2013 12:47:09 -0700, Noah Kantrowitz n...@coderanger.net wrote:
 +1 on let them break, but when they get fixed it should be against a
 dedicated testing endpoint if possible, preferably something internal
 to the test suite. Maybe spawn an HTTP server in a background
 thread/proc? I would very much like the web infra to not be a runtime
 dependency if possible.

Keep in mind that it isn't only us running the test suite; but, yeah,
this is what we've done in the past.  Just don't do the cutover near
when one of the release managers is trying to produce a release :)

We've been converting tests to use internal services as we've noticed them
for one reason or another, and when possible.  The example I quoted should
be converted.  There are tests that we don't have the infrastructure
to move into the test harness, but I don't think any of the ones that
reference www.python.org should be among those at this point.

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

Re: [python-committers] Commit privileges for Roger Serwy for IDLE

[R. David Murray]

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

Re: [python-committers] [Infrastructure] test suite dependencies on www.python.org

[R. David Murray]

On Mon, 18 Mar 2013 15:17:23 -0700, Noah Kantrowitz n...@coderanger.net wrote:
 As part of the PyCon sprints I would like to move python.org off
 dinsdale to a VM at OSL. Due to the build system being tied to SVN,
 I'll also migrate that service on the same VM. Do any SVN repos other
 than www/ need to remain available? This would require at least some
 period of not changing the website, probably a few hours, but I don't
 think that would be a problem. This is mostly a legacy move so I'm not
 going to clean it up much, we'll have a new site soon enough.

While working on tests at the sprint I was reminded that there are
various tests in the Python standard library that depend on resources in
specific resources in specific locations at python.org.  We will need
a plan for finding and dealing with these before (or as?) the new web
site is turned up.

Example:

request = urllib.request.Request(http://www.python.org/~jeremy/;)

And then there are things like:

h = client.HTTPSConnection('svn.python.org', 443, context=context)

I don't think there are a huge number of these, but we will need to
deal with them.

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

Re: [python-committers] Tracker settings for Peter Moody

[R. David Murray]

On Sat, 16 Mar 2013 15:25:56 +0100, Georg Brandl g.bra...@gmx.net wrote:
 Am 16.03.2013 15:01, schrieb Nick Coghlan:
  Could someone with sufficient privileges please flip Peter Moody's
  commit bit in the tracker: http://bugs.python.org/user9293
 
 Done.
 
  Reminder to everyone else: if you have commit privileges, but don't
  have the Python logo showing up next to your name on bugs.python.org
  (and have Is Committer: No in your user profile)
 
 Also, the Role field should be User,Developer.
 
 , we missed a step
  when granting you commit access, and it needs to be fixed so you
  appear in the Assigned To dropdown properly. (the nosy magic draws
  from the experts index instead, so it can work even if this setting is
  wrong)

It's the 'Developer' role that puts one in the dropdown (and allows
editing of all issue fields).  Which is why triage people appear in the
assigned-to even though they aren't committers (yet :).

The committer flag only controls the icon, as far as I remember.

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

Re: [python-committers] echosign

[R. David Murray]

On Mon, 04 Mar 2013 10:29:23 -0500, Jesse Noller jnol...@gmail.com wrote:
 On Monday, March 4, 2013 at 10:24 AM, R. David Murray wrote:
 
  I applaud the foundation for getting an electronic signature method in
  place.
  
  However, I have to say that to my mind echosign is nothing more than
  authentication theater, and I wonder if it is going to make us look
  more than a bit clueless to the tech community. I'm surprised that
  a lawyer would consider a signature generated from typed text to be
  useful for anything. If you are are going to accept the typed signature,
  just accept the typed signature.
  
  I was asked to sign a legal document I cared about that way once and I 
  refused.
  
  At least there's a way to upload a real signature.
  
  --David

 You mean like OpenStack who also uses this? And Opscode, Eucalyptus, and 
 others? 

Sure, it's fine to be using it, if the legal community for some reason
wants it.  And very I'm grateful that the system was put in place.

But I won't change my opinion that it is authentication theater, and
the existence of that theater component makes me sad.  And apparently
I can be sad not just for us, but for those other organizations that
indeed I was not aware were using it.

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

Re: [python-committers] echosign

[R. David Murray]

My apologies for sounding a sour note, by the way, I think I was unduly
influenced by my previous (very poor, from a UI perspective) experience
with a system like this, and had a knee-jerk reaction.

I think it is great that this system has been put in place, and my
thanks to all involved.

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

Re: [python-committers] echosign

[R. David Murray]

On Mon, 04 Mar 2013 10:58:57 -0500, Jesse Noller jnol...@gmail.com wrote:
 On Monday, March 4, 2013 at 10:55 AM, Antoine Pitrou wrote:
 
   My apologies for sounding a sour note, by the way, I think I was unduly
   influenced by my previous (very poor, from a UI perspective) experience
   with a system like this, and had a knee-jerk reaction.
   
   I think it is great that this system has been put in place, and my
   thanks to all involved.
  
  It is certainly great indeed (I say that without having seen the UI,
  though).

 it's an iframe and some javascript wizardry widgeting. Nothing to write home 
 to mom about. 

It can probably stand some tweaks(*), but it is *much* better than the
one I encountered before.

--David

(*) Not sure where to report this, so: I was confused by the fact
that I'd filled in the blanks, but clicking on the 'esign' button did
nothing except post a message that I needed to fill in all the required
fields...which I had already done.  Turns out I needed to scroll the
sub-window down in order to see the additional button to click for signing
the document.  The confusion could be cleared up by either having the
entire document show without scrolling, or by changing the final button
label from 'esign' to 'submit' (or doing both).
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] WANTED: leader for the core sprint at PyCon US (was: I will NOT be leading the core sprint at PyCon US this year)

[R. David Murray]

On Tue, 26 Feb 2013 12:43:04 -0500, Brett Cannon br...@python.org wrote:
 On Tue, Feb 26, 2013 at 12:16 PM, Guido van Rossum gu...@python.org wrote:
  So we have nobody to lead the core sprint?
 
 ATM no.
 
  Maybe we should change the
  subject to WANTED: core dev sprint leader for PyCon ?
 
 Done.
 
  Is this the
  best list, or should it go to python-dev?
 
 This list. It should be an experienced core dev and not any random person
 who happens to subscribe to python-dev and is willing to do it. Otherwise
 it would be no better than writing the URL to the devguide on a piece of
 paper and saying have at it. =)

Given a little support from Brett on how best to go about it, I'm willing
to volunteer for this.

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

Re: [python-committers] PyCon US 2013 attendees

[R. David Murray]

I'll be there the whole time (summit through the end of the sprints).

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

Re: [python-committers] Contributor Agreement - David Lam

[R. David Murray]

On Mon, 28 Jan 2013 12:53:10 -0500, Kurt B. Kaiser k...@shore.net wrote:
 We received a contributor agreement by postal mail
 
 David Lam
 211 E. Meadow Dr
 Palo Alto CA 94306
 
 d...@dlam.me
 
 I've added it to the local paper files

I've updated his tracker entry to reflect receiving the form as of
today's date.

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

Re: [python-committers] Anatoly Techtonik's contribution

[R. David Murray]

On Wed, 26 Dec 2012 02:36:08 -0500, Terry Reedy tjre...@udel.edu wrote:
 This is a continuation of my answer to Christian
 
 On 12/25/2012 5:56 PM, Łukasz Langa wrote:
  1. Communicate what happened clearly and openly to our community.
 
 I am not sure how broadly you mean 'our community', but please no. 
 Nothing need or should be said beyond this list. (Unless Anatoly says 
 something elsewhere -- but let him be the first.
 
 Spam accounts and messages on the tracker are routinely cancelled 
 without notice. The one time I know of that a contributor was banned 
 (suspended, actually, soon followed by an offer of re-instatement 
 without admin privileges), it was pretty much handled privately (though 
 I would have preferred notice on this list first).

And this private action had unintended negative consequences.  I think
anyone who wants to take action on Anatoly should go back and read the
threads surrounding Breamorboy's tracker suspension and what happened
afterward.  I believe the conclusion was that in the future any such
actions should be discussed publicly (at a minimum on this list, so we
are covering that) before action was taken, but despite having been a
principal in that mess I don't remember for sure.

  2. Communicate to Anatoly the decision to cut him off.
 
 I think any cut-off should be in stages: tracker, pydev, python-ideas.
 Anything beyond the tracker should be approved by Guido.

I agree that incident specific actions are better than a broad ban.

If Guido wants to take responsibility for any of it, that's fine,
but I don't think we should put that burden on him automatically.
My understanding is that he signed up to be language dictator, not
community dictator.

 As far as the tracker goes, I think it should be clearly communicated to 
 him and everyone in plain English (and specified in the user guide if 
 not already) that a) the purpose of the tracker is to help committers 
 receive reports, communicate with reporters and others, and to manage 
 issues, and b) after an initial report, the administrative fields are 
 mostly intended for the use of tracker administrators, including 
 committers. The only reason a submitter can edit the status field is so 
 that they can close an issue to withdraw it (possible after review). If 
 we can enforce that in the database (only admins (or possibly only 
 committers) but not the submitter can reopen), I think we should! That 
 would eliminate bogus reopenings by anyone, not just Anatoly.

The tracker fields used to be more restrictive, and we have been
gradually loosening them over time.  With the exception of Anatoly,
this has been a successful experiment, and I am reluctant to reverse
that trend.  I would hate to see one bad actor result in restrictions
on everyone.

 I say this because he specifically justified his re-open action on the 
 basis that *he* also uses the tracker to track issues. So he does not 
 quite understand what it is for. As I said in my previous post, if he 
 reopens a third time, act. He has not yet that I have seen. I also 
 notice that he just 'voted' to reopen http://bugs.python.org/issue7083 
 but did not do so himself (possible because he cannot).
 
 Going a bit further, I actually would not let a non-admin submitter edit 
 any field as long as an issue is closed. I see this as a sensible 
 refinement of the database policy based on years of experience and not 
 directly specifically at Anatoly. Another tweak based on experience 
 would be that only committers can set version to security issues. I 
 routinely unset 2.6 and 3.1 with a short explanation. Better that the 
 ignorant cannot even make that mistake (I know, submit to the metatracker.)

I have often told submitters in issues that I have closed that if they
come back with more evidence or a patch they should reopen the issue.
So again I would prefer not to restrict functionality because of one
bad actor.

   preparing also for vengeful action (which given
  the history is unfortunately likely).
 
 Shaming anyone publicly is more likely to get such action, and would 
 almost make it justified in my view.

Anatoly has been shaming us publicly for years.  We would be much more
polite and rational in any more-public statement made (I trust).  We
would still draw fire.  That may or may not make us stronger in the
long run...for it to do so we will, in fact, need to have a principled
position to rest upon, and thus I think we would be well recommended
to have something PEP-like in terms of a policy statement.

I wonder if a public discussion aimed at developing such a policy
would clue Anatoly in (probably not).  I wonder what other communities
have done.  I know Python is one of the leaders in the COC matter,
so perhaps we will have to be a leader here as well.

This is not easy stuff.

  4. Prepare for rectifying unjust PR by the banned person, etc.
 
 Better to not unnecessarily provoke it, and worry about it when it 
 actually happens.

No, it is a