I have updated the schedules for the next maintenance releases of Python 3.7.x and 3.6.x. My original plan had been to get 3.7.1, the first 3.7 maintenance release, out by the end of July. It was solely my fault that that did not happen so I hope you'll accept my apologies; I will try to not let it happen again. I have now scheduled a 3.7.1 release candidate and rescheduled the 3.6.7 release candidate for 2018-09-18, about a week from today, and 3.7.1 final and 3.6.7 final for 2018-09-28. That allows us to take advantage of fixes generated at the Core Developers sprint taking place this week.
Please review any open issues you are working on or are interested in and try to get them merged in to the 3.7 and/or 3.6 branches soon - by the beginning of next week at the latest. As usual, if there are any issues you believe need to be addressed prior to these releases, please ensure there are open issues for them in the bug tracker (bugs.python.org) and that their priorities are set accordingly (e.g. "release blocker").
Thanks for your support!
--Ned
--
Ned Deily
nad(a)python.org -- []
Hi all,
Most of my effort this week has gone into improving the state of
buildbot.python.org, which has largely gone into improving Buildbot
itself. Here are the relevant highlights:
- Anyone can now log into buildbot.python.org via GitHub by clicking
the 'Anonymous' dropdown in the upper right corner, then 'Login with
GitHub'. The first time, GitHub will ask you for approval;
subsequently you'll just be logged right in.
- Stopping builds and triggering rebuilds is now restricted to members
of the `python-core` team and the "owner" of a build. I've not had
opportunity to test whether the author of a commit actually qualifies
as the "owner" or if only the committer does, but if anyone runs into
trouble with it please open an issue on the buildmaster-config repo.
- Disabling/enabling schedulers is now restricted to members of the
`python-release-managers` team. We had an issue some months ago where
someone had apparently disabled the scheduler for one of our branches,
resulting in no builds on that branch for several days before we
noticed. That shouldn't happen again!
- Buildbot now reports results from our stable builders on each tested
commit. For now, we're still only running tests post-merge, so you
won't see new status checks on PRs, but you can find results on
https://github.com/python/cpython/commits/
Let me know if any of these changes negatively impact you, or if you
have suggestions for further improvement.
Regards,
--
Zach
At the developer sprints this week, we collectively decided to grant core committer status to Emily and Lisa.
Please join me in welcoming them to the team.
Raymond
-------------------------------
Emily is the Director of Engineering at Cuttlesoft. She has previously attended two Language Summits and three core development sprints at PyCon. Since July, Emily has worked with Guido's guidance to implement PEP 572, Assignment Expressions. She has also worked with Eric Snow to dive into CPython's runtime as well as subinterpreters. This year at PyCon she gave a talk on Python's AST. Here is her speaker bio https://us.pycon.org/2018/speaker/profile/283/ and a link to her talk video: https://www.youtube.com/watch?v=XhWvz4dK4ng
Lisa has a background in network engineering and supported the Cisco sale engineer team to develop high quality Python product demonstrations. Later she moved to the Facebook security team. This is her third core developer sprint. She and Guido are co-authors of PEP 526, Syntax for Variable Annotations. Last year, she worked with Eric Smith on PEP 557, Data Classes. Here is her speaker bio https://us.pycon.org/2018/speaker/profile/824/ and a link to her Pycon talks: https://www.youtube.com/watch?v=hKxbO4rRlpg and https://www.youtube.com/watch?v=ww1UsGZV8fQ
Hi all
Just a heads-up that the Azure Pipelines build failures for Linux
machines are a known issue that should be fixed by the end of the week.
It seems the service has become so popular since last week's
announcements that many more builds are being run on machines that have
been freshly imaged, and so they are racing with a background 'apt
update' command. This causes an explicit 'apt update' to (correctly)
fail to acquire its lock. I believe it's also related to the move from
running builds within Docker containers to actual VMs, which happened
around the same time.
Until it's fixed, feel free to ignore the Azure Pipelines status for
Linux builds. Apologies for the inconvenience with backports not
auto-merging.
Cheers,
Steve
Hi all
At the sprints this last week, probably unsurprisingly, we had some
discussions relating to the future of Python's governance. Since not
everyone could be involved, I'm going to be posting the notes from these
meetings (taken by an independent note-taken, and reviewed/redacted by
the participants before being made public).
I want to be very clear that no final decisions were made at these
meetings, but they were very helpful in helping those of us working on
concrete proposals. You should start seeing PEPs 80xx filling out with
content over the next few weeks. *Those* are the reference documents -
these notes are simply a record of what came out of discussions.
If you want to reply to and discuss particular points from these,
*please* reply to the list, change the subject line, and clearly quote
only the relevant part. There is a lot of content here and nothing to be
gained by repeating it endlessly. (Also, if you want to thank me for
copy-pasting into an email, it really is unnecessary but please do it
off-list. We've already passed on our thanks to the note-taker as well.)
For this second meeting, we reduced the audience to those particularly
interested in the governance models. We had four represented there,
which will be written up as PEPs 8010, 8011, 8012 and 8013 over the next
few weeks. I have inserted links to the current drafts of these in the
notes, though at this stage they are mostly still placeholders.
Again, the proposals that we will vote on will be accurately described
in the PEPs. the notes here are basically inaccurate summaries of the
discussion, but we are sharing the notes to help everyone get a sense of
what values we are thinking about when designing proposals, and the
aspects of Python development that we like and the ones we want to change.
This is not the thread to start arguing about details - if anything in
this email makes you upset or nervous, please assume that the email is
at fault and wait for the actual proposals.
Cheers,
Steve
---
The previous meeting showed that there were three main areas of concern:
* What do we want the culture of the team to be?
* How do we want to interact with each other and with the larger Python
community?
* How can we build a system that encourages those interactions?
* Example: if we don't use a mailing list, what do we use?
* What's the five year plan of python?
* How do we decide on a governance model?
These are deeply interrelated questions; notes that follow attempt to
summarize various contributor's points:
* The answers to the first two questions can be determined by the new
governance, whatever that is.
* We must quickly get away from the perception that Python is leaderless.
* We need specific structures, with specific people.
* Both those structures and the people must be selected by a process
that is perceived to be fair and open, without all our energy being
consumed by debate about minutia.
* It will be difficult to decide anything else until there is a clear
leadership structure.
* If we have multiple people who want a focus on async, or on
performance, or on typing, we need some way to resolve what should be
the focus for the next five years.
* These all influence each other. "Where do we want Python to go?" is
very germane to "what should the leadership model be?"
* We can end up in a rathole. Can we identify constituencies that we
want to serve? Education, science, kids, whatever. The structure is less
important than choosing a structure and working towards goals that serve
constituencies within that structure.
* Governance is also heavily tied to communication: how do we make
mundane decisions, how do we resolve controversies? This is all about
communication. Other languages have specified details of their
communication models in their governance arrangement: we put our notes
here, we communicate with this channel, and so on
* There may be different decision-making and communication models for
different areas.
* If you have a BDFL, do they take on everything Guido took on? Or are
they the titular spokesperson who interfaces with the public, and
delegates other decisions to committees?
* Having no governance model is worse than having a suboptimal model.
* The US Constitution was written knowing that the first order of
business would be the Bill of Rights.
* What is our list of things that we know we need to deal with as soon
as we have a governance model?
* Deciding how to commit to a governance model has highest priority.
* Our goal should be to achieve general consensus on what looks like a
fair voting model before we vote.
* Wherever we end up at the end, we want the leadership to be perceived
as legitimate and backed by the community.
* The greater good is more important than any particular desired detail.
* The governance model has to be backed by goodwill.
* Should we first determine where Python is going, in order to ensure
that the governance model supports it?
* "I disagree with the details but I support the process" should be the goal
* Python's governance model has been an active, top-down decision maker;
most open source projects have a much more hands-off steering council.
Split Guido's current roles across both formal, hands-off top-down
model, and an organic, bottom-up community based model.
* Do we know who wants to take a leadership role?
* Are there people who want to actively be involved as a BDFL, a
triumvirate, a council, and so on?
* If we only have one volunteer for BDFL, this is a waste of time.
* Triumvirates form as a mechanism for resolving conflict amongst leaders.
* What if no one wants to step into a leadership role?
* More people will be involved in lesser roles.
* We can probably find five people who want to be involved in a council.
* But perhaps nothing will happen with a leadership group of that size.
* What about looking at it the other way: who will go along with
whatever structure gets put in place?
* Those people are contributors, not leaders, and they don't have to be
involved in the discussion.
* Three main proposals:
(1) BDFL with advisory council and working groups model.
(2) No BDFL, steering committee of say three people.
(3) pure democracy, community driven, only working groups.
* Can we aim for initial draft PEPs October 1st?
* Each of these can be parameterized
* If no one is interested enough to even write a proposal, we can reject it.
* A rejection of a specific proposal is not an endorsement of its opposite.
* Roles granted in perpetuity? Or a cycle?
* This question should go into a session
* These are parameters to the proposals
--------------------------------------------------
Follow up two:
Champion your ideas
But remember this is not a competition; this is about doing what's best
for Python
Quick summary of earlier voting discussion:
restricted to core developers who currently have commit bit (or who have
commit bit by end of this week)
ask people who are not affected by the decision to abstain
private repo to post votes
* votes will be made public after; this is not an anonymous vote
* voting for individual positions later will likely be anonymous
* this system encourages dialog
* many people are fine with any of the proposed options but they have
opinions about what is best
* a public process helps avoid backroom complaining
* it seems acceptable to have public vote on governance issues
* quorum is whoever shows up to vote
* 50% + 1. Supermajority is only 14 people more, so seems unnecessary
* there are only 93 people in the set of possible voters
*When creating proposals that involve a BDFL, or other role, do not name
a person or group of people. Name a mechanism for choosing that person
or group of people.
*Put in as many specifics as necessary to make your proposal attractive
*The constitution of the united states says how to update itself; do the
same in a governance proposal.
Proposal One: No BDFL, all democracy all the time
PEP 8012 - https://www.python.org/dev/peps/pep-8012/
* Inspired by Rust and Django
* Working groups are self-selected from people interested in focus areas
* Non-experts in an area trust that experts will do well in an area
* Regular decision making process is mostly "go ahead and do it"
* Controversial decisions require a process with documented phases: make
a PEP, find a champion, get comments, set a deadline, decide on whether
it is accepted, rejected or postponed
* How does veto work? Put it to a vote.
* The "voice of Python" is expressed not by a person, but by the design
documents produced
* If you don't want assignment expressions, vote for my proposal
Proposal Two: external auditors
PEP 8013 - https://www.python.org/dev/peps/pep-8013/
* Working groups should continue to go forward — the people who are
working on a specific PEP, and not necessarily core developers.
* Normal decision process should continue
* Controversial decisions should be taken to an elected group of three
people who are NOT core developers who are arbiters of process concerns.
Call them the auditors.
* Appointed for how long? A year? Years? A release? This is a parameter.
* No term limit; you can be re-elected
* Not a developer; an escalation mechanism for when developers cannot
reach consensus
* Every time you take a controversial decision to the auditors, you have
to explain the problem in detail well enough to convince them that
you've done due diligence about design, user impact, and so on.
* Auditors can veto controversial decisions until there is enough
diligence done
* Auditors can require that a decision goes to a vote if it is still
controversial
* Auditors can require that more people weigh in
* Auditors cannot mess things up by proposing new bad stuff; they can
only slow down (hopefully bad) decisions
* We have a list of names of notable people who would be great at this;
whether they'd be willing is another question
* Microsoft would offer employees for this role, but maybe core
developers are opposed to corporate influence
Proposal Three: Trivumvirate of core developers
PEP 8011 - https://www.python.org/dev/peps/pep-8011/
* a similar scheme to Proposal Two, but where the triumvirate must be
core developers
* We are too used to the BDFL model and may be worried to change it
* Should be a diverse group of three people who can work together.
* These people must be trusted; if that trust breaks down then we have a
crisis — but of course we can always change the governance model if this
doesn't work
* Elected for longer than a year; semi permanent
* Role similar to previous BDFL, but with multiple people coming to
consensus.
Proposal Four: Find another BDFL
PEP 8010 - https://www.python.org/dev/peps/pep-8010/
* Elect a BDFL
* Continue with working groups
* Create a council as an advisory group to the BDFL, help find
delegates, and so on
* The BDFL has a broad view of the python ecosystem, and weigh in on
large scale changes, say to the grammar, or changes that have broad
impact, like deciding between performance and compatibility.
* Must be seen as "the voice of Python"
* The BDFL champions the overall vision of the evolution of the
language, with the support of the community
* "For life" is a misnomer. There should be a recall process or vote of
no confidence.
* Release manager has an important advisory role
Thoughts:
* These proposals are consistent in that most of the work is done in
informal groups, there is some sort of leadership council who ensures
that processes are followed.
* The working group and PEP process is pretty much the same in all these
proposals
* The fundamental differences are in who has authority: (1) no
authority, self-policing, (2) authority over process vested in
non-developers, (3) authority vested in a group of developers and (4)
one BDFL
* We can always make a decision, try it, and if it doesn't have good
outcomes, have this conversation again in two years
* Consider the role of release manager in all of these; they have a lot
of power in that they can file a release-blocking bug against stuff they
don't like
* Are there issues with how we induct/vote in new core developers?
* Individual working groups are autonomous and have authority to decide
who is core to their working group
* How do we solve controversial issues? Take it to a vote, take it to
auditors, take it to the BDFL.
* Do we have examples of community-based open-source projects that are
run using proposal 2? No. But we have lots of examples of that model in
business-run projects, non-profit-run projects, and so on.
* There are examples of members of technical committees secretly
proposing features and then approving them, sock puppeting, and so on.
We would want to avoid that. Similarly a BDFL will need to appoint a
delegate if they are also proposing PEPs, and so on.
* Need a graceful way for a leader to step down when their life requires
them to do so. Burnout is real and insidious.
* Be aware of conflicts of interest, double dealing. Financial self
dealing is probably not a problem for us.
* How do we ensure consistency in decision making?
* Excessive churn in leadership works against this.
* Having a set of core principles will help.
* Election campaigning for leadership roles is a mechanism for people
to choose direction.
* Would be helpful if every PEP had a core developer to sponsor it.
Particularly if final approval moves to python core devs.
Hi all
At the sprints this last week, probably unsurprisingly, we had some
discussions relating to the future of Python's governance. Since not
everyone could be involved, I'm going to be posting the notes from these
meetings (taken by an independent note-taken, and reviewed/redacted by
the participants before being made public).
I want to be very clear that no final decisions were made at these
meetings, but they were very helpful in helping those of us working on
concrete proposals. You should start seeing PEPs 80xx filling out with
content over the next few weeks. *Those* are the reference documents -
these notes are simply a record of what came out.
If you want to reply to and discuss particular points from these,
*please* reply to the list, change the subject line, and clearly quote
only the relevant part. There is a lot of content here and nothing to be
gained by repeating it endlessly. (Also, if you want to thank me for
copy-pasting into an email, it really is unnecessary but please do it
off-list. We've already passed on our thanks to the note-taker as well.)
For this first meeting, roughly 30 of us sat/stood in a circle and
briefly answered two questions:
* what are you most concerned about right now?
* in one word, what do you like most about Python?
These notes are an anonymised, paraphrased, reorganised summary of the
responses. Responses that deserved an immediate follow up have (as far
as I'm aware) received it already. So take this as a bit more insight
into community sentiment than could otherwise be obtained over email,
but as nothing more significant than that.
Cheers,
Steve
---
Python's Benevolent-Dictator-For-Life (BDFL) Guido has stepped down,
which raises the question of how Python's core development team should
proceed when making decisions about changes to Python. The attendees of
the sprint had a meeting to sit down and all concisely express their
biggest concerns. I took notes as people were speaking; hopefully I
captured the gist of what they were saying if not their exact words.
I'll start with a quick summary and the plan for immediate next steps,
and then give individual points loosely grouped by broad area of concern.
Executive summary:
The biggest areas of concern are:
* Choosing how to choose a new governance model
* The principles that will guide the future of python
* Effective, respectful communication and related social factors
* related: Code of conduct issues, which already have a PSF working
group looking into them.
We went around the room and asked people to give a one or two word
summary of what they like about Python.
* community
* people
* elegance
* consistency
* ease for non-experts
* good taste
* accessibility
* opportunity
* productivity
* trust
* zen
* fun
* openness
* thoughtfulness
* Monty :-)
Next steps:
* Digest what we've discussed overnight
* Meet in the morning and organize by areas of particular concern
* Discuss further
* Report back
Specific concerns raised by individuals follow. These have been
anonymized and rearranged, and are individual contributions and do not
reflect any official position, or even necessarily a majority position
of the core development team.
Introductory thoughts:
* Complexity is real
* Any number of plans could work
* What behaviours help communities be effective?
* Which produce roadblocks and challenges?
* What do we value about Python?
Choosing how to choose:
* There will be various proposals for governance models. How do we pick
one? Can we get to consensus on that?
* There's a PEP out to discuss how this process works in other languages.
* Vote on a committee that makes governance recommendations
* Give a small group of people a mandate to study and make recommendations
* Can we determine what are roles that need to be filled?
* Do not get bogged down in the meta-question of how to choose how to
choose.
* Any important change requires a working group of experts in the
specific area affected by the change. How to choose members of this group?
* Can we define the scope of problems that we need to bring to a higher
authority?
* Having working groups with autonomy is great, but there will be things
where all the threads come together. Changes to the C API, changes to
the core syntax.
* We have always appealed to Guido's sensibilities, and that's where the
power vacuum is now. Think about something like the Debian technical
committee, where they make decisions that affect everyone in that community.
* Some people will be unhappy with whatever decision is made, but we
want people to agree that there is a clear authority and a process that
is respected and legitimate.
* Our existing model has BDFL delegates for specific issues. How should
power be delegated to make specific decisions about features? Who can
say "this will not happen"?
* It's pretty nice to have a dictatorship when you have a good dictator.
A democracy does not guarantee that the best choice will be made, or
even that the will of the majority is carried out.
* The language is now sufficiently complex that it may be difficult to
have any individual that understands the whole thing enough to make
decisions unilaterally.
* Without a way to make the decision it is all talk; how do we have a
consensus?
* We should accept that we're not going to get to unanimity
* What is the externally visible legitimacy of any decision process? If
52% say yes and the other 48% say no, is the decision legitimate?
* The state we're in now is scary but many other projects have been
here, like numpy. We need to shift from our respect for Guido to a
shared sense of what's the right process, even if we don't agree on
every detail. A 51% vote is not a good thing.
* We are experts on programming languages, not on governance and
decision making. Maybe bring in an expert on decision making models if
this meta problem is going to get really thorny.
* There are models of decision making that have been studied by experts
and their characteristics are known. These models are all pretty good;
pick a decision-making model and discuss it.
* Think about what has worked well in the past and has not worked well.
We've had a successful process delegating issues before. Maybe we don't
need to worry too much about the fine details of delegation. We could
fall into the trap of making this process too complicated, too
overspecified and too legalistic.
* The core development community is not as diverse as the broader Python
community. Attitudes of the people making these governance decisions may
not be aligned with those of the communities they're intending to serve.
How can we address this?
* People are too afraid of changes; we don't need a PEP or a formal
process or a decision from Guido for everything. Some changes can just
be made by people we trust to make good decisions.
* Continue to rely on experts when making decisions about their areas of
expertise.
* There are disruption risks of changing too quickly but there are
existential risks in changing too slowly.
* The model so far is that the patriarch lets the kids run around but
keeps them from running over the cliff.
* Making one person or a small group an oracle for what is good is
unfair and unrealistic, particularly if they have to not only understand
and make decisions about every aspect of the language but also police
bad process outcomes.
* Consider models of projects that work; get people involved who are
experts on project management and process. We need a Counsellor Troi for
this project. Get a professional coach involved, who is already involved
in successfully governed Python projects, for example the Jupyter
project and the Django project.
* If someone does not aspire to be leadership but still has something to
offer, are they shut out of the decision-making process? If important
things come up, people with depth of experience need to be heard and
feel that they are heard.
* No one really wants decision by committee and what that entails.
* Historically we see that when there is a change in governance model
and power structure, there will be a challenge. Hopefully there will not
be a villain that brings us together.
* Whatever we do, hopefully it will not require more effort by the
volunteers of the core team; we like to work on technical issues rather
than navigating political organizations and heavyweight processes.
* Our work is founded on trust; take that into account and keep it from
falling apart
* Every core developer should have an idea of what they want to see from
Python in the next five years. That will motivate choice of governance
model.
* Keep moving forward and get a governance decision made. We don't want
to make a panic decision, but we don't want to sit and wait either.
Figure out what we want and execute on it.
* This is a human factors problem; burnout exists everywhere in an
organization. Understand the roles that we are trying to refactor.
* Things will not be the same, some changes will go smoothly, and some
will not, and then they'll say that in the old days, things were great.
* Define what roles need to be filled; that affects everything.
* We should choose how we're going to choose before we leave, while
being considerate of people who are not here.
* Be clear that any new model of governance is specifically for core
devs, not for the Python community as a whole
What's important?
* Python is a popular language; anything we change has a large impact
and we need to take that seriously. Can we agree on how impactful
decisions can be, and make sure that a governance process takes impact
seriously?
* Explicit is better than implicit; Guido is a mountain of implicit
knowledge, and there is no one close to that.
* We need a set of slogans or principles that summarize our design
values; the Zen of Python is poetic and aspirational, but we should
decide more specifically what Python should be or we will end up with C++
* What are the goals of Python as a language? Do we value stability, or
evolving to achieve feature parity with other languages? Do we want to
evolve fast or slow? Do we value performance or compatibility? It's easy
to say "both", but design is about making compromises.
The relationship between the PSF board and the core dev community
* The role of a board member is to fulfill the mission of the
organization in accordance with its guiding principles.
* What are those guiding principles? Consistency, stability? What else?
* What specific communities of users and developers are served?
* Where does the PSF and its board of directors fit in to this decision?
* Core developers don't see the PSF very often, and non-core-dev board
members don't see much of what the developers are doing.
* Does the board want to be involved in this process?
* We should make sure that the board and the core devs are on the same
track and share common goals
* There is a clear difference between how the board sees the core
developers and what the core developers do. New board members often ask
how much influence they have on how core developers do their work. Very
little.
* The PSF owns the trademark and therefore what is done with the codebase.
* Core developers are expected to participate in language development
and writing code, not, say, raising money. The foundation manages that.
Communicating decisions
* How will this decision be communicated to the world?
* People don't like to read long governance documents.
* Get this sorted out well before the next pycon. The decision should be
formally announced there, but it should be well known and accepted
throughout the community long before that.
Email is terrible, except when it isn't
* The email list mechanism is both boring and annoying. Can we find
another tool?
* Python dev mailing list has 20K subscribers which is a scarily large
number given the level of discussion.
* The mailing list used to function better:
* The participants were not necessarily nicer; some were mean, but the
problem solving was effective.
* How did those people interact together?
* Get old timers out of retirement to participate and model effective
problem solving.
* What communication techniques can be used for problem solving that
have intellectual depth while ensuring that everyone is heard?
* It's easy to criticize the email lists but remember that these lists
do in general work pretty well.
Process suggestions and concerns
* When someone exits a role, consider an exit interview. How do we not
repeat mistakes of the past? (Not to put Guido on the spot.)
* We took Guido for granted, and now need codification of those processes.
* The PEP process is the biggest part of how we design python and it
needs to be redesigned. We need a tighter PEP process with stages and
rules.
* The PEP process is more difficult than it needs to be.
Conduct, and its code
* The forum process dismisses and belittles people. That's not OK on the
face of it, but worse, the people who are bullied are allies,
contributors and advocates for this language.
* The code of conduct feels like it is ostensibly there to protect
people from abuse, but in fact can be used as a weapon against people
who want to contribute
* Python dev doesn't feel like a safe forum. We can't continue to let
that happen. Women with deep knowledge and industry experience have real
serious reasons to avoid this forum.
* We need to change our interactions before a change of governance has a
chance to work
* There are "hot" topics that people are overly "active" in their
participation; the code of conduct should be applied there. But let's
remember that in general our communication mechanisms work well most of
the time. We're capable of making good decisions.
* If you see something that doesn't seem right on a list, mail a
moderator; moderators don't see everything.
* Maybe apologize once in a while. We have a responsibility to each
other and to owning our mistakes.
* Being a core developer is as much about establishing trust with each
other as it does with technical ability. Work on establishing trust.
* The metric of a successful technical decision is not its technical
merit; it's whether everyone feels like they were heard. If it's a hard
technical decision then you need a diverse set of opinions to get
confidence that you've arrived at a good decision. And making people
feel heard keeps them around and wanting to participate.
* The code of conduct is supposed to make people feel more included but
can make people feel excluded.
* There are experts on this; get them involved. They're sensitive to
being humane through this process. Pycon brought in consultants for this.
* There is a conduct working group taking a holistic view, the board has
approved getting help on this.
* How does this affect core devs? We need buy-in.
* The process is not far involved yet; just got budget.
* Code of conduct enforcement should be prompt, kind and firm; don't get
into a state where everyone is screaming at each other.
I've deployed the bot to automerge CPython pull request on the master
branch.
One benefit of this is you don't need to worry about replacing "#" into
"GH-".
To get the bot to automerge:
- first edit the PR title and description, to be the commit message you
want to use.
- approve the PR (so it will have "awaiting merge" label)
- apply the "🤖 automerge" label.
It will wait for ALL status checks to pass, and merge the PR, replacing `#`
with `GH-`
I've made a demo video on YouTube: https://youtu.be/p85YtKKLNno
See also previous discussions in
https://github.com/python/core-workflow/issues/29https://github.com/python/bedevere/issues/14
The previous way of merging PR still works. If you prefer merging the PR
yourself, just don't apply the "🤖 automerge" label.
Mariatta
ᐧ
Someone left
https://github.com/python/cpython/pull/9195#issuecomment-420646466 which
was clearly written to upset Victor and insult him. I warned the person
that such behaviour is not okay and future insults would have
ramifications (I was actually asked to ban this person to begin with but I
gave them the benefit of the doubt considering how heated the topic
involved has become). They then decided to seek me out on Twitter berate me
there for my warning:
https://twitter.com/dolkensp/status/1039949212832722944 . For that I have
followed through with my warning and banned them from the org.
Hi.
I've found that my MSDN subscription has expired.
I don't use Window for daily tasks but sometimes need it for fixing
Windows-specific bugs.
Could you renew it or issue a new one?
--
Thanks,
Andrew Svetlov