A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2017-June/148404.html below:

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

[Python-Dev] [python-committers] Proposed release schedule for Python 3.5.4Victor Stinner victor.stinner at gmail.com
Fri Jun 23 04:55:57 EDT 2017
2017-06-22 17:56 GMT+02:00 Brett Cannon <brett at python.org>:
> On Thu, 22 Jun 2017 at 02:32 Larry Hastings <larry at hastings.org> 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
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4