Re: [python-committers] GitHub: allow Rebase and merge
It's possible, but we don't control what the default option is. On Mon, 6 Mar 2017 at 16:32 Victor Stinner wrote: > Hi, > > Would it be possible to keep "Squash and merge" button by default on > GitHub pull requests, but allow "Rebase and merge" to keep multiple > commits when they are well written. Example of such PR: > https://github.com/python/cpython/pull/489/commits > > Maybe the second commit lacks bpo-xxx, but it's not a big deal. I > prefer smaller atomic commits when possible. > > Victor > ___ > 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 mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] 3.6.1 release status and plans
An update on the 3.6.1 release: As you probably noticed, 3.6.1 release candidate 1 was made available (finally!) two days ago. Thank you for your patience as we worked though the details of producing a release using our new GitHub-based development workflow. As we've noted, it's really important for all segments of the community to try using 3.6.1rc1 to help make sure something didn't break along the way. Please report any potential problems via the bugs.python.org tracker and mark them as "release blocker". Because rc1 was delayed a week, I've moved the planned release date for 3.6.1 final back a week as well, now 2017-03-20. That gives two weeks of exposure for rc1. The plan is to, if at all possible, not ship any additional changes in the final beyond what is already in rc1 unless we discover any release-blocking critical problems in rc1. The 3.6 branch remains open for new cherry-pick PRs etc but you should expect that any PRs that are merged into the 3.6 branch since the v3.6.1rc1 tag will first be released in 3.6.2, expected before the end of June (about 3 months). Again, if something critical comes up that you feel needs to be in 3.6.1, you need to make sure the issue is marked as a "release blocker" and you should make sure I am aware of it. If any such release blockers do arise, we will discuss them and decide whether they should go into 3.6.1 and whether a second release candidate is needed. Thanks for your support! --Ned -- Ned Deily [email protected] -- [] ___ 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] 3.6.1 release status and plans
On 8 March 2017 at 11:59, Ned Deily wrote: > An update on the 3.6.1 release: As you probably noticed, 3.6.1 release > candidate 1 was made available (finally!) two days ago. Thank you for your > patience as we worked though the details of producing a release using our > new GitHub-based development workflow. As we've noted, it's really > important for all segments of the community to try using 3.6.1rc1 to help > make sure something didn't break along the way. Please report any > potential problems via the bugs.python.org tracker and mark them as > "release blocker". > > Because rc1 was delayed a week, I've moved the planned release date for > 3.6.1 final back a week as well, now 2017-03-20. That gives two weeks of > exposure for rc1. The plan is to, if at all possible, not ship any > additional changes in the final beyond what is already in rc1 unless we > discover any release-blocking critical problems in rc1. The 3.6 branch > remains open for new cherry-pick PRs etc but you should expect that any PRs > that are merged into the 3.6 branch since the v3.6.1rc1 tag will first be > released in 3.6.2, expected before the end of June (about 3 months). > And if anyone notices some oddities with sys.path initialisation, we're aware of them and are looking into it: http://bugs.python.org/issue29723 (it currently appears to be a case where a fix that worked as intended in Windows is unexpectedly leaving the parent directory of the given directory or archive on sys.path when running directories and zip archives on other platforms). 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/
