[python-committers] UPDATE: Python 3.6.2rc1 cutoff now scheduled for 2017-06-16 12:00 UTC

[Ned Deily]

The security-related release blocker (bpo-29591) has been resolved; my thanks 
to Victor for leading the effort.

As of now, I'm not aware of any other release blocker issues for the 3.6.2 
release candidate so I'm rescheduling the code cutoff for 2017-06-16 12:00 UTC, 
approximately 30 hours from now.  That gives you one last opportunity to get 
important fixes in for 3.6.2.  As always, if you know of issues that you think 
need to be resolved before the 3.6.2 release, please ensure there is an open 
tracker issue for it on bugs.python.org and mark the issue as "release 
blocker".  To still give 2 weeks of exposure for the rc, the new target release 
date for 3.6.2 final will be 2017-06-30.

--Ned

On Jun 13, 2017, at 00:09, Ned Deily  wrote:
> An update on 3.6.2rc1: we have been working through a few critical and 
> release blocker issues that needed to be fixed for 3.6.2.  Thanks to everyone 
> who has helped with them!  At the moment, we have one security-related 
> release blocker (http://bugs.python.org/issue29591) which I think we need to 
> get addressed in 3.6.2.  So, I'm delaying 3.6.2rc1 until we can get that 
> resolved.  That means that, for the moment, changes going into the 3.6 branch 
> will likely make in into 3.6.2.  I'll let you know when we are ready to tag.
> 
> On Jun 8, 2017, at 23:34, Ned Deily  wrote:
>> We are approaching the end of the second calendar quarter of 2017 and, 
>> according to PEP 494, it's time to start producing the second maintenance 
>> release for the 3.6 series.  The schedule calls for the release candidate to 
>> be produced on Monday 2017-06-12 UTC.  As was the case with previous 3.6.x 
>> releases, the plan is for the release candidate to be the same as the final 
>> release, that is, no additional changes go in after the release candidate 
>> except for any showstopper critical problems that might be discovered with 
>> rc1.  So please plan to get any security fixes, bug fixes, and documentation 
>> changes you think should be in 3.6.2 merged in ASAP.  The 3.6.2 final is 
>> planned for two weeks following rc1, that is, on 2017-06-26.  The next 3.6 
>> maintenance release (3.6.3) is planned to follow about 3 months later, so 
>> most likely in 2017-09.
>> 
>> A reminder that the 3.6 branch will remain open for checkins throughout the 
>> 3.6.2rc and final cycle.  Once 3.6.2rc1 is tagged, new commits to the 3.6 
>> branch will release with 3.6.3.  As always, if you find any problem in 
>> 3.6.2rc1 that you may believe should be corrected in 3.6.2, please ensure 
>> the problem is documented in a new or existing open issue on 
>> bugs.python.org, ensure that the Priority field of the issue is set to 
>> "release blocker", and that "Python 3.6" is included in the selected 
>> Versions.  Comments or tags on github Pull Requests are NOT sufficient!
>> 
>> Thanks again for all of your efforts in bringing 3.6 into the world and for 
>> helping now to make it even better!
>> 
>> https://www.python.org/dev/peps/pep-0494/
>> http://cpython-devguide.readthedocs.io

--
  Ned Deily
  n...@python.org -- []

___
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

[Nick Coghlan]

On 15 June 2017 at 00:40, Victor Stinner  wrote:
> Hi,
>
> The CPython workflow was enhanced to get pre-commit CI checks. That's
> a huge win, thank you for that... But, sometimes, a change can still
> break many buildbots, bugs which weren't catched by pre-commit checks
> (Travis CI/Linux and AppVeyor/Windows). Buildbots cover much more
> different architectures and platforms.
>
> I spend a significant amount of time to maintain the sanity of our
> buildbots. Sometimes, it can take me up to 3 days on a week (of 5
> working days). It's annoying to see new regressions while I'm trying
> hard to fix old ones :-(
>
> 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.

For example, something that would be genuinely helpful would be a bot
monitoring PR comments that could automate the "custom-build" dance
for core developers (i.e. we'd be able to write something like
"BuildBot: test custom build", and it would go away, kick off a custom
BuildBot run by pushing the PR to the "custom-build" branch, and then
report back the links for failed builds like
http://buildbot.python.org/all/builders/x86%20Tiger%20custom/builds/5
)

That way, the reversion process would be:

1. Revert the change
2. Post a "BuildBot: test custom build" comment on the offending PR
3. Original PR author, committer, and anyone else interested continues
the issue resolution process based on the specific links posted back
by the helper bot

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

[Barry Warsaw]

On Jun 14, 2017, at 11:00 PM, Victor Stinner wrote:

>Since I'm trying to always keep the highest number of green buildbots,
>I prefer to try to fix the bug myself.
>
>My question is what to do if I'm unable to fix the issue and the
>author is not available. Keep a broken CI for hours, sometimes for
>days. Or revert the change to reduce the pressure and get more time to
>write a *proper* fix?
>
>I propose to revert to get more people at the issue to find the best
>option, rather than urging to push a quick & dirty fix.
>
>Hopefully, in most cases, the bug is trivial and I consider that the
>fix doesn't require a review, so I push it directly.

I agree with you that if it's easy to fix, JFDI.  If not, revert it to keep
the buildbots green and inform the author about the problem.  For now that can
be to update the issue or PR so the author gets a mention, but later it can be
an autonag email.

-Barry
___
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

[Ethan Furman]

On 06/14/2017 02:07 PM, Donald Stufft wrote:


I’m +1 on reverting the change, I’d even go so far to say I’d be +1 on doing it 
as a first response. It’s always
possible to revert the revert once the person who committed the patch has time 
to investigate the failure and recommit
the patch with a fix.


I would rather have the revert be the first response.  Without a thorough understanding of the bug/feature being 
addressed it is entirely possible to introduce a new bug or change the semantics of the original patch.


--
~Ethan~

___
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

[Donald Stufft]

I’m +1 on reverting the change, I’d even go so far to say I’d be +1 on doing it 
as a first response. It’s always possible to revert the revert once the person 
who committed the patch has time to investigate the failure and recommit the 
patch with a fix.

> On Jun 14, 2017, at 5:00 PM, Victor Stinner  wrote:
> 
> 2017-06-14 18:38 GMT+02:00 Serhiy Storchaka :
>> I think we first should make buildbots notifying the author of a
>> commit that broke tests or building, so his can either quickly fix the
>> failure or revert his commit.
> 
> Hum, I think that I should elaborate my previous email.
> 
> It's usually easy to identify a commit which introduced regressions if
> you compare 2 or 3 failing buildbots and their list of changes. So
> when I identify the commit, if I cannot fix the issue immediately,
> usually I leave a message on the issue (bugs.python.org). So the
> author but also other people who worked on the issue are well aware of
> the regression.
> 
> In my experiemnce, it's rare that I get any feedback in less than 24h,
> while slowly more and more buildbots become red. It depends on the
> availability of the commiter.
> 
> Since I'm trying to always keep the highest number of green buildbots,
> I prefer to try to fix the bug myself.
> 
> My question is what to do if I'm unable to fix the issue and the
> author is not available. Keep a broken CI for hours, sometimes for
> days. Or revert the change to reduce the pressure and get more time to
> write a *proper* fix?
> 
> I propose to revert to get more people at the issue to find the best
> option, rather than urging to push a quick & dirty fix.
> 
> Hopefully, in most cases, the bug is trivial and I consider that the
> fix doesn't require a review, so I push it directly.
> 
> Victor
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/


—
Donald Stufft



___
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

[Victor Stinner]

2017-06-14 18:38 GMT+02:00 Serhiy Storchaka :
> I think we first should make buildbots notifying the author of a
> commit that broke tests or building, so his can either quickly fix the
> failure or revert his commit.

Hum, I think that I should elaborate my previous email.

It's usually easy to identify a commit which introduced regressions if
you compare 2 or 3 failing buildbots and their list of changes. So
when I identify the commit, if I cannot fix the issue immediately,
usually I leave a message on the issue (bugs.python.org). So the
author but also other people who worked on the issue are well aware of
the regression.

In my experiemnce, it's rare that I get any feedback in less than 24h,
while slowly more and more buildbots become red. It depends on the
availability of the commiter.

Since I'm trying to always keep the highest number of green buildbots,
I prefer to try to fix the bug myself.

My question is what to do if I'm unable to fix the issue and the
author is not available. Keep a broken CI for hours, sometimes for
days. Or revert the change to reduce the pressure and get more time to
write a *proper* fix?

I propose to revert to get more people at the issue to find the best
option, rather than urging to push a quick & dirty fix.

Hopefully, in most cases, the bug is trivial and I consider that the
fix doesn't require a review, so I push it directly.

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

Re: [python-committers] Promote Julien Palards as Committers on docsbuild-scripts

[Victor Stinner]

2017-06-14 22:40 GMT+02:00 Brett Cannon :
>> Oh, I didn't know. Is it possible to see who owns a GitHub Python project
>> at https://github.com/python/?
>
> If you can see https://github.com/orgs/python/teams/python-core/repositories
> then yes. :)

About this list, there was a question on the buildmaster-config
repository. Mariatta Wijaya's message:
"""
I didn't know about buildmaster-config repo.

It's not listed as one of the projects for the Python Core team :)

https://github.com/orgs/python/teams/python-core/repositories

Should it be?
"""

http://bugs.python.org/issue30658#msg296018

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

Re: [python-committers] Revert changes which break too many buildbots

[Brett Cannon]

On Wed, 14 Jun 2017 at 07:46 Victor Stinner 
wrote:

> Hi,
>
> The CPython workflow was enhanced to get pre-commit CI checks. That's
> a huge win, thank you for that... But, sometimes, a change can still
> break many buildbots, bugs which weren't catched by pre-commit checks
> (Travis CI/Linux and AppVeyor/Windows). Buildbots cover much more
> different architectures and platforms.
>

There's also macOS if you look at the Travis results manually.


>
> I spend a significant amount of time to maintain the sanity of our
> buildbots. Sometimes, it can take me up to 3 days on a week (of 5
> working days). It's annoying to see new regressions while I'm trying
> hard to fix old ones :-(
>
> 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.
>
> It doesn't mean that the commit is bad and must not be merged ever.
> No. It would just mean that we need time to work on fixing the issue,
> and it shouldn't impact other pending changes, to keep a sane master
> branch.
>
> What do you think? Would you be ok with such rule?
>

I'm +1 on it. We have always expected people to watch the buildbots after a
commit to make sure nothing horrible happened. And leaving a branch broken
just makes fixing it harder due to code change and it masks potential
failures from subsequent commits that happen to manifest themselves as a
similar failure.

-Brett


>
> A recent example is Nick Coghlan's implementation of the PEP 538:
> basically, it broke all buildbots... except of Linux and Windows :-)
> And it will take a few more days to fix all failures. Well, we are
> working on fixing these issues, so I don't want to revert this change.
> It's just an example of a single change which broke many buildbots.
> The PEP 538 depends a lot on the platform, so I'm not surprised to see
> different failures per platforms ;-)
>
> By "buildbot failure", I mean a red buildbot failing because of
> compilation error or failed test suite. But I would prefer to ignore
> failures of the Refleak buildbots since these ones are not stable
> (even if there are less and less ref leaks in master, and these
> buildbots already catched recent regressions!).
>
> If the rule is approved, I plan to announce it on python-dev to be
> transparent.
>
> Victor
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers 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 Julien Palards as Committers on docsbuild-scripts

[Brett Cannon]

On Tue, 13 Jun 2017 at 15:37 Victor Stinner 
wrote:

> Le 14 juin 2017 00:29, "Brett Cannon"  a écrit :
>
> It is, but the infrastructure team owns that repo, not Python core.
>
> -Brett
>
>
> Oh, I didn't know. Is it possible to see who owns a GitHub Python project
> at https://github.com/python/?
>

If you can see https://github.com/orgs/python/teams/python-core/repositories
then
yes. :)


>
> If not, do you think that it would be worth it to document it somewhere?
> Like in the devguide?
>

I don't think it's worth it as it doesn't come up often enough and it would
just end up out-of-date.
___
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

[Victor Stinner]

2017-06-14 18:38 GMT+02:00 Serhiy Storchaka :
>> What do you think? Would you be ok with such rule?
>
> I think we first should make buildbots notifying the author of a
> commit that broke tests or building, so his can either quickly fix the
> failure or revert his commit.

One or two months ago, I created a new buildbot-status mailing list
which gets notifications of buildbot failures:
https://mail.python.org/mm3/mailman3/lists/buildbot-status.python.org/

I'm happy because we get less and less random failures, but I don't
feel confortable yet to spam the author of changes when a buildbot
fails for an unrelated reason like a network issue.

Analyzing buildbot failures is still a manual step, so I propose to
make a compromise here ;-)

Reading buildbot logs is a boring task, I don't expect that everyone
do it. I cannot require that all contributors take care of the CI. But
I consider that it's part of my job, I'm fine with that ;-)

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

[python-committers] Revert changes which break too many buildbots

[Victor Stinner]

Hi,

The CPython workflow was enhanced to get pre-commit CI checks. That's
a huge win, thank you for that... But, sometimes, a change can still
break many buildbots, bugs which weren't catched by pre-commit checks
(Travis CI/Linux and AppVeyor/Windows). Buildbots cover much more
different architectures and platforms.

I spend a significant amount of time to maintain the sanity of our
buildbots. Sometimes, it can take me up to 3 days on a week (of 5
working days). It's annoying to see new regressions while I'm trying
hard to fix old ones :-(

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.

It doesn't mean that the commit is bad and must not be merged ever.
No. It would just mean that we need time to work on fixing the issue,
and it shouldn't impact other pending changes, to keep a sane master
branch.

What do you think? Would you be ok with such rule?

A recent example is Nick Coghlan's implementation of the PEP 538:
basically, it broke all buildbots... except of Linux and Windows :-)
And it will take a few more days to fix all failures. Well, we are
working on fixing these issues, so I don't want to revert this change.
It's just an example of a single change which broke many buildbots.
The PEP 538 depends a lot on the platform, so I'm not surprised to see
different failures per platforms ;-)

By "buildbot failure", I mean a red buildbot failing because of
compilation error or failed test suite. But I would prefer to ignore
failures of the Refleak buildbots since these ones are not stable
(even if there are less and less ref leaks in master, and these
buildbots already catched recent regressions!).

If the rule is approved, I plan to announce it on python-dev to be transparent.

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