Re: [Python-Dev] Troubles to merge changes in the 2.7 branch: PR "out-of-date" branch
On 29 May 2018 at 08:52, Ned Deily wrote: > On May 28, 2018, at 17:42, Victor Stinner wrote: > > Please use the same configuration for 2.7, 3.6, 3.7 and master branches! > > Sounds reasonable. I've updated the 2.7 configuration to match the others > and not require the PR branch be up to date before merging, meaning the CI > test might be against an older view of the branch. If it proves to be a > problem, we can revisit it for all of the branches. I am not going to > change the settings for 3.5 and 3.4 as they are in security-fix mode and > only their release manager can merge changes for those. > Turning the setting on for security-fix branches sounds like a good idea to me, since it's basically a "stability-of-target-branch vs ease-of-merging" trade-off: by setting it, you ensure that your pre-merge CI checks reflect the state of the post-merge branch, whereas the default setting means your post-merge branch state represents a never-before-tested combination of software. The default state works pretty well for us since we don't kick off test runs on the BuildBot fleet for every PR, so there's always some additional testing that only happens post-merge anyway. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Compact GC Header
Hi, all. I hacked GC module and managed to slim PyGC_Head down from 3 words to 2 words. It passes test suite, while some comments and code cleanup is needed before merge. * https://bugs.python.org/issue33597 * https://github.com/python/cpython/pull/7043 I want to merge it after 3.7.0rc1 and buildbots are stable, if Antoine or other GC expert accept it. I estimate it reduces 5% memory usage (RSS) and negligible performance difference. If someone interested in it, please test and benchmark it on GC heavy application. Regards, -- INADA Naoki ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compact GC Header
> I hacked GC module and managed to slim PyGC_Head down from 3 words to 2 > words. > It passes test suite, while some comments and code cleanup is needed before > merge. Does this change break the stable ABI? Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compact GC Header
Looks like it breaks the 3.7 ABI, which is certainly not allowed at this time. But it’s not a limited API structure, so no problem for 3.8. Top-posted from my Windows 10 phone From: Victor Stinner Sent: Tuesday, May 29, 2018 6:44 To: INADA Naoki Cc: Python-Dev Subject: Re: [Python-Dev] Compact GC Header > I hacked GC module and managed to slim PyGC_Head down from 3 words to 2 > words. > It passes test suite, while some comments and code cleanup is needed before > merge. Does this change break the stable ABI? Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40python.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Troubles to merge changes in the 2.7 branch: PR "out-of-date" branch
> As I wrote, it became very difficult to merge any PR on 2.7 because of > that. We all run a race to be the first one to merge a change into > 2.7. The next one will get a "conflict" even if the merged commit is > unrelated (as I described: two different unrelated directories). Couldn't miss-islington be configured to automatically rebase those (when there is no actual conflict). The "Allow edit from maintainer" would most likely permit to push on the PRs branch. -- M On Tue, 29 May 2018 at 05:26, Nick Coghlan wrote: > On 29 May 2018 at 08:52, Ned Deily wrote: > >> On May 28, 2018, at 17:42, Victor Stinner wrote: >> > Please use the same configuration for 2.7, 3.6, 3.7 and master branches! >> >> Sounds reasonable. I've updated the 2.7 configuration to match the others >> and not require the PR branch be up to date before merging, meaning the CI >> test might be against an older view of the branch. If it proves to be a >> problem, we can revisit it for all of the branches. I am not going to >> change the settings for 3.5 and 3.4 as they are in security-fix mode and >> only their release manager can merge changes for those. >> > > Turning the setting on for security-fix branches sounds like a good idea > to me, since it's basically a "stability-of-target-branch vs > ease-of-merging" trade-off: by setting it, you ensure that your pre-merge > CI checks reflect the state of the post-merge branch, whereas the default > setting means your post-merge branch state represents a never-before-tested > combination of software. > > The default state works pretty well for us since we don't kick off test > runs on the BuildBot fleet for every PR, so there's always some additional > testing that only happens post-merge anyway. > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/bussonniermatthias%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Troubles to merge changes in the 2.7 branch: PR "out-of-date" branch
This doesn't seem like the best idea, since it would kick off dozens or hundreds of builds for every commit to the master branch. On 05/29/2018 11:25 AM, Matthias Bussonnier wrote: >> As I wrote, it became very difficult to merge any PR on 2.7 because of >> that. We all run a race to be the first one to merge a change into >> 2.7. The next one will get a "conflict" even if the merged commit is >> unrelated (as I described: two different unrelated directories). > > Couldn't miss-islington be configured to automatically rebase those (when > there is no actual conflict). The "Allow edit from maintainer" would most > likely permit to push on the PRs branch. > > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/paul%40ganssle.io > signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python 3.7.0 updated schedule: beta 5 cutoff in 24 hours
Here's an update on the 3.7.0 endgame. As announced several days ago, we made the difficult decision to hold back on 3.7.0rc1 due primarily to some unexpected difficulties being seen downstream due to changes in how docstrings were handled in 3.7.0 (details below). After some discussions about various approaches, we agreed on a solution that should minimize downstream impact without losing all the benefits of the existing 3.7 changes. Thanks to a lot of work over the long weekend by a number of people that solution is now merged in the 3.7 branch. In parallel with that, a number of people spent a lot of time looking at CI and buildbot test failures, mostly intermittent ones. As a result, a number of actual bugs were fixed and also problems with a number of tests were fixed which should make the test suite more robust. All this is good news. Primarily because of the important user-facing changes made with the AST docstring API, I feel we need to do one more beta release before we are ready for the release candidate. About 24 hours from now, approximately 2018-05-30 18:00UTC, I plan to tag and start manufacturing 3.7.0b5. This will be a short beta cycle, aimed mainly at users of the AST API so they can recheck that their packages with 3.7.0. Assuming all goes well, we will then plan to tag 3.7.0rc1 on 2018-06-11 and 3.7.0 final on 2017-06-27. I am also rescheduling 3.6.6rc1 and 3.6.6 final to match the new 3.7.0 dates. All fixes that have been merged into the 3.7 branch as of cutoff tomorrow will be in 3.7.0b5 and fixes merged afterwards will be in 3.7.0rc1 up to its cutoff point. After 3.7.0rc1 cutoff, 3.7 merges will appear in 3.7.1. Please continue to exercise diligence when deciding whether a change is appropriate for 3.7; as a rule of thumb, treat the 3.7 branch as if it were already released and in maintenance mode. Please also pay attention to CI test failures and buildbot test failures and see if you can help resolve them. I want to thank everyone who has been involved so far in helping us through this endgame and who have given up their personal time to work on making Python better. I, for one, am deeply grateful. 2018-05-30 3.7.0b5 2018-06-11 3.7.0rc1 & 3.6.6rc1 2018-06-27 3.7.0final & 3.6.6final --Ned On May 25, 2018, at 01:33, Ned Deily wrote: > On May 24, 2018, at 03:23, Ned Deily wrote: >> On May 23, 2018, at 09:13, Ned Deily wrote: >>> On May 23, 2018, at 07:45, Serhiy Storchaka wrote: Is it possible to add yet one beta instead? CI was broken for few latest days, tests are not passed on my computer still (and fail on some buildbots), updating What's New exposed new features which need additional testing (and maybe fixing or reverting), and I'm not comfortable about some changes which would be harder to fix after the release. >>> it is possible but there's no point in doing either another beta or a >>> release candidate until we understand and address the current blocking >>> issues, like the major buildbot failures. We have another 24 hours until >>> rc1 was planned to be tagged. Let's keep working on the known issues and >>> we will make a decision then. >> An update: thanks to a lot of effort over the past day by a number of >> people (including Victor, Serhiy, Christian, Zach, and others I'm sure >> I'm forgetting - my apologies), we have addressed all of the "release >> blocker" issues and all but one of the persistent failures on the 3.7 >> stable buildbots. We should have the couple of remaining "deferred >> blockers" including the remaining stable buildbots in green status by >> later today. At that point, we will be ready to tag 3.7.0rc1 and begin >> producing the release candidate artifacts. > Further update: some good news and some changes. > > The good news is that we have resolutions for all of the previous release and > deferred blockers. Thanks to a number of people for continuing to help get > the remaining stable buildbot issues taken care of along with some lingering > bugs. > > The not-quite-as-good news is that we have had more discussions about some > unexpected incompatibilities that have shown up with downstream user testing > with the AST docstrings changes in place (see bpo-32911). We have had some > previous discussions about the expected user impact and, earlier in the beta > phase, I encouraged us to stay the course with the feature as implemented. > But I am now persuaded that we owe it to our users to take one more look at > this to make sure we do not force them to make changes for 3.7 and then once > again for 3.8. More details are in the bug tracker issue; I strongly > encourage those of us who have been involved with this to "vote" there on the > proposal to either (A) proceed with the release of the current implementation > in 3.7.0 or (B) revert the feature in 3.7.0 and retarget for 3.8. Should the > consensus be to revert (B), we will plan to have one more fast-track beta > release (b5)
Re: [Python-Dev] Troubles to merge changes in the 2.7 branch: PR "out-of-date" branch
On Tue, 29 May 2018 at 08:43, Paul G wrote: > This doesn't seem like the best idea, since it would kick off dozens or > hundreds of builds for every commit to the master branch. > Sorry if I was unclear, I was not suggesting to do that for PRs against master, but do that only for 2.7, 3.4 and 3.5 only. (or Branch having "Require branches to be up to date before merging ") For these there is likely only a couple of open PRs, and it won't kick more jobs than if the author had to rebase and push by themselves. If you still think it's too much or triggered too often, you can also just have a tag "Miss-islington please rebase", which is often easier to apply manually, than having to do that by yourself on the Command line. -- M ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Troubles to merge changes in the 2.7 branch: PR "out-of-date" branch
GitHub provides a [Update branch] button. It seems like the button does a rebase, no? Victor 2018-05-29 18:24 GMT+02:00 Matthias Bussonnier : > On Tue, 29 May 2018 at 08:43, Paul G wrote: >> >> This doesn't seem like the best idea, since it would kick off dozens or >> hundreds of builds for every commit to the master branch. > > > Sorry if I was unclear, I was not suggesting to do that for PRs against > master, but do that only for 2.7, 3.4 and 3.5 only. (or Branch having > "Require branches to be up to date before merging ") > For these there is likely only a couple of open PRs, and it won't kick more > jobs than if the author had to rebase and push by themselves. > > If you still think it's too much or triggered too often, you can also just > have a tag "Miss-islington please rebase", which is often easier to apply > manually, than having to do that by yourself on the Command line. > > -- > M > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Troubles to merge changes in the 2.7 branch: PR "out-of-date" branch
On 29.5.2018 22:01, Victor Stinner wrote: GitHub provides a [Update branch] button. It seems like the button does a rebase, no? AFAIK it merges the traget branch to the PR branch. No rebase. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Troubles to merge changes in the 2.7 branch: PR "out-of-date" branch
2018-05-29 22:12 GMT+02:00 Miro Hrončok : > On 29.5.2018 22:01, Victor Stinner wrote: >> >> GitHub provides a [Update branch] button. It seems like the button >> does a rebase, no? > > > AFAIK it merges the traget branch to the PR branch. No rebase. Oh right! And it's the good option :-) Rebase cause confusions in reviews. Merge are fine for reviews. Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
