Le 9 mars 2017 7:32 PM, "Brett Cannon" <brett(a)python.org> a écrit :
In general I expect none of those branches to live longer than 24 hours as
the PRs they were created for should be merged in less than an hour. If a
branch is older than a day then it means someone probably forgot to delete
the branch after merging a PR.
My main experience with Git is the OpenStack project and in this project
there is no such "temporary" branches.
I didn't know that it was possible to remove an "upstream" branch in Git.
I will see in a few weeks if these branches are an issu in practice or not
;-)
Right now, I'm still a little bit lost in the long list of branches. I have
many local branches too.
Victor
Hi,
Updating my local copy of CPython Git repository created a new
ncoghlan-bpo-29537-NEWS branch. Was it deliberate? If not, should we
prevent the creation of new Git branches? Maybe restrict this feature
outside releases? Or restrict the feature to release managers? Just to
prevent mistakes.
Victor
Is there a reason for this ?
Example:
https://github.com/python/cpython/pull/422
and
http://bugs.python.org/issue20087
Also: I'd like to remind other committers that discussions of PRs
should happen on the ticket, not the PR. In the above case, the PR
was merged while we were still discussing the patch on the ticket.
Thanks,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Experts (#1, Mar 08 2017)
>>> Python Projects, Coaching and Consulting ... http://www.egenix.com/
>>> Python Database Interfaces ... http://products.egenix.com/
>>> Plone/Zope Database Interfaces ... http://zope.egenix.com/
________________________________________________________________________
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/http://www.malemburg.com/
It’s that time again: time to start thinking about the Python Language Summit!
The 2017 summit will be held on Wednesday, May 17, from 10am to 4pm, at the
Oregon Convention Center in Portland, Oregon, USA. Your befezzled hosts Larry
and Barry will once again be at the helm.
The summit’s purpose is to disseminate information and spark conversation
among core Python developers. It’s our yearly opportunity to get together for
an in-person discussion, to review interesting developments of the previous
year and hash out where we’re going next. And we have lots to talk about!
Since our last summit, Python 3.6 was released, and the main CPython
development process has been moved to GitHub. Naturally Python 3.7
development continues apace.
Speaking of changes, we’re continuing to evolve the summit. Everyone seemed
to like the lightning talks, so we’ll keep those. Everyone seemed to hate us
keeping the schedule secret -sorry!- so we’ll make that available beforehand,
with the understanding that it’ll be fluid as the day progresses. Due to room
size limitations and the yearly increase in participation, we’re limiting
summit invitations to just core developers and invited speakers. As usual,
we’ll have whiteboards and a projector. But this year we’re adding roaming
microphones, so everybody in the room will be able to hear your question!
With the help of the ever awesome Ewa, this year we’ll have badge ribbons for
Language Summit participants, which we’ll hand out at the summit room in the
morning.
As with last year, we’re using Google Forms to collect signups. The form will
let you request an invitation to the summit and optionally propose a talk.
Signups are open now, and will remain open until Wednesday April 12th, 2017.
You can find the link to the signup form from the summit’s official web page,
here:
https://us.pycon.org/2017/events/language-summit/
But never forget: you don’t need to be registered for PyCon in order to attend
the summit!
One final note. We’re re-inviting Jake Edge from Linux Weekly News to attend
the summit and provide press coverage. Jake’s done a phenomenal job of
covering the previous two years’ summits, providing valuable information not
just for summit attendees, but also for the Python community at large. Jake’s
coverage goes a long way toward demystifying the summit, while remaining
respectful of confidential information that’s deemed “off the record” ahead of
time by participants.
We hope to see you at the summit!
[BL]arry
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
nad(a)python.org -- []
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
Travis is severely backed up at the moment. Knowing that 3.6.1rc1 is due
this weekend I have temporarily turned off Travis requiring to be passing
so that those who test locally can skip being blocked by hour-long (or
more) wait times for Travis. If you don't want to test I would then still
strongly recommend on waiting for Travis if you don't feel like your PR is
critical to 3.6.
On behalf of the Python development community and the Python 3.6 release
team, I would like to announce the availability of Python 3.6.1rc1.
3.6.1rc1 is the first release candidate for Python 3.6.1, the first
maintenance release of Python 3.6. 3.6.0 was released on 2017-12-22
to great interest and now, three months later, we are providing the
first set of bugfixes and documentation updates for it. While
3.6.1rc1 is a preview release and, thus, not intended for production
environments, we encourage you to explore it and provide feedback
via the Python bug tracker (https://bugs.python.org). Although it
should be transparent to users of Python, 3.6.1 is the first release
after some major changes to our development process so we ask users
who build Python from source to be on the lookout for any unexpected
differences.
3.6.1 is planned for final release on 2017-03-20 with the next
maintenance release expected to follow in about 3 months.
Please see "What’s New In Python 3.6" for more information:
https://docs.python.org/3.6/whatsnew/3.6.html
You can find Python 3.6.1rc1 here:
https://www.python.org/downloads/release/python-361rc1/
More information about the 3.6 release schedule can be found here:
https://www.python.org/dev/peps/pep-0494/
--
Ned Deily
nad(a)python.org -- []
Hello!
Some of our automation needs to be able to determine who is a member of the Python organization on Github to effectively work. Unfortunately it currently can only see users who have publicized their membership in the Org, but so far only 50 out of 138 current members have done so.
If you have a minute and are able to do that, it would be great.
It’s pretty easy to do, just go to https://github.com/orgs/python/people <https://github.com/orgs/python/people> and locate yourself on the list. Once you found yourself, if you look to the right hand side of your entry, you’ll see either the word “Private” or “Public”, if it says “Private”, click on it and select “Public” (https://s.caremad.io/MLlxY1W5r0/ <https://s.caremad.io/MLlxY1W5r0/>). That’s all you need to do.
Thanks a lot!
—
Donald Stufft
