Re: [python-committers] [Python-Dev] Proposed release schedule for Python 3.5.4

2017-06-23 Thread Victor Stinner 
2017-06-22 17:56 GMT+02:00 Brett Cannon :
> On Thu, 22 Jun 2017 at 02:32 Larry Hastings  wrote:
>> Seriously, though, I was mostly hoping other people would handle the
>> security stuff and just keep me informed.  If I'm the only one permitted to
>> accept PRs into 3.4 (and soon 3.5), okay, I can work with that.  I'm still
>> probably gonna delegate the actual judgment of the validity of the PRs.  But
>> obviously it'll mean I'll have to be more hands-on, where so far I was
>> assuming I could just let other people handle it.
>
> Currently the security-only branches are set so that only release managers
> can merge PRs since they technically are on the hook if some compatibility
> breaks due to some patch (e.g. I expect Ned to use this for 3.7 once we hit
> rc to really control what goes in last minute). It's easy enough to turn
> this protection off, though, if people want.

Larry: would you be ok to turn this protection off on the 3.4 branch?
Or would you feel more confortable if only a few people would be
allowed to push to the 3.4 branch, so add me a whitelist group or
something like that?

As I wrote, my plan is not only to merge my security fixes, but also
to work on a CI. I would feel more confortable to see the Travis CI
test result on my security PRs.

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

Re: [python-committers] [Python-Dev] Proposed release schedule for Python 3.5.4

2017-06-23 Thread Larry Hastings 

On 06/23/2017 01:55 AM, Victor Stinner wrote:

Larry: would you be ok to turn this protection off on the 3.4 branch?
Or would you feel more confortable if only a few people would be
allowed to push to the 3.4 branch, so add me a whitelist group or
something like that?


Actually I kind of like the idea of the branch being restricted. Let's 
try it for now and see if it works.




As I wrote, my plan is not only to merge my security fixes, but also
to work on a CI. I would feel more confortable to see the Travis CI
test result on my security PRs.


Do you need write access to the branch in order to get Travis CI working?


//arry/
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] [Python-Dev] Proposed release schedule for Python 3.5.4

2017-06-23 Thread Victor Stinner 
2017-06-23 15:19 GMT+02:00 Larry Hastings :
> Do you need write access to the branch in order to get Travis CI working?

As soon as someone reviews my proposed 3.4 patches, no :-) I will work on a PR.

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

Re: [python-committers] Proposed release schedule for Python 3.5.4

2017-06-23 Thread Larry Hastings 

On 06/21/2017 07:58 PM, Larry Hastings wrote:
If you have any feedback / concerns about this schedule, or if you 
think it's important that I release 3.4.7 with these minor changes, 
please reply here.  If I don't hear anything back in a day or two I'll 
go ahead and make this the official schedule.


I haven't heard any concerns, so I'm declaring that the official 
schedule for 3.5.4, and I'm not scheduling 3.4.7 at this time.



//arry/
___
python-committers mailing list
[email protected]
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?

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

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

--David
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Reminder! Today's the last day for core sprint sign-ups!

2017-06-23 Thread Guido van Rossum 
[Was:  Core sprint 2017 - Sep 4 - Sep 9, Menlo Park, California]

On Mon, Jun 12, 2017 at 4:04 PM, Lukasz Langa  wrote:

> Hello fellow committers!
> I'm organizing another core sprint this year to make Python 3.7 the best
> release possible.
>
> *WHY*:
> 1. *Community*.  The sprints at the end of PyCon are great but they
> mostly get the same people in the room year after year.  Many of the most
> active contributors never attend conferences.  My goal with this sprint is
> to bring together many core devs who rarely if ever meet!
> 2. *Focus*.  When we have sprints at the end of a conference, many of us
> are pretty tired and less productive than we could have been without the
> late dinners, endless hallway sessions, and so on.  Some of the sprinters
> are preoccupied with tutoring newcomers.  This sprint won't be after a
> major conference, and it's only for seasoned CPython core devs--so get to
> work!
> 3. *Communication*. There are tremendous benefits to getting everyone
> together in one big room.  Conversations that drag on on python-dev can be
> solved quickly in person.  Even contentious debates become faster, easier,
> and more civil.  And meeting face-to-face helps us all feel more connected
> to our community.
>
> *WHY THE BAY AREA*: We have a large population of core contributors
> here.  Also, I can arrange for Facebook to provide us a "war room" for the
> whole week, with full access to the campus during the sprints. That
> includes free food for breakfast, lunch, dinner, and snacks, compatible
> with almost any dietary restrictions.
>
> *WHY EARLY SEPTEMBER*: It's almost impossible to find a time that doesn't
> overlap with a PyCon. This week worked well last year so we're redoing it
> that way. Monday September 4 is Labor Day in the US, which may make it
> easier for employees of US companies to attend, as they'd only be taking
> off four days instead of five.
>
> *HOW LONG*: A full week Monday, Sep 4 to Friday, Sep 8 evening. You can
> check into your hotel the day before the sprint (Sunday, Sep 3) and check
> out the day after (Saturday, Sep 9).
>
> *HOW BIG*: No fewer than 10, no more than 20.  More than 20 people would
> be great but it'd be hard for me to organize a sprint that big.
>
> *WHO PAYS*: The venue, hotels, and food are provided by Facebook. I'm
> working on getting flight reimbursements. Last year they were provided by
> the Python Software Foundation. Anybody is free to waive their
> reimbursement.
>
> *PLEASE REPLY*: If you're interested in attending and have the commit bit
> on GitHub's python/cpython, fill out this Google Form:
> https://goo.gl/forms/MzrNtRe0NAmzvGwF2
>
> *DISCLAIMER*: I'd like to be able to host everybody. However, if I
> receive more than 20 applications, this is not going to be possible. In
> this case, the following will happen:
>
> 1. I will look at your current level of involvement in CPython
> development. This includes metrics like commits / PRs, activity on the bug
> tracker and python-dev, special role (release manager, infrastructure dev,
> etc.).
> 2. I will look at your sprint plan and ability to participate in the
> entire sprint (per answers to the questions above).
> 3. I will gather all this data and leave the final decision to our
> Benevolent Dictator (who is also attending the sprint). This is one of
> those occasions where having a dictator is useful.
>
> *DON'T WAIT*: September is closer than you think! Please let me know as
> soon as possible so we can start setting up the event. I'm going to close
> the sign-up form on June 23rd.
>
> Organizational-ly yours,
> Ł
> Vice-Minister of Silly Sprints
>
> ___
> python-committers mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>


-- 
--Guido van Rossum (python.org/~guido )
___
python-committers mailing list
[email protected]
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?

2017-06-23 Thread Brett Cannon 
On Fri, 23 Jun 2017 at 09:28 R. David Murray  wrote:

> On Wed, 21 Jun 2017 13:37:22 -0700, Mariatta Wijaya <
> [email protected]> 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).
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] New workflow change: Welcome to blurb

2017-06-23 Thread Larry Hastings 



One minor but ongoing problem we've had in CPython core development has 
been the mess of updating Misc/NEWS.  Day-to-day developers may have a 
conflict if they lose a push race, which means a little editing.  You'll 
have a similar, if slightly worse, problem when cherry-picking a fix 
between versions.  Worst of all used to be the manual merges necessary 
after cutting a release--this was the bane of a CPython release 
manager's existence.  (Though the new git-based workflow may have 
obviated the worst of this.)


The real problem is that we have one central file that everybody 
continually edits in a haphazard way.  We aren't actually editing the 
same information, we aren't actually changing the same lines. But our 
revision control systems and diff algorithms don't understand the 
structure of Misc/NEWS and so they get confused. And for what? It's not 
like there's a tremendous benefit to having this central file everyone's 
fighting over.


We've been talking about addressing this for years.  Fixing this was one 
of the goals of the new workflow.  And finally, as of right now, the 
future is here.  Ladies and gentlemen, I present: blurb.


   https://github.com/python/core-workflow/tree/master/blurb


blurb is an interactive command-line tool that helps you write Misc/NEWS 
entries.  You simply run blurb from anywhere inside a CPython repo.  
blurb runs an editor for you with a template open. You fill in these 
three pieces of information:


 * the bugs.python.org or "bpo" issue number,
 * what "section" of Misc/NEWS this entry should go in (by uncommenting
   the correct line), and
 * the text of the Misc/NEWS entry, in ReST format.

You save and exit and you're done.  blurb even stages the Misc/NEWS 
entry in git for you!



Behind the scenes, blurb writes your information here:

   Misc/NEWS.d/next//

The "" is the name of the section in Misc/NEWS where your 
entry should go.   contains the current date and time, the bpo 
number, and a nonce to prevent collisions.


These "next" files get merged together into a single aggregate .rst file 
by the release manager when cutting a release (using "blurb release").  
One nice feature of this approach: when you cherry-pick a change, its 
Misc/NEWS entry in "next" gets cherry-picked along with it.



One important change: Misc/NEWS will no longer be checked in. It'll 
still be present in CPython tarballs; it will be generated by the 
release manager as part of cutting a release.  But as a repository of 
information, it's been superseded by the various blurb data files.  And 
by regenerating it from data files, we ensure that we'll never ever have 
a Misc/NEWS conflict ever again!


The plan is to leave Misc/NEWS in the CPython repo for maybe another 
week, to let the current crop of PRs get merged.  But new work should 
switch to using blurb immediately.



You can install blurb from pip:

   % pip3.6 install blurb

In fact--please do!


//arry/
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] [Python-Dev] New workflow change: Welcome to blurb

2017-06-23 Thread Steve Dower 
One quick heads up – the NEWS file is included in the docs build (if not in the 
html docs, certainly in the CHM for Windows releases). You may have to do some 
extra work to keep that from breaking when you remove it. We might also include 
it as plain text in the installers, I forget right now.

Is blurb going to be embedded in the main repository? Not necessarily a problem 
if not, but I'd rather not have the build process depend on pip. Though I guess 
Sphinx is dependency already, so perhaps I should just integrate it better into 
the build…

Top-posted from my Windows phone

From: Larry Hastings
Sent: Friday, June 23, 2017 20:26
To: Python Dev; python-committers
Subject: [Python-Dev] New workflow change: Welcome to blurb



One minor but ongoing problem we've had in CPython core development has been 
the mess of updating Misc/NEWS.  Day-to-day developers may have a conflict if 
they lose a push race, which means a little editing.  You'll have a similar, if 
slightly worse, problem when cherry-picking a fix between versions.  Worst of 
all used to be the manual merges necessary after cutting a release--this was 
the bane of a CPython release manager's existence.  (Though the new git-based 
workflow may have obviated the worst of this.)

The real problem is that we have one central file that everybody continually 
edits in a haphazard way.  We aren't actually editing the same information, we 
aren't actually changing the same lines.  But our revision control systems and 
diff algorithms don't understand the structure of Misc/NEWS and so they get 
confused.  And for what? It's not like there's a tremendous benefit to having 
this central file everyone's fighting over.

We've been talking about addressing this for years.  Fixing this was one of the 
goals of the new workflow.  And finally, as of right now, the future is here.  
Ladies and gentlemen, I present: blurb.
https://github.com/python/core-workflow/tree/master/blurb

blurb is an interactive command-line tool that helps you write Misc/NEWS 
entries.  You simply run blurb from anywhere inside a CPython repo.  blurb runs 
an editor for you with a template open.  You fill in these three pieces of 
information:
• the bugs.python.org or "bpo" issue number,
• what "section" of Misc/NEWS this entry should go in (by uncommenting the 
correct line), and
• the text of the Misc/NEWS entry, in ReST format.
You save and exit and you're done.  blurb even stages the Misc/NEWS entry in 
git for you!


Behind the scenes, blurb writes your information here:
Misc/NEWS.d/next//
The "" is the name of the section in Misc/NEWS where your entry 
should go.   contains the current date and time, the bpo number, and 
a nonce to prevent collisions.

These "next" files get merged together into a single aggregate .rst file by the 
release manager when cutting a release (using "blurb release").  One nice 
feature of this approach: when you cherry-pick a change, its Misc/NEWS entry in 
"next" gets cherry-picked along with it.


One important change: Misc/NEWS will no longer be checked in.  It'll still be 
present in CPython tarballs; it will be generated by the release manager as 
part of cutting a release.  But as a repository of information, it's been 
superseded by the various blurb data files.  And by regenerating it from data 
files, we ensure that we'll never ever have a Misc/NEWS conflict ever again!

The plan is to leave Misc/NEWS in the CPython repo for maybe another week, to 
let the current crop of PRs get merged.  But new work should switch to using 
blurb immediately.


You can install blurb from pip:
% pip3.6 install blurb
In fact--please do!


/arry

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

Re: [python-committers] New workflow change: Welcome to blurb

2017-06-23 Thread Nick Coghlan 
On 24 June 2017 at 13:24, Larry Hastings  wrote:
>
>
> One minor but ongoing problem we've had in CPython core development has been
> the mess of updating Misc/NEWS.  Day-to-day developers may have a conflict
> if they lose a push race, which means a little editing.  You'll have a
> similar, if slightly worse, problem when cherry-picking a fix between
> versions.  Worst of all used to be the manual merges necessary after cutting
> a release--this was the bane of a CPython release manager's existence.
> (Though the new git-based workflow may have obviated the worst of this.)
>
> The real problem is that we have one central file that everybody continually
> edits in a haphazard way.  We aren't actually editing the same information,
> we aren't actually changing the same lines.  But our revision control
> systems and diff algorithms don't understand the structure of Misc/NEWS and
> so they get confused.  And for what? It's not like there's a tremendous
> benefit to having this central file everyone's fighting over.
>
> We've been talking about addressing this for years.  Fixing this was one of
> the goals of the new workflow.  And finally, as of right now, the future is
> here.  Ladies and gentlemen, I present: blurb.
>
> https://github.com/python/core-workflow/tree/master/blurb

Thanks Larry, great to see this go live!

> Behind the scenes, blurb writes your information here:
>
> Misc/NEWS.d/next//
>
> The "" is the name of the section in Misc/NEWS where your
> entry should go.   contains the current date and time, the bpo
> number, and a nonce to prevent collisions.

Folks are also free to handcraft these files if they really want to do
so. The Developer Guide has the necessary details:
https://docs.python.org/devguide/committing.html#what-s-new-and-news-entries

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] [Python-Dev] New workflow change: Welcome to blurb

2017-06-23 Thread Nick Coghlan 
On 24 June 2017 at 14:01, Craig Rodrigues  wrote:
> On Fri, Jun 23, 2017 at 8:24 PM, Larry Hastings  wrote:
>>
>>
>>
>> We've been talking about addressing this for years.  Fixing this was one
>> of the goals of the new workflow.  And finally, as of right now, the future
>> is here.  Ladies and gentlemen, I present: blurb.
>>
>> https://github.com/python/core-workflow/tree/master/blurb
>
>
> Yes, when you have a single NEWS file that needs to get updated,
> the process begins  to fall apart when you have a pull request type of
> workflow
> which results in many merge conflicts to the single NEWS file.
>
> Twisted and Buildbot use towncrier ( https://github.com/hawkowl/towncrier )
> which tries
> to solve the same problem as blurb.

Aye, towncrier and OpenStack's reno were the two main alternatives we
looked at in addition to Larry's offer of creating a tool specifically
for CPython: https://github.com/python/core-workflow/issues/6

We ultimately settled on blurb mainly because we wanted to be able to
customise various details differently from the way towncrier works,
and we figure they're close enough in spirit that folks familiar with
one won't have any problems adapting to the other.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] New workflow change: Welcome to blurb

2017-06-23 Thread Serhiy Storchaka 
2017-06-24 6:24 GMT+03:00 Larry Hastings :
> One minor but ongoing problem we've had in CPython core development has been
> the mess of updating Misc/NEWS.  Day-to-day developers may have a conflict
> if they lose a push race, which means a little editing.  You'll have a
> similar, if slightly worse, problem when cherry-picking a fix between
> versions.  Worst of all used to be the manual merges necessary after cutting
> a release--this was the bane of a CPython release manager's existence.
> (Though the new git-based workflow may have obviated the worst of this.)

Thanks Larry! With the old hg-based workflow this was only slightly
annoying, but the new git-based workflow turned this into a hell. If
you have several PRs that updates the same Misc/NEWS section you
needed to spent many time for just resolving conflicts one by one and
waiting CI tests. And be lucky if other core developer trying to do
the same withis PRs at the same time.

> You can install blurb from pip:
>
> % pip3.6 install blurb
>
> In fact--please do!

I have installed it, but how to use it?

$ python3 -m pip install --user blurb
Collecting blurb
  Using cached blurb-1.0-py3-none-any.whl
Installing collected packages: blurb
Successfully installed blurb-1.0
$ python3 -m blurb
/usr/bin/python3: No module named blurb
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/