Re: [python-committers] Cheryl Sabella promoted as core dev

[Mariatta Wijaya]

Congrats, Cheryl.

Thank you for all your contributions so far. Glad to have you on the team.
ᐧ

On Tue, Feb 19, 2019 at 9:19 AM Victor Stinner  wrote:

> Hi,
>
> I opened a vote during 1 week to promote Cheryl Sabella. She got the
> excellent score of 21 “+1” vs 0 “-1” with very encouraging comments.
> Moreover, the Steering Council accepted the vote.
>
> https://discuss.python.org/t/vote-to-promote-cheryl-sabella-as-a-core-developer/862
>
> Welcome aboard Cheryl!
>
> I offered to mentor her for one month to guide her in her new
> responsibilities. For example, I asked her to ask me before merging a
> pull request.
>
> Cheryl: Would you like to introduce yourself shortly?
>
> --
>
> I sent an email to GitHub admins to add her to the GitHub python-core
> team and to subscribe her to the python-committers mailing list. In
> the meanwhile, I added her in copy of this email.
>
> Ah, I already added her to
> https://discuss.python.org/groups/committers and switcher the
> "committer" bit in her https://bugs.python.org/user25861 account :-)
>
> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> 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] Duplicate ("triplicate"?) Github notifications on Roundup

[Mariatta Wijaya]

Know issue:
https://github.com/python/bugs.python.org/issues/12#issuecomment-450681871

On Sun, Feb 3, 2019, 6:47 AM Antoine Pitrou 
> Hello,
>
> For some time now, Github notifications on Roundup when a PR is open
> arrive three times instead of one.  Is this a known issue?
>
> Regards
>
> Antoine.
> ___
> 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] REMINDER: governance vote is closing by end of this week

[Mariatta Wijaya]

You have about 15 hours 12 minutes left to vote, if you haven't already.

On Wed, Dec 12, 2018, 1:44 AM Łukasz Langa  You have time until December 16th AoE to rank proposals and cast your
> ballot. More information in PEP 8001.
>
> Note: reading the candidate PEPs will take you a while. Don't wait until
> Sunday.
>
> - Ł
> ___
> 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/

[python-committers] Blurb-it is now available

[Mariatta Wijaya]

Blurb-it is now available. For details, please see my post on discourse

https://discuss.python.org/t/blurb-it-is-now-available/528
ᐧ
___
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] A plea to stop last-minute changes to governance PEPs

[Mariatta Wijaya]

 As a reminder, PEP 8001 states:

"November 16th, 2018 to November 30th, 2018 is the official governance PEP
review period. We discourage the PEP authors from making major substantive
changes during this period, although it is expected that minor tweaks may
occur, as the result of this discussion period."

Looking at the commit history, the last change to PEP 8016 was on Nov 15 my
timezone, and I'm assuming it was Nov 15 in PEP 8016 authors' timezone too,
so I think it was still allowed. There shouldn't be any more major changes
going forward though.

I would suggest that PEP 8001 can also say that once voting start (Dec 1),
PEPs 801x should be locked and not editable anymore.


On Sun, Nov 18, 2018, 3:17 AM Antoine Pitrou 
> Hello folks,
>
> A couple days ago Nathaniel pushed significant changes to his governance
> PEP (PEP 8016).  This means some governance PEPs are apparently still
> *not* finalized.  This raises a problem: when can we consider that we
> are reading the final version of a proposal (barring wording fixes or
> improvements), not some work in progress draft?
>
> Not everyone keeps an eye daily on PEP changes and discussions.  It
> would be nice to be able to make one's mind at an idle pace.  But that
> requires that PEP authors don't make last-minute changes in an attempt
> to gather more support.
>
> In my vote, I may have to devaluate those proposals that keep changing
> in the last days before the vote, because it doesn't sound like the
> author can be trusted to propose a stable model.
>
> Regards
>
> Antoine.
> ___
> 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] Timeline to vote for a governance PEP

[Mariatta Wijaya]

>
> Shouldn't people who were not involved in the individual creation
> processes at least get two weeks to review the final work
> to make up their mind before entering a voting period ?
> It seems like we're completely skipping the review phase of the
> regular PEP process and going straight from PEP writing to
> a vote:



The period of Oct 8 (date when PEPs were due) up until Nov 15 (before
voting start) was meant as the "review" period, and this was stated in my
original email about timeline:
https://mail.python.org/pipermail/python-committers/2018-August/005960.html

I did propose that there was a period where no more changes to PEP should
be made.

Copy pasting text from that email

*Oct 1 - Nov 15: Review period.*
> All core developers will review the PEPs, and ask any questions to the PEP
> author. This timeline allows for enough time for all core devs to carefully
> review each PEPs, and for authors to respond.
>


> *Review phase 1: Oct 1- Nov 1:* Allow changes and tweaks to the proposed
> PEPs.
> I figured people will have questions and will need to clarify the PEPs
> during this period. But if we want the PEP to be final by Oct 1, that's
> fine by me. maybe allow typo fixes still.
>


> *Review phase 2: Nov 1 00:00:00 UTC*: No more changes to the above PEPs.
> No more tweaks to these PEPs. PRs to these PEPs should be rejected.
> This is the final chance to carefully review all governance PEPs, and
> formulate your decisions.
>


> *Nov 15 00:00:00 UTC: Voting for new governance model starts, and will go
> for 2 weeks*
> Send reminders for folks to vote.


But I guess some people think that whole fixed timeline thing was bad idea,
so I didn't go and enforce all of this (also I took a break from life and
reduced responsibilities).

ᐧ
___
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] 1 week to Oct 1

[Mariatta Wijaya]

Really sorry folks, but I also would like to request an extension, by one
week to Oct 8.
It's not because I've been slacking; I've started a five-page document
(only Barry has seen it), but I still need his help before it can be ready
for the public.
In addition, I'm facing personal health issue. I'll be unable to work on
the proposal for the next few days.

I hope this will be ok with you all. Sorry again for delaying this process.

Although we should still be good to "vote" on proposals by Mid November. I
still think it would be good for that PEP 8001 to be ready sooner, so we
all have good understanding of how this all will go down.

Thanks.
ᐧ
___
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] Council / board (Was: 1 week to Oct 1)

[Mariatta Wijaya]

> * Mariatta proposed to require to have a least one woman in that
> council.

> Why stop at women?


My actual wording was: "not all white men", which actually means quite
different from "must include one woman".

I don't appreciate you jumping straight to accusing me for discrimination.
Assume positive intent, and ask for clarity before scrutinizing and making
accusations.

My PEP will provide guideline on how members of the group should be
nominated, and it is a long list. It will not name names. Only once the PEP
has been accepted that people can nominate folks to fill the role, and
there will be another round of voting.

Some of the questions asked by Victor will be answered in the PEP that I'm
writing, so I will not answer now.
___
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] 1 week to Oct 1

[Mariatta Wijaya]

It is now 7 days until October 1, the deadline for coming up with Python
Governance PEPs.

Some still relevant links:

- https://www.python.org/dev/peps/pep-8000/ Python Language Governance
Proposal Overview
- https://www.python.org/dev/peps/pep-8001 Python Governance Voting Process
- https://www.python.org/dev/peps/pep-8002 Open source governance survey

These are current ideas and proposals, some are placeholders still.

- https://www.python.org/dev/peps/pep-8010 The BDFL Governance Model
- https://www.python.org/dev/peps/pep-8011 The Council Governance Model
(I'm claiming this PEP)
- https://www.python.org/dev/peps/pep-8012 The Community Governance Model
- https://www.python.org/dev/peps/pep-8013/ The External Council Governance
Model
- https://www.python.org/dev/peps/pep-8014/ The Commons Governance Model

I have some questions:

1. Is everyone still ok with the Oct 1 as deadline for coming up with
governance PEPs?

2. How do we discuss these PEPs?

3. At the sprint, there's a small workgroup formed for coming up with the
procedure to vote. How is that coming? Could someone please write up a
brief summary? (perhaps as a separate email thread) I think it would be
great to have this written up soon, before Oct 1.

Thanks.


Mariatta
ᐧ
___
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] I have blocked someone from the Python org

[Mariatta Wijaya]

Thanks for handling it, Brett.

That kind of behavior is not something we need to allow or tolerate in this
community.
I'm fine with banning.

Mariatta

ᐧ

On Thu, Sep 13, 2018 at 9:18 AM Brett Cannon  wrote:

> 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.
> ___
> 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] Automerge bot deployed

[Mariatta Wijaya]

Update to the automerge bot:

It will not merge unless there is "CLA signed" label, and no "DO-NOT-MERGE"
label.

Again, please edit the PR title and description before adding the `烙
automerge` label.
The PR title and description will be used as the squashed commit message.

Mariattaᐧ
ᐧ
___
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] Automerge bot deployed

[Mariatta Wijaya]

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/29
https://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
ᐧ
___
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] 3 weeks to Oct 1

[Mariatta Wijaya]

Friendly reminder that it is now 3 weeks until October 1, the deadline for
coming up with Python Governance PEPs.

Barry has started several Governance PEPs:

- https://www.python.org/dev/peps/pep-8000/ Python Language Governance
Proposal Overview
- https://www.python.org/dev/peps/pep-8001 Python Governance Voting Process
- https://www.python.org/dev/peps/pep-8002 Open source governance survey

The following three PEPs are for placeholders. I believe the idea is to
have people claim the PEP they're planning to write, and finish writing the
PEP.

- https://www.python.org/dev/peps/pep-8010 The BDFL Governance Model
- https://www.python.org/dev/peps/pep-8011 The Council Governance Model
- https://www.python.org/dev/peps/pep-8012 The Community Governance Model

And don't forget about the lucky PEP number 13.
https://www.python.org/dev/peps/pep-0013/

Mariatta
ᐧ
___
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] Organizing an informational PEP on project governance options (was Re: Transfer of power)

[Mariatta Wijaya]

Hi Nathaniel,

I know you mentioned my name earlier, and thanks for thinking of me. But
I'm really sorry, I just don't have the bandwidth to help out with this
right now.

Not sure if you've made any progress yet. Since the intention is to collect
information of the various governance models out there, I was thinking
perhaps you can ask non core developers to help out with this effort. So
that way you're not constrained by the limited number of core devs and
their limited free time available.

What do you think?

Mariatta


On Wed, Aug 1, 2018 at 8:17 PM Nathaniel Smith  wrote:

> I'm sorry, I seem to have accidentally licked a cookie [1] here. I'm still
> keen to see this happen and to be a part of it, and have been trying to be
> find the spoons to take the lead on organizing, but it's been a few weeks
> now and that hasn't happened yet [2].
>
> Does anyone else want to take the lead here? A number of people have
> expressed interest in helping or in making introductions to other
> communities, and I think the next step would be to organize some kind of
> kick off meeting to rough out an outline and start divvying up work.
>
> -n
>
> [1] http://communitymgt.wikia.com/wiki/Cookie_Licking
> [2] not to go into too many details, but basically I'm currently sick,
> unemployed, and broke, which isn't a crisis but sorting it out is sucking
> up a lot of energy.
>
> On Jul 13, 2018 04:31, "Nathaniel Smith"  wrote:
>
> On Thu, Jul 12, 2018 at 6:35 PM, Łukasz Langa  wrote:
> > I'm +1 to an Informational PEP around the state of the art in project
> governance.
>
> I think this is a great idea. There's a lot of experience out there on
> different governance models, but of course any given project only uses
> one of them, so knowledge about what works and what doesn't is pretty
> fragmented across the F/OSS community. And this is a really important
> decision for us and our users, so we should do due diligence. For
> example, we should think this through at least as carefully as we
> thought through Github vs. Gitlab :-). A PEP is a good format to start
> doing that.
>
> I volunteer to co-author such a PEP. But I'm not up to doing it on my
> own. So... who else wants to be a co-author? (I'm not going to
> pressure anyone, but Brett, Mariatta, and Carol, please know that your
> names were the first ones that jumped to my mind when thinking about
> this :-).)
>
> What I'm thinking:
>
> - While this might eventually produce some recommendations, the
> immediate goal would just be to collect together different options and
> ideas and point out their trade-offs. I'm guessing most core devs
> aren't interested in becoming experts on open-source governance, so
> the goal here would be to help the broader community get up to speed
> and have a more informed discussion [1].
>
> - As per the general PEP philosophy, I think this is best done by
> having some amount of general discussion on
> python-dev/python-committers, plus a small group of coauthors (say 2-4
> people) who take responsibility for filtering ideas and organizing
> them in a coherent document.
>
> - Places where we'll want to look for ideas:
>   - The thread already happening on python-committers
>   - Whatever books / articles / blog posts / etc. we can find (e.g. I
> know Karl Fogel's Producing OSS book has some good discussion)
>   - Other major projects in a similar position to CPython (e.g.,
> node.js, Rust) -- what do they do, and what parts are they
> happy/not-happy about?
>   - Large Python projects (e.g. Django) -- likewise
>
> If you have suggestions for particularly interesting projects or
> excellent writing on the topic, then this thread would be a good place
> to mention them.
>
> -n
>
> [1] The NumPy project has put a lot of energy into working through
> governance issues over the last few years, and one thing that
> definitely helped was coming up with some "assigned reading" ahead of
> the main sprint where we talked about this. NumPy's problems are/were
> pretty different from CPython's, but I'm imagining this PEP as filling
> a similar role.
>
>
> --
> Nathaniel J. Smith -- https://vorpus.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/
>
___
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] Push rights for new Jython contributors

[Mariatta Wijaya]

Your question is regarding push access to hg.python.org/jython, right?
Seems like according to Jython's devguide
, you'll need to send the
SSH key to hgaccou...@python.org.
But it also seems to be the same email address we used when adding
committers to hg.python.org/cpython.
Now that we're on GitHub, we don't send over SSH keys anymore.


On Sun, Aug 5, 2018, 5:23 PM fwierzbi...@gmail.com 
wrote:

> It's been a while since we added a Jython contributor, so I no longer
> know what the process would be and we have at least one person we'd
> like to add.
>
> Previously, I think the process was:
>
> 1) Contributor creates a user on bugs.python.org using their real name.
> 2) Contributor signs the PSF agreement (not the Jython-specific one,
> which is not used anymore).
> 3) Someone gives contributor push rights to hg.python.org.
>
> Is this still the process for Jython?
>
> Kind regards,
>
> Frank Wierzbicki
> ___
> 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] Reminder of BDFL succession timeline + CFP

[Mariatta Wijaya]

Thanks all for voicing your concerns and all the feedback.
So far I hear people opposing the strict deadline because they're afraid it
means we'll be making rush decisions for the sake of meeting deadlines.

Well here are my reasonings of why I'm setting deadlines and timelines:

We all know it, discussions in mailing list can go on forever. And now that
we don't have a BDFL who will shut down and end discussions, these things
can really go literally forever. Therefore we should timebox these
discussions.

I believe that none of us actually want Python without governance and
without decision forever. The Python community is waiting for core
developers to come together and figure out Guido's successor.

For myself, January 1, 2019 is reasonable deadline, it will be 6 months
since Guido announced his permanent vacation.

In separate thread, it seems that we're in agreement that Oct 1, 2018 for
deadline to come up with proposals of governance model.

So then, what needs to happen between Oct 1 to Jan 1? (3 months period?) How
do we go from "here are the proposed governance model" into "we have
selected the successor(s)"?
Clearly, if we want to have decision by Jan 1, people can't still be
arguing about governance model on Dec 31st. If we're going to vote on
things, people need to know when they need to show up to vote. We probably
need someone to volunteer and set up the voting system, or get in touch
with The PSF for setting it up, and maybe account for flexibilities in case
there are last minute technical difficulties and so on. All of these
require coordination and concerted effort.

>From there, I've started breaking down the different phases of how this
will go, and also allowing ample time for people to catch up and read their
emails. For example, in my timeline, I suggested 2 weeks time of voting in
each round. In reality, voting is probably just going to take a few clicks
on a website, not 2 full weeks.

I'm just drawing from my own personal experience of having organize and
coordinate a group of volunteers. What I've learned is that the group will
be more successful when each volunteers know their roles, responsibilities,
the goal of the group, and in a lot of cases, they need to know when they
should deliver and complete their task.

Python core devs are all volunteers, living in different timezones, in
different part of the world, and we all have other commitments to our
employer and family. But right now we all have responsibilities to come up
with a plan of succession for this community. It was the last task Guido
gave to us before retiring as BDFL.

These timelines are not meant for you to rush and make decision last minute
just because there is a deadline.
On contrary, I hope that by knowing these timelines ahead of time, you all
can account for these dates, you can be responsible, and if needed, adjust
and plan ahead your volunteering schedule surrounding these dates.

If you are proposing a governance model, and someone else here have
questions about it, it will be appreciated if you can respond in timely
manner, and not wait 4 months before you respond.

Similarly, if you have question and concern or just want to argue about a
proposed governance model, you should do it sooner, within these timeboxed
periods, and not wait until 2020, and don't wait until last minute either.
You'll need to give time for the proposer to respond to you. (again we all
live in different timezones).

I'm also guessing that not everyone here is planning to come up with 100
different proposals, and not everyone here wants to argue at all. Perhaps
some of you are just waiting for the ballot to arrive in the email?
There is value in knowing in advance of when you need to vote, so you can
plan on watching their mailbox, or alert us if they didn't receive the
ballot.

I hope by knowing these timelines people can be more considerate with each
other, and that they'll be able to express their thoughts more effectively
in emails.

Without clear deadlines, sure there is less pressure of not rushing into
making decisions, but it also allows for discussions to stall forever.
I also don't want people to come up with yet a new proposal every other
week.

So I still would like us to have clear deadlines and timebox this whole
succession process.

"clear" does not need to be "strict". What I will try to do is to post
reminders here, a week before the expected "deadline" and ask if people
need extensions, and we'll extend the dates accordingly. (similar to what
Python release managers normally do).
But maybe the extension will be for only another one week or two, not
forever.
What do people think about this?

It seems like several people (Barry, Brett, Steven) and myself are ok with
January 1, 2019 as the a deadline of choosing the successor.
For those opposing the deadlines, do you have a different date in mind?

Here are my proposed timeboxes again, adjusted to AoE timezone, and
including Barry's guidance of using PEP 8k+ 

Re: [python-committers] List of all core developers

[Mariatta Wijaya]

>
> I think it would also be a good idea to include core developers
> of other Python implementations in such a document, in
> separate sections, e.g. for Jython, IronPython, PyPy,
> Stackless, etc


Hmm, I don't think it is should be our (CPython) responsibility to keep
track and maintain the list of the core devs of alternate Python
implementations. Don't they have their own community / website? They have
their own repo, bug tracker, governance model, and everything, right?

Mariatta

On Wed, Aug 1, 2018 at 2:54 PM Eric Snow 
wrote:

> On Wed, Aug 1, 2018 at 3:44 PM M.-A. Lemburg  wrote:
> > On 01.08.2018 23:28, Mariatta Wijaya wrote:
> > > See also an open issue to revamp the Developer log:
> > > https://github.com/python/devguide/issues/390
> > >
> > > Someone has also said that they're working on tracking down the dormant
> > > core devs, but now I can't find that email.
> >
> > I think the log is fine at it is, since it serves a different
> > purpose.
> >
> > The list should be in addition to the log, not replacing it.
> >
> > Resources we already have:
> >
> > * https://devguide.python.org/developers/
> > *
> >
> https://bugs.python.org/user?%40action=search=1&%40pagesize=300&%40sort=username
> > * python-committers Subscribers List (but this is currently only
> >   for list admins to see - perhaps we could make that available
> >   to list members ?!)
> > * https://hg.python.org/committers.txt
> > * for the early days:
> >
> >
> https://raw.githubusercontent.com/python/cpython/e42b705188271da108de42b55d9344642170aa2b/Misc/HISTORY
> >   in combination with
> >
> >
> https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Misc/ACKS
> >   (in those times, there was no direct access to the repo
> >   and all patches had to go through the team around Guido)
>
> There's also:
>
> * the members of the github team
> * folks marked as committers as BPO
>
> I don't recall if these are exposed via public lists though.
>
> -eric
>
> > I think it would also be a good idea to include core developers
> > of other Python implementations in such a document, in
> > separate sections, e.g. for Jython, IronPython, PyPy,
> > Stackless, etc.
>
___
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] Reminder of BDFL succession timeline + CFP

[Mariatta Wijaya]

>
> IIRC we always promoted core devs by popular vote, so I don't think
> this would be a problem.  Do we have any candidates that are currently
> waiting for us deciding on a governance model?


If this new governance model will include core devs being able to vote on
PEPs, then I will have different opinion on how I want to vote or promote
any new core dev.

And maybe that's OK for a few months? I don't recall Guido ever
> accepting PEPs promptly. :)  Setting strict deadlines really seems
> like a last-resort option.


Please don't misunderstand my wanting to set up a deadlines and process as
wanting to rush things.
I'm open to extend the dates, and even wait another year if we need to.
Or do folks want to come up with a completely different process than what
I've proposed?

In the end, I just want to know whether we will come to decision before
2019, 2020, 2021, 2022, .. ?

Mariatta


On Wed, Aug 1, 2018 at 4:06 PM Yury Selivanov 
wrote:

> On Wed, Aug 1, 2018 at 6:44 PM Mariatta Wijaya
>  wrote:
> >
> >
> > Thank you for the responses and concerns.
> >
> > I do want to keep this discussion open and ongoing, and I still think
> that we do need a set deadline on things.
>
> I talked to a few core developers recently (at EuroPython and over
> messengers) and I had an impression that some of them don't like an
> idea of making a decision faster than everybody has a chance to say
> their word.  Some of them are shy to publicly object to having strict
> deadlines, some probably haven't yet seen this thread, some don't have
> time to engage right now. You also see a few -1s in this very thread.
> All in all, I really don't understand why we need to hurry here.
>
> > Currently any undecided PEP is stalled, and no one can pronounce on them.
>
> And maybe that's OK for a few months? I don't recall Guido ever
> accepting PEPs promptly. :)  Setting strict deadlines really seems
> like a last-resort option.
>
> > And we probably won't/can't promote any new core devs until we have new
> governance.
>
> IIRC we always promoted core devs by popular vote, so I don't think
> this would be a problem.  Do we have any candidates that are currently
> waiting for us deciding on a governance model?
>
> Yury
>
___
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] Reminder of BDFL succession timeline + CFP

[Mariatta Wijaya]

Thank you for the responses and concerns.

I do want to keep this discussion open and ongoing, and I still think that
we do need a set deadline on things.
Currently any undecided PEP is stalled, and no one can pronounce on them.
And we probably won't/can't promote any new core devs until we have new
governance.
Someone brought up the idea where core devs would be able to decide/vote on
PEPs and that would affect how we promote core devs.

I hope that having these dates will encourage all of us to prioritize this
issue and coming up with a solution.
If the deadline of January 1st is too short, please propose alternate
dates, but it should not be "whenever".

We may very well end up not having any kind of governance body
> initially and use a simple democratic voting scheme for any
> issues which may arise.


I see this as one proposal of a governance body, and it's acceptable if you
want to propose that we go this route for X years and re-evaluate it again.

It should be ok for us to choose one governance model this time, but decide
on something else next.


Mariatta
___
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] List of all core developers

[Mariatta Wijaya]

See also an open issue to revamp the Developer log:
https://github.com/python/devguide/issues/390

Someone has also said that they're working on tracking down the dormant
core devs, but now I can't find that email.

Mariatta


On Wed, Aug 1, 2018 at 2:15 PM M.-A. Lemburg  wrote:

> It's become fairly obvious that we are missing a list of core
> developers on some site. One we can use as reference and one
> which core devs can also show to other to prove they are
> core developers.
>
> I guess the natural place for such a list is the dev guide,
> but we could also use a page on www.python.org, if that's easier
> to maintain.
>
> Regarding format, I'd suggest to use the same as PSF Fellows
> list:
>
> https://www.python.org/psf/members/#fellows
>
> Thoughts ?
>
> Note: Asking for this now is not completely unintentional.
> The EuroPython Society has something to announce which will
> require such a list.
>
> Thanks,
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts (#1, Aug 01 2018)
> >>> 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/
>
> ___
> 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] Reminder of BDFL succession timeline + CFP

[Mariatta Wijaya]

Thanks! AoE timezone works for me.
In that case, let's use AoE instead of UTC.

Mariatta


On Wed, Aug 1, 2018 at 1:36 PM Thomas Wouters  wrote:

>
>
> On Wed, Aug 1, 2018 at 12:42 PM Mariatta Wijaya 
> wrote:
>
>> 2. Are people ok UTC timezone?
>>
>
> FYI, for the PSF elections and similar deadlines, we use the AoE timezone:
> https://www.timeanddate.com/time/zones/aoe -- it makes it harder for
> people to miss the deadline for timezone reasons.
>
> --
> Thomas Wouters 
>
> Hi! I'm an email virus! Think twice before sending your email to help me
> spread!
>
___
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] Reminder of BDFL succession timeline + CFP

[Mariatta Wijaya]

Since this is like a CFP I figured we should clarify what's expected the
proposal, and I also wanted to be more detailed in the timeline.

*Oct 1 00:00:00 UTC:* Deadline of coming up with proposals of governance
model.

To be included in the proposal:
- explanation and reasoning of the governance model
- expected roles and responsibilities
- candidate for the role need not be included at this time, since we're
only choosing the governance model. Depending on the governance model
chosen, we might have different people to be nominated. There will be a
separate process for nominating the candidate.
- the term of governance: is it for life? 5 years? 10 years?

Who can submit the proposal?
Python core developers. Individual core devs can submit a proposal, or
co-author the proposal with another core dev.

How to submit the proposal?
Proposal should be in a form of a PEP, and merged into peps repo before Oct
1 00:00:00 UTC. Proposals not merged after Oct 1 00:00:00 UTC will not be
considered.

*Oct 1 - Nov 15: Review period.*
All core developers will review the PEPs, and ask any questions to the PEP
author. This timeline allows for enough time for all core devs to carefully
review each PEPs, and for authors to respond.

There will be two parts of this:

*Review phase 1: Oct 1- Nov 1:* Allow changes and tweaks to the proposed
PEPs.
I figured people will have questions and will need to clarify the PEPs
during this period. But if we want the PEP to be final by Oct 1, that's
fine by me. maybe allow typo fixes still.

*Review phase 2: Nov 1 00:00:00 UTC*: No more changes to the above PEPs.
No more tweaks to these PEPs. PRs to these PEPs should be rejected.
This is the final chance to carefully review all governance PEPs, and
formulate your decisions.

*Nov 15 00:00:00 UTC: Voting for new governance model starts, and will go
for 2 weeks*
Send reminders for folks to vote.

Who can vote:
Only core developers can vote.

*Vote will be anonymous.*
*We will use the system used to elect PSF board members.*


*Dec 1 00:00:00 UTC: Voting ended*.
The most voted proposal will be accepted.
Depending on the chosen governance model, we'll begin nominating candidates
to fill the role(s).

*Dec 10 00:00:00 UTC Deadline for nominating candidates to fill the role*
Maybe just one PEP to list all the nominations, instead of separate PEPs of
each candidates.

Who can nominate: Python core developers
Who can be nominated: Python core developers

*Dec 15 00:00:00 UTC Voting for new successor starts*
(Depends on the governance model chosen on Dec 1)

*Who can vote:*
*Only core developers can vote.*

*Vote will be anonymous.*
*We will use the system used to elect PSF board members.*

*Jan 1 00:00:00 UTC Voting for new successor ends.* Most voted candidate(s)
is chosen.

The PSF's Code of Conduct applies to all interactions with core devs
regarding this process, including interactions in any mailing lists, zulip,
IRC, twitter, GitHub, backchannels.

Questions
1. For the purpose of eligibility (for voting or writing the PEP), who are
considered as "core developers"? Anyone in python-committers? Anyone on
Python Core GitHub team? Anyone with commit bit? What about core developers
of alternate implementation (PyPy, IronPython, etc)

2. Are people ok UTC timezone?

3. Should this be a PEP?

Mariatta
___
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] Mentoring Office Hours - the idea, and a question

[Mariatta Wijaya]

I've started a PR in the devguide adding the office hours of core devs that
I know of.
https://github.com/python/devguide/pull/402

Please add your own office hours in there, or create new PRs.

I think we can leave it to each core devs of how they want to do their
office hour.
For myself, a fixed weekly schedule works for me, but others might have
more flexible schedule.

Mariatta


On Thu, Jun 14, 2018 at 4:58 PM Mariatta Wijaya 
wrote:

> Thanks for starting this, Brian.
>
> As such, it needs a person/persons/list to contact should something arise
>> in this context that needs to be handled. What/who should that be?
>
>  * Suggestion 2: Create some new list with a few key people on it.
>>  * Suggestion 3: List some direct names. Who?
>
>
> I personally prefer knowing names. If it will be a mailing list, I'd like
> to know who are in the mailing list.
>
> Related, I believe there is a new Code of Conduct working group within the
> PSF, but I don't know what is the scope of that working group.
> https://mail.python.org/pipermail/psf-community/2018-April/000488.html
>
> Perhaps to start it could just be some of us who wants to volunteer and do
> it?
>
> I can set aside 1 hr each week Thursday as my office hours, between 7 PM -
> 8 PM Pacific.
>
>
>
> Mariatta
>
> On Wed, May 16, 2018 at 3:08 PM, Victor Stinner 
> wrote:
>
>> 2018-05-16 11:31 GMT-04:00 Victor Stinner :
>> > I'm usually available between 10:00 and 16:00 in the French timezone
>> > (currently, it's CEST = UTC+2).
>>
>> Oh, let me be more specific:
>>
>> 10:00-12:00 and 14:00-16:00, Monday to Friday
>>
>> Yeah, in France we take our time to eat ;-)
>>
>> 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] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Mariatta Wijaya]

On Thu, Jul 19, 2018 at 8:59 AM Brett Cannon  wrote:

>
> I had Carol's same worry that while it's great to have a "no sooner than"
> date, we also can't let this drag on and we have no "settle by" date, else
> we risk losing the faith of the community in our ability to come together
> and make decisions (e.g. if I heard it took a year for a project to resolve
> this then I would think there was some major divisiveness on the team).
>
> So could we go with Nathaniel's idea of no decision before October, but
> any proposals to be ready by then as well as Ethan suggested?
>
> I would also propose we have a goal of at least choosing the governance
> model by the end of the year (and a stretch goal to even have people placed
> into created positions by then as well). I have no problem with sooner, but
> I think it might be good to try to put _some_ upper bound on this.
>
> -Brett
>
>
Sounds good.
So what about the following timelines:
Oct 1: Deadline for people to come up with proposals of governance model,
candidates, and how to vote
Dec 1: Deadline to choose a governance model, (and if possible, we choose
the new leader(s) too)
Jan 1: Deadline to choose the new leader(s), if not already chosen by Dec 1.

?
___
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] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Mariatta Wijaya]

+1


On Wed, Jul 18, 2018, 8:54 PM Ethan Furman  wrote:

> On 07/18/2018 08:45 PM, Łukasz Langa wrote:>
>  >> On Jul 18, 2018, at 9:36 PM, Nathaniel Smith  wrote:
>  >>
>  >> I propose: no governance decisions finalized before October
>  >> 1, 2018.
>  >
>  > +1 but it's okay and expected that discussions here will continue in
> the interim.
>
> Absolutely!  Without continuing discussion we'll have nothing to vote on
> come October!  ;-)
>
> --
> ~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/
>
___
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] An alternative governance model

[Mariatta Wijaya]

Next available is PEP lucky number 13 

Mariatta


On Wed, Jul 18, 2018 at 4:14 PM Barry Warsaw  wrote:

> On Jul 18, 2018, at 16:06, Fred Drake  wrote:
>
> > PEP 2 is (currently) the "Procedure for Adding New Modules".  Though
> > superseded, recycling the PEP number seems out of character with the
> > RFC process from which we derived the PEP process.  Let's be cautious
> > about recycling like that; integers are cheap.
>
> Dang, so it is.  :(
>
> I don’t want to recycle numbers, so we’ll likely end up taking the next
> available low ones.
>
> Cheers,
> -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/
>
___
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] An alternative governance model

[Mariatta Wijaya]

Let's be clear that we're not yet at the stage where we can vote for
anything, let alone how to vote.

Barry made one proposal, that's all.

Last week someone suggested doing research of other governance models. We
should still do that before we even start voting on anything.

Mariatta


On Wed, Jul 18, 2018 at 2:04 PM Łukasz Langa  wrote:

>
> > On Jul 18, 2018, at 1:23 PM, Alex Martelli  wrote:
> >
> > Since 1179 (and with a few very minor exceptions in the centuries right
> after then -- none since 1612), the Catholic Church requires a
> super-majority of 2/3 to elect a new Pope. I don't see how the choice of a
> BDFL is so much more important to the Python community, than the choice of
> a Pope is to the Catholic Church; thus, requiring 90% rather than "just"
> 2/3 seems unwarranted.
>
> This is a good point. Moreover, I'm sure Monty Python-wise it's only
> fitting for us to base our rules on a papal conclave.
>
> If we do, then it looks like 2/3 it is. However, historically cardinal
> participation rates were really high so I'd like to keep the 90%
> participation rule there.
>
> I do find it a bit problematic that a papal conclave doesn't vote "yes/no"
> but rather just places names for a predefined position using predefined
> rules.
>
> > In fact, a 90% requirement gets dangerously close to a requirement for
> unanimity -- allowing any member of the Sejm to shout "Nie pozwalam!" and
> thus end the session and nullify every decision made in the session.
>
> Oh, you know how to hit close to home! However, there's a big difference
> between one vote vetoing the ruling and ten (as there's 100+ GitHub
> committers now IIRC).
>
> But yeah, if the Vatican is fine with two thirds, it sounds like we could,
> too. By the way, if we're already studying Polish parliamentary rules, 2/3
> agreement is needed to make constitution changes.
>
> - Ł
> ___
> 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] Language moratorium

[Mariatta Wijaya]

>
> There is a de facto moratorium for the time being until a new governance
> model is chosen. Let's not formalize anything beyond that.


I agree.

Mariatta


On Wed, Jul 18, 2018 at 9:24 AM Łukasz Langa  wrote:

> There is a de facto moratorium for the time being until a new governance
> model is chosen. Let's not formalize anything beyond that.
>
> --
> Best regards,
> Łukasz Langa
>
> > On Jul 18, 2018, at 11:11 AM, Stefan Krah  wrote:
> >
> >
> > Hi,
> >
> > if I remember correctly, we had a moratorium for language changes around
> > versions 3.2-3.3.  I think during that time relatively few BDFL-level
> > decisions were required.
> >
> > Perhaps we could have one again, say for 12 months so we can figure
> things
> > out. Other Python implementations may welcome the moratorium so they can
> > catch up.
> >
> >
> > During that time we could just informally listen very closely to Guido if
> > anything requires a decision and he happens to be around. But there may
> be
> > no decisions at all.
> >
> > And yes, I guess we can successfully attempt to be nice, especially to
> him
> > (thanks for this wonderful language!).
> >
> >
> >
> > Stefan Krah
> >
> >
> >
> > ___
> > 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/
>
___
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] Transfer of power

[Mariatta Wijaya]

Guido,

Thank you for all you've done for Python. It is well deserved break.

I'm sad, but I like to see this as an opportunity to further improve Python
and this community.

My first instinct is to suggest: instead of one successor, we will have
several people as the new "leaders", perhaps a co-BDFL, or even 3-5 people
as co-BDFLs/leaders.
This is based on my experience with organizing meetup and conference
(although these are not comparable to leading the community like Python).
The benefit is to lessen the burden and responsibilities of one person, and
they will have backups when they need to go on a break, vacation, take care
of personal life.

Another thing that came to my mind is, who is actually able (have the time
and energy) to take on this role? Most of us in open source are
volunteering on limited free time available. I'm aware some of you have
employer support, but most don't. Will this limit the candidacy to certain
people just because they have the employer support?

What is the role of the successor(s)? Do we assume "whatever Guido did", or
is this an opportunity to come up with a new process?

One useful resource is Vicky Brasseur's talk: Passing the Baton, Succession
planning for your project https://www.youtube.com/watch?v=Jhkm2PA_Gf8
The slides:
https://ia800809.us.archive.org/2/items/pyconau2017-successionplanning/03-pyconau2017-successionplanning-with_notes.pdf

Some ideas from that talk:
1. identify critical roles (e.g. PEP decision making)
2. refactor large roles
3. mentor the new successor, shadow the previous leader
4. document all the things

This might be selfish request, but I hope you can still assume power until
we have new successor(s).

Thanks.

Mariatta


On Thu, Jul 12, 2018 at 7:58 AM Guido van Rossum  wrote:

> Now that PEP 572 is done, I don't ever want to have to fight so hard for a
> PEP and find that so many people despise my decisions.
>
> I would like to remove myself entirely from the decision process. I'll
> still be there for a while as an ordinary core dev, and I'll still be
> available to mentor people -- possibly more available. But I'm basically
> giving myself a permanent vacation from being BDFL, and you all will be on
> your own.
>
> After all that's eventually going to happen regardless -- there's still
> that bus lurking around the corner, and I'm not getting younger... (I'll
> spare you the list of medical issues.)
>
> I am not going to appoint a successor.
>
> So what are you all going to do? Create a democracy? Anarchy? A
> dictatorship? A federation?
>
> I'm not worried about the day to day decisions in the issue tracker or on
> GitHub. Very rarely I get asked for an opinion, and usually it's not
> actually important. So this can just be dealt with as it has always been.
>
> The decisions that most matter are probably
> - How are PEPs decided
> - How are new core devs inducted
>
> We may be able to write up processes for these things as PEPs (maybe those
> PEPs will form a kind of constitution). But here's the catch. I'm going to
> try and let you all (the current committers) figure it out for yourselves.
>
> Note that there's still the CoC -- if you don't like that document your
> only option might be to leave this group voluntarily. Perhaps there are
> issues to decide like when should someone be kicked out (this could be
> banning people from python-dev or python-ideas too, since those are also
> covered by the CoC).
>
> Finally. A reminder that the archives of this list are public (
> https://mail.python.org/pipermail/python-committers/) although membership
> is closed (limited to core devs).
>
> I'll still be here, but I'm trying to let you all figure something out for
> yourselves. I'm tired, and need a very long break.
>
> --
> --Guido van Rossum (python.org/~guido)
> ___
> 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] A different way to focus discussions

[Mariatta Wijaya]

For permalink in zulip, the link from "Copy link to conversation" seems to
be sufficient.
I've created a stream (
https://python.zulipchat.com/#narrow/stream/130206-.23pep581/subject/hello/near/129486993)
but it now has double ##  and it seems I can't rename it to remove the
extra "#"

I've been waiting for the "excitement" surrounding PEP 572 to cool down
before I want to merge PEP 581 (https://github.com/python/peps/pull/681/)

I was hoping to bypass python-ideas since we've discussed at Python
Language Summit :)  but if really needed I can start a thread there.

Mariatta


On Wed, Jul 11, 2018 at 10:38 AM Guido van Rossum  wrote:

> I like the Zulip idea, though it'll be hard to get permalinks to past
> discussions.
>
> Also, before going to python-dev it should probably be battle-tested in
> python-ideas (PEP 572 wasn't ready for python-dev when it was moved there,
> and I'm still recovering from the resulting brawl).
>
> On Wed, Jul 11, 2018 at 10:31 AM, Ethan Furman  wrote:
>
>> On 07/11/2018 09:25 AM, Mariatta Wijaya wrote:
>>
>> Sorry to bring up this old topic.
>>>
>>> I'm trying to decide how to handle discussions for PEP 581, and I'm open
>>> to try out new things :)
>>> Are we all still content with posting to python-dev?
>>> I was thinking in addition to a thread in python-dev, I want to allow
>>> discussions to take place in zulip, under a new
>>> #pep581 stream.
>>> Will that be ok?
>>>
>>
>> I think this will be a good test of Zulip, as well as incentive for folks
>> to join.
>>
>> --
>> ~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/
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> ___
> 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] A different way to focus discussions

[Mariatta Wijaya]

Sorry to bring up this old topic.

I'm trying to decide how to handle discussions for PEP 581, and I'm open to
try out new things :)
Are we all still content with posting to python-dev?
I was thinking in addition to a thread in python-dev, I want to allow
discussions to take place in zulip, under a new #pep581 stream.
Will that be ok?


Mariatta


On Thu, Jun 28, 2018 at 4:34 AM Antoine Pitrou  wrote:

>
> Le 28/06/2018 à 13:04, Victor Stinner a écrit :
> > It seems like the PEP 572 discussions restarted on python-dev mailing
> > list with more than 100 emails in one week.
> >
> > Stupid idea: we created a mailing list just to fix os.random(): PEP
> > 522 and PEP 524, whereas these discussions were not the ones with the
> > most emails. Why not creating a new pep572 mailing list for the ones
> > who don't want to follow PEP 572 discussions?
>
> PEP 572 is a language-wide change.  Presumably those who don't want to
> follow discussions will still want to give their opinion (or informal
> vote) at the end.  Which will give rise to other discussions...
>
> What strikes me is that we have such long-lasting and intense discussion
> about a feature which, whether approved or not, will not significantly
> change Python's popularity or appeal or ability to solve real-world
> problems.
>
> Perhaps this is a case where « Nature abhors a vacuum » : we're getting
> focussed on whatever comes up to fill the narrative of Python's evolution.
>
> Regards
>
> Antoine.
> ___
> 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] Comments on moving issues to GitHub

[Mariatta Wijaya]

>
> "Old and languishing issues should just be closed / ignored"
> I disagree with doing this blindly, and I would be mightily annoyed if
> someone did so with IDLE issues and hide valuable ideas and code.


Since you are IDLE's maintainer, I'll also be annoyed if other people
except yourself (or other IDLE maintainers) blindly close IDLE issues
without consulting you.

Many modules don't have maintainers anymore. If such issues have been
ignored for all these years, we'll probably never get to it. Might as well
close it.

The proposed idea is to provide a button that can copy over conversations
from a b.p.o issue to GitHub, and to continue discussions in GitHub. If
core devs have a list of issues they still care about, then they use this
not yet existing magic button.

The closed issue will still be in bpo, and anyone motivated enough can
migrate it to GitHub.

To deal with issues better, we need
> 1. More core developers, so more modules can have maintainers.


We need more core developers anyway, regardless of what tracker we're
using. That is a separate problem.

And perhaps this is to be discussed in a separate thread: even though in
the b.p.o we appear to have 170 committers, really there are 90 core devs
(people who has commit right to CPython on GitHub). and out of those 90, I
think only about half are currently active (since the migration to GitHub).
So yes, we need more (active) core devs.

2. Better support for core developers in the tracker.


Not sure what you mean by "support"? There are only two maintainers of the
bug tracker, they both are also Python core developers: Brett and Ezio. My
personal opinion is: they're more valuable elsewhere instead of supporting
the bug tracker. At its current state, the bug tracker is not ready to take
up new contributors, and it will not be easy effort to onboard new bpo
maintainers.

2b. Associated (linked) manager or dashboard for issues pertaining to a
> module or group of modules.


We can try the project boards as Ivan mentioned? https://help.github.com/
articles/about-project-boards/

* Labels can be grouped using name prefix and color, for example (we have
> similar structure in mypy):
>   - priority-low
>   - priority-normal
>   - priority-etc...
>   - kind-bug
>   - kind-docs
>   - kind-feature
>   - topic-asincio
>   - topic-etc..


I kinda like those!

I wonder if other hosted services, such as Gitlab, offer a more
> sophisticated issue tracker.


One thing I'm trying to avoid is having separate issue tracker and repo,
and needing different accounts.

Possibly useful for planning, if we had someone who was responsible for that
>


Perhaps for a project the size of Python we should have a dedicated Project
manager.


Mariatta
ᐧ
___
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] Comments on moving issues to GitHub

[Mariatta Wijaya]

Yup, the "mystery" was just for fun 
There is no secret. I've been thinking that we should start using GitHub
issues instead of the b.p.o.

I realized not everyone was able to get to the language summit, and I fully
intended to update python-committers with this idea.
I just haven't been reading the mailing list for sometime until today.

For those who missed it, some resources:

1. My language summit slides (
https://speakerdeck.com/mariatta/mariattas-python-language-summit-2018-presentation
)
There are 3 bonus slides at the end which I did not get to cover, because
we were running late and it was lunchtime. (in the end, we were 3 hrs
overtime.)
Those can be discussed in core-workflow.

2. LWN article: https://lwn.net/Articles/754779/
I will not be reading/responding to the comments in LWN. 蘿

3. My initial research into this topic:
https://docs.google.com/document/d/1b3H-OQaZ7oc5jI9l7CEx9b_zCpao6PfEV1tIg0vpgG8/edit?usp=sharing


Mariatta

ᐧ
___
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] Proposing Mark Shannon to be a core developer

[Mariatta Wijaya]

Part of the new core dev initiation should be watching this talk, titled
"What is a Python Core Developer?" https://youtu.be/hhj7eb6TrtI

On Tue, May 15, 2018, 11:35 AM Guido van Rossum  wrote:

> Let's stop the email barrage, Mark is in. Can someone tell Mark what to do?
>
>
___
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] Orphaned backports

[Mariatta Wijaya]

To help with this, miss-islington will now assign the PR where backport had
failed to the core dev who merged the original PR.


Mariatta

On Tue, Apr 24, 2018 at 8:57 AM, Brett Cannon  wrote:

>
>
> On Tue, 24 Apr 2018 at 02:59 Serhiy Storchaka  wrote:
>
>> 23.04.18 19:47, Brett Cannon пише:
>>
>> On Sun, 22 Apr 2018 at 11:27 Terry Reedy  wrote:
>>
>>> Does github allow repository owners to send email directly to people who
>>> have submitted PRs or at least, people with commit privileges (in this
>>> case, those whose have done particular merges)?
>>>
>>
>> No. People have to provide explicit permission to expose their email
>> address. Otherwise the best we have are @ mentions in a comment.
>>
>>
>> Aren't all active committer subscribed to this mailing list?
>>
>
> They should be. Doesn't mean they pay attention to it. ;)
>
> -Brett
>
>
> ___
> 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] Wanting to merge my first PR under github - a bit of advice

[Mariatta Wijaya]

Some steps were written here:
https://devguide.python.org/gitbootcamp/#accepting-and-merging-a-pull-request

And the section right after explains the backport.

I guess it needs reorganizing.

Top posted from my phone while literally on a beach.

On Wed, Mar 21, 2018, 7:57 AM Paul Moore  wrote:

> On 21 March 2018 at 12:42, Nick Coghlan  wrote:
> > On 21 March 2018 at 06:58, Paul Moore  wrote:
> >>
> >> Hi,
> >> Cheryl Sabella kindly migrated a patch I'd put on bpo some time ago
> >> but forgotten about onto github. The PR (#6158) is ready to go (I
> >> think) but this is the first time since the migration to github that
> >> I've done a merge, and I'm not quite sure what the workflow is :-( I
> >> didn't see much in the devguide (which covers how to write a PR, how
> >> to test it etc, but not so much how to merge it, unless I missed
> >> something, or it's so simple that the little I did find is all that's
> >> needed!)
> >
> >
> > You didn't miss it - https://devguide.python.org/committing/ is still
> pretty
> > much written for the old approach of merging on the command line.
> >
> > So a devguide issue would definltely be appropriate, and if you're so
> > inclined, even a PR with the docs that you wish had existing when you
> looked
> > for them :)
>
> I'll certainly try to find some time to put something together. For
> now, I've raised https://github.com/python/devguide/issues/347 to
> track it.
>
> Paul
> ___
> 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] Save the date: Core developer sprints

[Mariatta Wijaya]

Thanks for organizing!

I should be able to attend for the whole week this time :) Looking forward
to it.

Mariatta Wijaya

ᐧ
___
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] Issues with hundreds of commits being opened and closed -- what's going on?

[Mariatta Wijaya]

I've also created https://github.com/python/bedevere/issues/69 so that the
review requests from such PRs can be dismissed automatically.

Not sure if there's anything else we can do.

Will it help when bedevere close the PR, it can leave a comment say that
"This PR is invalid. Ignore it" ?


Mariatta Wijaya

ᐧ
___
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] Auto-merge the backport PR with one core dev approval and all passing CI

[Mariatta Wijaya]

This is now done!

miss-islington has been promoted as committer ;)

If you approve the PR and all CI passed, miss-islington will merge it.
Example: https://github.com/python/cpython/pull/5547#event-1468940344

Enjoy!

Mariatta Wijaya

ᐧ
___
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] cherry picking, miss islington, and generated files

[Mariatta Wijaya]

I compared the output from the auto backport PR, and Barry's PR where he
regenerated the files:

Basically comparing the two results from [1] (miss-islington) and [2]
(Barry)

[1] https://api.github.com/repos/python/cpython/pulls/5503/files
[2] https://api.github.com/repos/python/cpython/pulls/5498/files

All these values are identical: "sha", "filename", "status", "additions",
"deletions", "changes", "patch"

The differences are in "blob_url", "raw_url", and "contents_url" but those
are expected to be different for each PR.

So, maybe we trust the CI a little bit more now when it comes to checking
if regenerated files are needed :)

Mariatta Wijaya
___
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] cherry picking, miss islington, and generated files

[Mariatta Wijaya]

Maybe we should just do a diff if https://github.com/python/
cpython/pull/5498 and https://github.com/python/cpython/pull/5503
<https://github.com/python/cpython/pull/5503/files> are identical..

Mariatta Wijaya
___
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] Auto-merge the backport PR with one core dev approval and all passing CI

[Mariatta Wijaya]

On Mon, Feb 5, 2018 at 9:28 AM, Senthil Kumaran  wrote:

> I like to seek one clarification.
>
> I know git has author as well as committer. I am assuming that even if
> miss-islington backports the PR, the author'ship of the patch is still
> preserved.
>
> Is that correct?
>
>
>
Thanks, Senthil.
Currently, the original PR author on master will be credited as a co-author
on backport PRs.
See this example [1] where it says "2 people authored (miss-islington and
csabella) and ncoghlan committed"
If this idea got implemented, I believe it will say "2 people authored
(miss-islington and csabella) and miss-islington committed"

[1]
https://github.com/python/cpython/commit/fea0a12f6bee4a36b2c9533003e33a12c58d2d91
___
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] Auto-merge the backport PR with one core dev approval and all passing CI

[Mariatta Wijaya]

Hi,

I will have some time in the next couple weeks to work on miss-islington.
I'm thinking to work on this issue:
https://github.com/python/miss-islington/issues/44

The idea is to have miss-islington automatically merge the backport PR,
after all CI passed and after a core dev approved the PR. I think this will
save us a lot of button clicks and time.

Just wanted to check if everyone is pretty much +1 on this, before I start
writing the code.

Some notes and implicationss:

- The expectation is that the commit message has already been cleaned up on
the master branch
- It already knows how to replace the # to GH- in the commit message
- miss-islington will need write access to CPython
- git log it will show miss-islington (bot) as the committer
- If you still want to do the merge yourself, then just don't approve
miss-islington's PR.

What does everyone here think about all that?

Thanks.

Mariatta Wijaya
___
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] cherry picking, miss islington, and generated files

[Mariatta Wijaya]

>
> We already have Travis checking 'make regen-all' and 'make clinic'
> (assuming it's working correctly).


The CI in https://github.com/python/cpython/pull/5498 were all passing, but
I think we expected it to fail? In the end Barry regenerated the files
manually.

Mariatta Wijaya
___
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] cherry picking, miss islington, and generated files

[Mariatta Wijaya]

Thanks :)

I found the related thread in core mentorship mailing list:
https://mail.python.org/mm3/archives/list/core-mentors...@python.org/thread/CNK7EWWZTDIRID7MTWLTWXU4H7IH3UIE/

Guido and Victor answered, I guess I got distracted with other things and
forgot to do any sort of follow up :P

If I understand it right, they both suggested running "make regen-all" at
each backport.
But you seem to indicate that you rather do that manually?

For the first pass, I think it can detect that when a changeset includes
importlib.h, we'll make miss-islington leave a comment about needing to
regenerate files.
___
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] cherry picking, miss islington, and generated files

[Mariatta Wijaya]

Sure, I sort of asked this in the past: what are the generated files, how
to identify them, is there a pattern?

I need to dig up that thread and find out if anyone answered. It's been a
while :)

Usually there would be conflict in backport though. It was suggested that
cherry-picker can regenerate the files and resolve the conflict.
Your suggestion of having miss Islington comment on the PR sounds good too.



On Feb 2, 2018 8:17 PM, "Barry Warsaw"  wrote:

I’m in the process of back porting a change which touches importlib and
requires regeneration of Python/importlib.h and Python/importlib_external.h.

The original fix on master:
https://github.com/python/cpython/pull/5481

Miss Islington’s back port to 3.7:
https://github.com/python/cpython/pull/5498

Miss Islington was not able to auto-pick this into 3.6, which makes sense.

I got a little concerned though that the back port touches those two
generated files, and didn’t feel comfortable just pushing the Big Green
Button.  I chatted with Brett and he also agreed that the merge should
probably be done manually.  So for the 3.7 merge, I actually followed the
GitHub CLI merge instructions, regenerated the .h files, pushed the branch,
and opened a new PR:

https://github.com/python/cpython/pull/5503/files

Once CI passed, I hit the BGB and the merge occurred as normal.

For the 3.6 fix, I used cherry_pick, resolved the conflicts manually,
regen’d the header files, pushed the branch, and submitted a new PR:

https://github.com/python/cpython/pull/5504

This one’s still running CI, but if it passes, I’ll merge it.

I wanted to mention this because maybe Miss Islington should flag, warn, or
otherwise indicate when autogenerated files are being merged?  Are there
any other files other than the importlib .h files that we should take extra
care with?

Cheers,
-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/
___
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] [IMPORTANT] post 3.7.0b1 development now open

[Mariatta Wijaya]

>
> Should a patch for 3.6 be cherry-picked directly from master or from 3.7?
> Does it matter?  With hg, double forward merges had to be done linearly, as
> from 3.6 to 3.7 and thence from 3.7 to 3.8 (master).


cherry_picker.py and miss-islington will backport from master to newest
branch first.
So master -> 3.7, then master -> 3.6, and master -> 2.7.
It does not backport from 3.7 -> 3.6.

When doing it manually yourself, you should be able to backport from master
-> 3.6 first and then master -> 3.7, it doesn't matter.


Mariatta Wijaya
___
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] I created the "needs backport to 3.7" labelon GitHub

[Mariatta Wijaya]

If it's protected then backport PR can still happen, but then only Ned can
merge it, right?

On Jan 31, 2018 6:59 PM, "Steve Dower" <steve.do...@python.org> wrote:

> I’d suggest not porting anything to that branch until Ned gives the okay.
> Hopefully it’s locked right now anyway.
>
>
>
> Top-posted from my Windows phone
>
>
>
> *From: *Alex Gaynor <alex.gay...@gmail.com>
> *Sent: *Thursday, February 1, 2018 10:44
> *To: *Mariatta Wijaya <mariatta.wij...@gmail.com>
> *Cc: *core-workflow <core-workf...@python.org>; python-committers
> <python-committers@python.org>
> *Subject: *Re: [python-committers] I created the "needs backport to 3.7"
> labelon GitHub
>
>
>
> Is there documentation somewhere on "how to create a release branch" that
> we should add "creating a label" step to?
>
>
>
> Alex
>
>
>
> On Wed, Jan 31, 2018 at 6:40 PM, Mariatta Wijaya <
> mariatta.wij...@gmail.com> wrote:
>
> I noticed that there is a 3.7 branch now.
>
> So you can use this label if you want miss-islington to backport a PR to
> 3.7.
>
>
>
>
> ___
> 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/
>
>
>
>
>
> --
>
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
>
> GPG Key fingerprint: D1B3 ADC0 E023 8CA6
>
>
>
>
>
___
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] I created the "needs backport to 3.7" label on GitHub

[Mariatta Wijaya]

I'm not sure. Maybe the release managers know? There is PEP 101..

On Jan 31, 2018 6:43 PM, "Alex Gaynor" <alex.gay...@gmail.com> wrote:

> Is there documentation somewhere on "how to create a release branch" that
> we should add "creating a label" step to?
>
> Alex
>
> On Wed, Jan 31, 2018 at 6:40 PM, Mariatta Wijaya <
> mariatta.wij...@gmail.com> wrote:
>
>> I noticed that there is a 3.7 branch now.
>> So you can use this label if you want miss-islington to backport a PR to
>> 3.7.
>>
>>
>> ___
>> 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/
>>
>>
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: D1B3 ADC0 E023 8CA6
>
>
___
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] I created the "needs backport to 3.7" label on GitHub

[Mariatta Wijaya]

I noticed that there is a 3.7 branch now.
So you can use this label if you want miss-islington to backport a PR to
3.7.
___
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] [core-workflow] Adding "Co-authored-by" in commit message.

[Mariatta Wijaya]

No prob :)

I've also updated cherry_picker and miss-islington, so now `Co-authored-by`
is added automatically in backport PRs.

Mariatta Wijaya

On Mon, Jan 29, 2018 at 5:37 PM, Eric Snow <ericsnowcurren...@gmail.com>
wrote:

> On Mon, Jan 29, 2018 at 4:32 PM, Mariatta Wijaya
> <mariatta.wij...@gmail.com> wrote:
> > I suggest we start adding this where it makes sense, to give proper
> credit
> > to PR authors.
>
> +1
>
> Thanks for noticing this.  I've bumped into this several times and
> look forward to (more clearly) giving credit where credit is due.
>
> -eric
>
___
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] Adding "Co-authored-by" in commit message.

[Mariatta Wijaya]

I learned today that GitHub now supports multiple author info in a commit.

https://help.github.com/articles/creating-a-commit-with-multiple-authors/
and
https://github.com/blog/2496-commit-together-with-co-authors


It can be done by adding:

Co-authored-by: name 

as the footer of the commit message.

I tested this in CPython:
https://github.com/python/cpython/commit/6ea75b174da0cf824e2acc5db6b53798f5f4e4f9

I suggest we start adding this where it makes sense, to give proper credit
to PR authors. What I've seen is that we've only been writing "Original
Patch by ".

One scenario is when we convert someone else's mercurial patch to GitHub
pull request. Or when someone started a patch, and another person finished
it.

The other scenario is with miss-islington's backport PRs. I will try to
find time this week so that miss-islington or cherry_picker will add the
"Co-authored-by:" automatically.


Mariatta Wijaya
___
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] trivial tag on GitHub?

[Mariatta Wijaya]

> So when the original PR didn't have a news entry, what should I have seen
> to alert me to that?


If a news entry is missing from the PR, the CI check at the bottom of the
PR will fail.
You should see the following:

bedevere/news -- No news entry in Misc/NEWS.d/next/ or "skip news" label
found

An example can be seen here (at least at the time I write this email)
https://github.com/python/cpython/pull/5347
___
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] AppVeyor is now required to pass on PRs

[Mariatta Wijaya]

>
> Is it possible to write a bot which merges a PR?


Yes it is possible, and we sort of discussing the same thing in python-dev
[1] :)

Each time I approve a backport PR created by miss-ilington with "LGTM,
> good bot", I hope secretly that the PR will be merged automatically
> once CI tests pass ;-)


You should have filed a feature request! :D
To make it happen, I'll need miss-islington be promoted and given write
access to CPython.
Currently miss-islington can't merge.

[1] https://mail.python.org/pipermail/python-dev/2018-January/151899.html

Mariatta Wijaya
___
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] AppVeyor is now required to pass on PRs

[Mariatta Wijaya]

I'm fine with the delay. I've been thinking to implement the bot that will
remind us when all the CI has been completed.
So we don't have to wait, and won't forget about it.

Currently miss-islington does this only for the backport PRs made by
miss-islington.
I think it'll be useful to do that on other PRs too.
(yes I'm aware GitLab does this but we are on GitHub)

Mariatta Wijaya
___
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] Mentoring Julien Palard (core), Cheryl Sabella (bug) and Sanyam Khurana (bug)

[Mariatta Wijaya]

I think questions about triaging can be asked in the regular
core-mentorship as those are useful for all contributors and core devs.

On Dec 9, 2017 10:23 AM, "Carol Willing"  wrote:

>
>
> On Dec 9, 2017, at 11:58 AM, Brett Cannon  wrote:
>
> I have a subscription request to python-committers from Cheryl. Im planing
> rejecting it since we have kept this list only to committees, but I didn't
> want it to come off as rude when it happens.
>
> I also don't know if we want a triage-only list.
>
>
> Perhaps it would be a good idea to have a "core mentorship - triage" list
> which core devs interested in mentoring and triage can help answer
> questions from Cheryl and Sanyam and others down the road. Nice things
> about a list like this is it could be low traffic and supportive while
> helping to build maintainer skills over time. I would be happy to moderate
> and encourage folks on a list like that.
>
>
> On Sat, Dec 9, 2017, 05:13 Victor Stinner, 
> wrote:
>
>> Hi,
>>
>> For your information, I just sent emails to Julien, Cheryl and Sanyam
>> to notify them that I will their mentor during one month.
>>
>> I asked them to ask me to double check before merging a pull request
>> (Julien) or closing a bug (Cheryl and Sanyam).
>>
>> Since I'm trying for formalize the whole process to become a core dev,
>> I kept a copy of my emails to serve as template for future mentors:
>>
>> https://github.com/vstinner/misc/blob/master/cpython/
>> mentor_core_dev_email.rst
>> https://github.com/vstinner/misc/blob/master/cpython/
>> mentor_bug_triage_email.rst
>>
>> By the way, I'm now working on the "Process to become a core
>> developer" document (maybe becoming a PEP later?) at:
>> https://github.com/vstinner/misc/blob/master/cpython/pep-
>> core_dev_process.rst
>> (I almost didn't change since I sent it to python-committers)
>>
>> 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/
>
>
>
> ___
> 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] Sanyam Khurana has been promoted to get bug triage permission

[Mariatta Wijaya]

Congrats Sanyam!
Thanks for your continued contributions :)

Mariatta Wijaya

On Wed, Dec 6, 2017 at 3:25 PM, Senthil Kumaran <sent...@uthcode.com> wrote:

> Congratulations, and Welcome Sanyam!.
>
> Thank you, and keep up with your good work.
>
>
>
> On Wed, Dec 6, 2017 at 1:43 PM, Victor Stinner <victor.stin...@gmail.com>
> wrote:
>
>> Hi,
>>
>> To recognize the good contributions of Sanyam Khurana, I gave him the
>> bug triage permission on bugs.python.org. (In practice, Ezio gave him
>> the permission.)
>>
>> He already commited 9 changes into the master branch since April, 2017.
>>
>> Congrats Sanyam!
>>
>> 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/
>
>
___
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 Palard as core developer

[Mariatta Wijaya]

Agree. +1!

Mariatta Wijaya

On Thu, Dec 7, 2017 at 8:29 AM, Ethan Furman <et...@stoneleaf.us> wrote:

> On 12/06/2017 04:48 PM, Victor Stinner wrote:
>
> I propose to promote Julien Palard as a core developer.
>>
>
> I know that Julien doesn't have the typical profile of core
>> developers, only or mostly contribute to the code: Julien is currently
>> focused on the doculmentation.
>>
>
> Good documentation is hard.  +1 to bring Julien Palard in!
>
> --
> ~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/
>
___
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] Cheryl Sabella was promoted to get bug triage permission

[Mariatta Wijaya]

Not dumb question.

But I don't think Cheryl is on this list.

not yet ;)

On Dec 6, 2017 10:25 AM, "Ethan Furman"  wrote:

> On 12/06/2017 09:43 AM, Victor Stinner wrote:
>
> Congrats Cheryl!
>>
>
> Possibly a dumb question, but is Cheryl on this list?
>
> --
>
>
___
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] Cheryl Sabella was promoted to get bug triage permission

[Mariatta Wijaya]

Congrats Cheryl!!

Thanks for your continued contributions!


On Dec 6, 2017 9:43 AM, "Victor Stinner"  wrote:

Hi,

To recognize the good contributions of Cheryl Sabella, I gave her the
bug triage permission on bugs.python.org. (In practice, Ezio gave her
the permission.)

In the past, such "promotion" wasn't always advertized on
python-committers, but my intent is to make our process more
transparent and award people who deserve it!

IMHO bug triage is the first step/milestone to become a core developer
in the long term.

FYI She pushed not less than 14 commits into the master branch since
August, 2017.

Congrats Cheryl!

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] Adding Ivan Levkivskyi as a core committer

[Mariatta Wijaya]

Please add Ivan to the Developer Log in Dev Guide, and he should subscribe
to python-committers mailing list :)



On Dec 6, 2017 8:44 AM, "Guido van Rossum"  wrote:

I think I figured it out -- I invited him to the python org on GitHub.
Anything else?
___
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] Requesting reviews

[Mariatta Wijaya]

The windows team is notified because the PR includes changes to PCBuild/*

Mariatta Wijaya

On Fri, Oct 6, 2017 at 8:51 AM, Paul Moore <p.f.mo...@gmail.com> wrote:

> Hmm, as an example, #2858, which seems to be about the AST (which I'm
> not familiar with). I don't particularly want to single this out as a
> problem, but it's an example of the sort of request that confuses me -
> I simply don't know what help I can offer. Maybe there is some
> suspicion that there might be a Windows element - but without some
> guidance, I'm not sure where to look.
>
> Paul
>
> On 6 October 2017 at 16:38, Zachary Ware <zachary.ware+py...@gmail.com>
> wrote:
> > On Fri, Oct 6, 2017 at 7:16 AM, Paul Moore <p.f.mo...@gmail.com> wrote:
> >> I'm seeing a lot of review requests from github, asking for reviews
> >> from the Windows team. Many of the PRs don't as far as I can see have
> >> much Windows-specific about them. It doesn't bother me too much (I
> >> just ignore ones I don't have anything to say on) but I thought the
> >> idea of having the teams was to ask for specific experts to take a
> >> look when needed?
> >>
> >> As I say, it's not a big deal for me, but I'm curious how others think
> >> the review teams should be used.
> >
> > Do you have some examples of superfluous requests?  I don't think I've
> > seen any, other than a rash of bad drive-by PRs that merge a
> > maintenance branch into master, which GitHub should be working on
> > preventing.  See https://github.com/python/core-workflow/issues/168
> > for more on that.
> >
> > --
> > Zach
> > ___
> > 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/
>
___
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] Hacktoberfest

[Mariatta Wijaya]

One hacktoberfest issue closed!
https://github.com/python/core-workflow/issues/164

Thanks to Berker who reviewed and merged their PR quickly :)


Mariatta Wijaya

On Thu, Sep 28, 2017 at 2:39 PM, Victor Stinner <victor.stin...@gmail.com>
wrote:

> Hi,
>
> 2017-09-28 18:21 GMT+02:00 Mariatta Wijaya <mariatta.wij...@gmail.com>:
> > October is hacktoberfest (https://hacktoberfest.digitalocean.com/)
> > In the month of October, people can sign up and contribute to open source
> > projects on GitHub. If they make 4 PRs during Hacktoberfest, they'll
> earn a
> > limited edition T-Shirt.
>
> We never tried it. Maybe it will be a mess, maybe it will be a
> success. In the worst case, it will be ignored. As least if it's a
> mess, we would have try and we will learn something.
>
> I'm open to try new things, we always look for new contributors :-)
>
> 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] Hacktoberfest

[Mariatta Wijaya]

>
> Fun fact: The real Oktoberfest in München always starts mid of September
> and ends on the first weekend of October. This year it will end on
> October 3rd. Hurry up! :)



Hmm.. Maybe the next core sprint can coincide with the real oktoberfest? ;)


This may sound grumpy to some, but I'm against gamification of open source
> and also against giving GitHub a special role.


I'm also against gamification, which I have expressed personally to another
core dev.
I do believe that the ability to contribute to open source is a privilege.

Any open source activity is somehow credited to or associated with some
> commercial entity.  What has changed in the last 7-10 years?


I don't know, I haven't been involved with open source for that long.

I have a rather selfish motivation. I'd really like to see some of these
open issues in the DevGuide closed:
https://github.com/python/devguide/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22

During the core sprint I mentioned to another core dev that I'd like to see
someone write up the git worktree part (
https://github.com/python/devguide/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22)
since I don't know how it works.
Seems like there are other core devs who knows how it works, but have not
find time/motivation to write up the docs.

If during the month of October there plenty of eager contributors looking
for issues to work on, why not direct them to one of our issues?
I think it benefits all of us.

We are not the one giving out t-shirts anyway. It does mean we will receive
more than usual incoming PRs.
I think this will happen anyway whether I create the hacktoberfest label or
not.

I'm planning to apply the labes to the devguide issues that have the 'help
wanted' labels already (see above link)
and this core workflow issue which is supposed to be straightforward
https://github.com/python/core-workflow/issues/164


Mariatta Wijaya


Mariatta Wijaya

On Thu, Sep 28, 2017 at 10:04 AM, Antoine Pitrou <anto...@python.org> wrote:

>
> Le 28/09/2017 à 18:58, Stefan Krah a écrit :
> > On Thu, Sep 28, 2017 at 09:21:04AM -0700, Mariatta Wijaya wrote:
> >> October is hacktoberfest (https://hacktoberfest.digitalocean.com/)
> >> In the month of October, people can sign up and contribute to open
> source
> >> projects on GitHub. If they make 4 PRs during Hacktoberfest, they'll
> earn a
> >> limited edition T-Shirt.
> >
> > This may sound grumpy to some, but I'm against gamification of open
> source
> > and also against giving GitHub a special role.
>
> I don't like gamification, but the t-shirt thing sounds innocuous
> enough.  I would be more worried if such a scheme became permanent.
> Also I'm not even sure we can prevent this one for CPython PRs:
>
> """To get a shirt, you must make four pull requests between October 1–31
> in any timezone. Pull requests can be to *any public repo on GitHub, not
> just the ones we’ve highlighted*.""" (emphasis added)
>
> Regards
>
> Antoine.
> ___
> 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/

[python-committers] Hacktoberfest

[Mariatta Wijaya]

Hi,

October is hacktoberfest (https://hacktoberfest.digitalocean.com/)
In the month of October, people can sign up and contribute to open source
projects on GitHub. If they make 4 PRs during Hacktoberfest, they'll earn a
limited edition T-Shirt.

If it's ok with everyone, I want to create "hacktoberfest" label and apply
it to some of the open issues in the DevGuide and core-workflow repo. The
purpose of the label is to make the repo discoverable, so it shows up as
one of the participating projects:
https://github.com/search?q=label%3Ahacktoberfest+state%3Aopen+type%3Aissue=Issues

Mariatta Wijaya
___
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] Can I get access to CPython's GitHub Webhook events?

[Mariatta Wijaya]

Hi,

As part of maintaining miss-islington, I think it would be great if I could
see the GitHub webhook events for the CPython repo, just to make it easier
for me to debug problems. Sometimes miss-islington doesn't work as
expected, and the logs I get from heroku aren't too useful..

Not sure who in here can give me such access..
The webhook info is located in
https://github.com/python/cpython/settings/hooks and to me this is a 404
right now.

Thanks :)

Mariatta Wijaya
___
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] Cherry picker bot deployed in CPython repo

[Mariatta Wijaya]

Hi,

The cherry picker bot has just been deployed to CPython repo, codenamed
miss-islington.

miss-islington made the very first backport PR for CPython and became a
first time GitHub contributor: https://github.com/python/cpython/pull/3369

GitHub repo: https://github.com/python/miss-islington

What is this?
==

As part of our workflow, quite often changes made on the master branch need
to be backported to the earlier versions. (for example: from master to 3.6
and 2.7)

Previously the backport has to be done manually by either a core developer
or the original PR author.

With the bot, the backport PR is created automatically after the PR has
been merged. A core developer will need to review the backport PR.

The issue was tracked in https://github.com/python/core-workflow/issues/8

How it works
==

1. If a PR needs to be backported to one of the maintenance branches, a
core developer should apply the "needs backport to X.Y" label. Do this
**before** you merge the PR.

2. Merge the PR

3. miss-islington will leave a comment on the PR, saying it is working on
backporting the PR.

4. If there's no merge conflict, the PR should be created momentarily.

5. Review the backport PR created by miss-islington and merge it when
you're ready.

Merge Conflicts / Problems?
==

In case of merge conflicts, or if a backport PR was not created within 2
minutes, it likely failed and you should do the backport manually.

Manual backport can be done using cherry_picker:
https://pypi.org/project/cherry-picker/

Older merged PRs not yet backported?
==

At the moment, those need to be backported manually.

Don't want PR to be backported by a bot?


My recommendation is to apply the "needs backport to X.Y" **after** the PR
has been merged. The label is still useful to remind ourselves that this PR
still needs backporting.

Who is Miss Islington?
=

I found out from Wikipedia that Miss Islington is the name of the witch in
Monty Python and The Holy Grail.

miss-islington has not signed the CLA!
=

A core dev can ignore the warning and merge the PR anyway.

Thanks!


Mariatta Wijaya
___
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] UPDATE 1: Core sprint 2017 - Sep 4 - Sep 9, Menlo Park, California

[Mariatta Wijaya]

Thanks Łukasz for organizing the sprint, and Victor for setting up etherpad.
I added my own sprint plan there.
I saw that some of you are wanting to chat with me during the sprint.
I'll only be at the sprint Monday-Wednesday, so let's plan accordingly and
make the most out of it :)

Looking forward to sprint with y'all in a few weeks.

Thanks.

Mariatta Wijaya
___
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] GitHub: remove the "needs backport to 3.5" label?

[Mariatta Wijaya]

Just catching up with emails.
+1 to removing the label.


On Aug 11, 2017 12:04 PM, "Brett Cannon"  wrote:

> No one has said anything, so I will delete the label sometime today.
>
> On Wed, 9 Aug 2017 at 12:20 Brett Cannon  wrote:
>
>> On Wed, 9 Aug 2017 at 01:55 Victor Stinner 
>> wrote:
>>
>>> Hi,
>>>
>>> Python 3.5 entered security fix only mode. Should we now remove the
>>> "needs backport to 3.5" label? Other security only branches don't have
>>> this label neither (3.3 and 3.4).
>>>
>>
>> Seems reasonable to me since you will need to get Larry's attention and
>> approval anyway for 3.5 changes now so the label isn't that useful. If
>> there isn't a consensus to not do this I will remove the label probably
>> Friday.
>>
>
> ___
> 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] My (positive) feedback on the new CPython workflow

[Mariatta Wijaya]

> >  2. Bot to backport PRs (which could also be automatically merged)
> So, to me, this is the priority item on the list.


I'm planning to work on the cherry-pick bot this during the core sprint in
September. Unless someone beat me to it.


Automatically close stale PRs (e.g. not signing CLA, changes
> requested but not being made, etc.)


This is also in my sprint plan, but only if I finish the cherry-pick bot :)
Further discussion can be done here:
https://github.com/python/core-workflow/issues/93



What does 'close' (without merging) mean?


The PR will be closed. The branch containing the changeset will still be
available in the contributor's fork of CPython.
Unless they delete it too.

On GitHub You can search for PRs that are closed but not merged by using
the filters:
is:pr is:closed is:unmerged

A list of closed PRs that were not merged
https://github.com/python/cpython/pulls?utf8=%E2%9C%93=is%
3Apr%20is%3Aclosed%20is%3Aunmerged%20

I believe the reopening the PR straight-forward: click on the "Reopen pull
request" button.


Mariatta Wijaya

On Tue, Jul 18, 2017 at 4:01 PM, Brett Cannon <br...@python.org> wrote:

>
>
> On Tue, 18 Jul 2017 at 12:54 Barry Warsaw <ba...@python.org> wrote:
>
>> On Jul 18, 2017, at 15:21, R. David Murray <rdmur...@bitdance.com> wrote:
>> >
>> > I much prefer rietveld over github reviews, but I also much prefer the
>> > integration between the bug tracker and github over the minimal
>> > integration we had for rietveld.  Thanks to all the people who made
>> > that happen, and especially Brett for leading it.
>>
>> Not that I’m suggesting anything should change, but just FWIW, I find
>> Gitlab to have a much better conversational review tool than Github.  I
>> often find myself getting lost in GH reviews (on many projects), but GL
>> just organizes the conversation really well IMHO.
>>
>
> It's very obvious, Barry, that you're playing the long game of trying to
> line up GitLab as the next platform once we grow tired of GitHub and need
> to switch in a few years. I'm on to you. ;)
>
> ___
> 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] link from github to bpo?

[Mariatta Wijaya]

PR 2304 is merged. "View Details" still exists (scroll all the way down).

When the PR is not yet merged (e.g.
https://github.com/python/cpython/pull/2316), the UI looks different.
Click 'Show all checks' to get the link back to bpo.


Mariatta Wijaya

On Wed, Jun 21, 2017 at 1:21 PM, R. David Murray <rdmur...@bitdance.com>
wrote:

> On Wed, 21 Jun 2017 10:02:58 -0700, Mariatta Wijaya <
> mariatta.wij...@gmail.com> wrote:
> > Yes, for that PR, scroll down and click the "View Details" button.
> > Click the Details link next to bedevere/issue number status check.
> > It will take you to the issue in bpo.
>
> Note that this will only exist if the PR is still open (not closed, not
> merged).
>
> > There is also an open issue in bedevere, where the link will be added at
> > the bottom of the PR message.
> > https://github.com/python/bedevere/issues/3 (I believe Brett is working
> on
> > it :)  )
>
> And this should fix the problem mentioned above :)
>
> --David
> ___
> 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] Bedevere now automatically removes "needs backport to *" labels

[Mariatta Wijaya]

I think it's because there was no 'needs backport to 3.4' label from PR
1849, so it doesn't make the comment about 3.4 backport PR.

Mariatta Wijaya

On Tue, Jun 20, 2017 at 7:17 AM, Victor Stinner <victor.stin...@gmail.com>
wrote:

> Does it allow catch for 3.3 and 3.4 branches? I got notifications for
> 3.6, 3.5 and 2.7 backports of
> https://github.com/python/cpython/pull/1849 but not for the 3.3 and
> 3.4 backports:
> https://github.com/python/cpython/pull/2291
> https://github.com/python/cpython/pull/2292
>
> These two backports have the same format: title ending with " #2291"
> and "(cherry picked from commit 90e01e5)" in the description.
>
> Victor
>
> 2017-06-16 22:30 GMT+02:00 Brett Cannon <br...@python.org>:
> > When you create a backport PR, if the title is formatted as, e.g. "[3.6]
> > stuff that changed (GH-1234)", then Bedevere will remove the "needs
> backport
> > to 3.6" label on the GH-1234 PR and leave a comment linking to the
> backport
> > PR that triggered the label removal.
> >
> > ___
> > 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/
>
___
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] Windows License for a core dev

[Mariatta Wijaya]

Hi,

During the language summit I overheard that as a core developer, I can get
free Windows License. Is this true?
If so, how can I get one, and will it work with VirtualBox on mac?

Thanks.

Mariatta Wijaya
___
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] Travis skipping the test build

[Mariatta Wijaya]

I think this PR takes care of it. https://github.com/python/
cpython/pull/1879



On May 30, 2017 4:08 PM, "Brett Cannon"  wrote:

> At the moment Travis is not running the test build (it's actually not even
> listing it as a build). You can look at master, 3.6, or 3.5 to see that
> only the docs and coverage builds are being run: https://travis-ci.org/pyt
> hon/cpython/branches . I don't know why this is as it was fine yesterday
> and then stopped working today. The last change was from Antoine but its
> own Travis run ran fine so I don't think that caused the problem:
> https://github.com/python/cpython/commits/master/.travis.yml . If anyone
> can figure out if this is somehow our fault that would be great (I can't
> see how it is).
>
> But the key thing is to be aware that Travis being green just means the
> docs built fine. So until this is resolved, try to remember to check if the
> coverage test run passes if you want Travis to check your non-doc changes.
>
> ___
> 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] Guide to pushing to submitters' repo?

[Mariatta Wijaya]

The git pr alias in the devguide assumes that you have origin and upstream
remote setup,
where origin is your own CPython fork, and upstream is python/CPython repo


On May 25, 2017 6:27 AM, "Antoine Pitrou"  wrote:


Le 25/05/2017 à 15:06, Nick Coghlan a écrit :
> On 25 May 2017 at 18:01, Antoine Pitrou  wrote:
>> Did someone manage to make this work?  Can they post the entire
>> instructions they used? (including local branch setup)
>
> The minimal set of instructions some of us worked out are at
> https://docs.python.org/devguide/gitbootcamp.html#
editing-a-pull-request-prior-to-merging
> (the initial draft was longer, but patch review found a few
> opportunities for simplification)

Thank you.  Is it possible for the "git pr" alias to also edit the
branch tracking information?  Currently I get:

(master)$ git pr 1785
Depuis https://github.com/python/cpython
 * [nouvelle référence] refs/pull/1785/head -> pr_1785
Basculement sur la branche 'pr_1785'

(pr_1785)$ LANG=C git pull
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.

git pull  

If you wish to set tracking information for this branch you can do so with:

git branch --set-upstream-to=/ pr_1785


Regards

Antoine.
___
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] Proposing Carol Willing to become a core developer

[Mariatta Wijaya]

+1_000_000

On May 23, 2017 11:23 AM, "Brett Cannon"  wrote:

> While at the PyCon US sprints the idea came up of offering Carol Willing
> developer privileges. Everyone at the table -- about 6 of us -- liked the
> idea and Carol also said she would happy to become a core dev, so I'm
> officially putting her forward for consideration.
>
> For those of you who don't know Carol, she basically knows our developer
> workflow better than most of us. :) ; she's very active on the devguide and
> core-mentorship. Carol has also attended the PyCon US language summit two
> years in a row as a representative for the Jupyter project. She is actually
> so good with new people that she managed to get my wife to make her first
> open source contribution (something I never managed to do).
>
> As usual, if you support/object to this idea, please say so. :)
>
> ___
> 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] Feedback on the new CPython workflow

[Mariatta Wijaya]

>
> * Currently, cherry-picker works a single step. It would be nice to
> have at least 2 steps: first cherry-pick locally, then allow to review
> the patch locally and run some specific tests, and then send the PR.


The --no-push parameter allows you to test changes locally first. Then you
can use --continue to finish the backport and open the PR:

Discussion: https://github.com/python/core-workflow/issues/78
Implementation: https://github.com/python/core-workflow/pull/84


By the way, instead of only using the sha1 to build the branch name,
> it would be nice to add also the bpo number.


It's possible, but remember not all PRs have bpo-issue, eg those with
trivial label.
In that case, what should the backport branch be?
So we might end up with two backport branch name patterns, eg
`backport-bpo--` and `backport-sha1` for the trivial PRs ?

Thanks :)

Mariatta Wijaya

On Wed, May 17, 2017 at 11:26 AM, Victor Stinner <victor.stin...@gmail.com>
wrote:

> Hi,
>
> I wanted to wait a little bit before giving back my feedback on the
> new workflow. I just attend Brett Canon's talk at the Language Summit.
> So here are my misc notes on the new workflow.
>
> * Is there anyone already working on the workflow who would like to
> get a grant (money!) from the PSF?
>
> * If I want to share a change to review but it must not be merged,
> would it be possible to prevent merge by mistake? Maybe add [WIP] to
> the title and modify our bot to mark the "build" as failed? For
> example, I wrote a patch which depends on a different patch but I
> didn't want to create a patch serie since it didn't make sense.
>
> * AppVeyor is now quite stable. I fixed a few unstable tests. I
> suggest to mark this CI as mandatory. The CI is as fast or even faster
> than Travis CI! But it seems like it accepts less jobs in parallel :-/
> It might be an issue if we get a huge number of PR in a short period
> (ex: during an event like Pycon US).
>
> * Currently, cherry-picker works a single step. It would be nice to
> have at least 2 steps: first cherry-pick locally, then allow to review
> the patch locally and run some specific tests, and then send the PR.
> By the way, instead of only using the sha1 to build the branch name,
> it would be nice to add also the bpo number.
>
> * I suggest to track backports at bpo since an issue tracks all PR and
> it seems like most core developers want to put most informations in
> the issue rather than GitHub.
>
> * Find a way to keep the Code coverage job, but don't mark the PR as
> failed if the coverage is considered as "failed"? It's strange to see
> a long list of PR with the red sign (failed) whereas Travis and
> AppVeyor passed.
>
> I have a lot of other minor remarks, but I prefer to stop here ;-)
>
> 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] Sphinx 1.6.1 is causing Travis to fail

[Mariatta Wijaya]

It passes now : https://github.com/python/cpython/pull/1612

Ok to merge?

Mariatta Wijaya

On Tue, May 16, 2017 at 10:31 AM, Brett Cannon <br...@python.org> wrote:

> Looks like they added some new warnings that are causing the docs build to
> fail (e.g. https://travis-ci.org/python/cpython/jobs/232903226 and
> https://travis-ci.org/python/cpython/jobs/232897796).
>
> I will see if I have time to fix this before I leave for PyCon US today,
> but there's no guarantee. If someone has time to fix this then I've opened
> https://bugs.python.org/issue30380 to track the problem and give my take
> on a solution.
>
> ___
> 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] Proposal for procedures regarding CoC actions

[Mariatta Wijaya]

Thanks everyone for the input.


It is still unclear to me how one can report when someone is being rude on
GitHub.
In the mailing lists we can email the administrators. But what about on
GitHub?
Do I write to python-committers?
What if it was a core developer who was being rude, where can a non
core-dev contributor report such behavior?



Mariatta Wijaya

On Thu, May 4, 2017 at 6:53 AM, Nick Coghlan <ncogh...@gmail.com> wrote:

> On 4 May 2017 at 06:10, Guido van Rossum <gu...@python.org> wrote:
> > Two ex-board members disagree. I have to side with Brian; the PSF board
> > should have minimal say in how the developers develop.
> >
> > Note, I'm fine with the board being the arbiter when someone disagrees
> with
> > their ban though -- there's got to be a "higher authority" for appeals.
> But
> > I don't agree that the board should be the decider on the initial ban.
>
> I think initial temporary suspensions should definitely be handled
> without involving the Board (just as they are for any other PSF
> provided channel).
>
> I also think there are two cases that can definitely only be handled
> at the board level:
>
> - folks that feel they've been treated unfairly by the core
> development team appealing to the Board for reconsideration
> - the core development team recommending that a ban from our channels
> (python-dev, python-ideas, core-workflow, bugs.python.org, GitHub
> python org) be extended to other PSF provided channels
>
> I'd previously said that I thought conversion of temporary suspensions
> to permanent bans should also go to the Board, but I now think it
> makes more sense to handle that as:
>
> - the Board gets notified if a temporary suspension is now considered
> a permanent ban
> - they only need to get further involved if the ban is appealed
>
> Cheers,
> Nick.
>
> P.S. Don't forget that the specific context here is *public* behaviour
> that is the domain of channel moderators, rather than confidentially
> reported Code of Conduct concerns. Handling of the latter will remain
> with the PSF Board or their appointed representatives, independently
> of how we handle moderation of the development channels.
>
> --
> 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] Proposal for procedures regarding CoC actions

[Mariatta Wijaya]

Hi,

First of all, sorry for bringing up an old thread.
I know this is an uncomfortable topic, and I also wish that we can just
avoid it, but ... I think we gotta do something about it.

I understand why Brett did what he did, and I support his decision.

I do agree with Raymond's point, that going forward, we should have
a procedure in place, we all need to know what the rules are, and how to
play by the rules.

Communities like Django Project and Write The Docs have clear enforcement
manuals on what to do in case of CoC violation:
https://www.djangoproject.com/conduct/enforcement-manual/
http://www.writethedocs.org/code-of-conduct-response/

Can we adopt something like that to our community, or do we have this
already?
If it requires involvement with the PSF board, who could bring this to
their attention? (I'm new I don't know how these things work yet)

Brett's step-by-step guide above based on Raymond's proposal seems like a
good start.
Does that need to be approved by the board first? Or can we start by
creating a PR to the devguide, and continue the discussion there?

I also want to discuss what the different actions to be taken in case
someone is being negative.
In one of the mailing lists, the violator gets a warning for their first
offense.
What if their first offense is severe enough, maybe a warning may not be
suitable?
Do we (core developers) want to decide all of these ourselves, or do we
leave it PSF board to decide?

I just want to make sure that we are taking some actions going forward.



Mariatta Wijaya

On Sun, Apr 2, 2017 at 8:04 PM, Nick Coghlan <ncogh...@gmail.com> wrote:

> On 3 April 2017 at 04:08, Brett Cannon <br...@python.org> wrote:
> > On Sun, 2 Apr 2017 at 04:34 Paul Moore <p.f.mo...@gmail.com> wrote:
> >> As a result, the public perception of a "code of conduct violation" is
> >> that someone has harassed, or otherwise made a community member
> >> uncomfortable, specifically because they don't conform to the
> >> stereotypical norm. That's not necessarily what any specific code of
> >> conduct might say, but it's how the public perceives such things (and
> >> high-profile blog entries that expose exclusive behaviour, and cite
> >> codes of conduct and how they help and where they fail to, simply
> >> reinforce that perception).
> >>
> >> We may not like the fact that a simple term like "Code of Conduct"
> >> gets appropriated in the public perception in such a way, but denying
> >> the reality of it doesn't mean it doesn't happen.
> >
> > But based on how others are stating their views, I'm seem to be in the
> > minority on this one. I'm fine with that as I can view it personally as
> > political wordsmithing. For me the key is that if I'm going to shoulder
> the
> > burden of being a moderator I want to have the ability to keep
> discussions
> > open, respectful, and considerate. If that means that someone gets a
> "CoC"
> > label when they run afoul of those tenants by being mean while they get
> an
> > "persistently unproductive" label when they run afoul of those labels in
> how
> > they communicate then I can live with that.
>
> I essentially agree with Brett here, but I also agree with MAL that at
> least for now we can keep this to a simpler two level system where:
>
> 1. We write down explicit rules for encouraging productive,
> collaborative discussions on PSF provided communication channels,
> together with the process that channel moderators are advised to
> follow when imposing temporary suspensions of posting privileges. We
> then explicitly adopt those rules for the core Python communication
> channels (python-dev, python-ideas, core-mentorship, the issue tracker
> and meta-tracker, the python org on GitHub) by updating the Developer
> Guide appropriately. The trigger for lifting suspensions imposed at
> this level can just be that: a) the minimum time period specified by
> the moderators has passed; b) the person suspended explicitly requests
> that the channel moderators restore their posting privileges.
>
> Whether we call them "Rules for Active Participation" or something
> else, this step gives channel moderators the explicit authority to
> govern their channels according to their defined purpose, without
> having to rely on the Code of Conduct as the sole mechanism for
> ensuring that folks don't persist indefinitely in wasting other
> people's time.
>
> 2. Anything that can't be handled through a temporary suspension of
> posting privileges gets escalated to the elected PSF Board. For
> example:
>
> - cases where folks feel they have been suspended unfairly by moderators
> - cases where moderators believe that a tempor

[python-committers] cherry_picker.py updated

[Mariatta Wijaya]

Hi,

If you've been using cherry_picker.py, please update it ( by doing `git
pull` ).

With this update, the branch number is automatically prefixed in the commit
message. (https://github.com/python/core-workflow/issues/44)

Added --abort/--continue options to address
https://github.com/python/core-workflow/issues/45

Lastly, I added --status option, which will just perform `git status` for
the cpython directory.

Thanks :)

Mariatta Wijaya
___
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] [Core-mentorship] Regarding reviewing test cases written for tabnanny module

[Mariatta Wijaya]

So there is already a PR in the devguide advising contributors to keep
their commit history intact, see https://github.com/python/devguide/pull/162
Assuming people do read the devguide, then let's hope that we won't lose
the commit history going forward.

There is also already a section in the devguide instructing core devs to
clean up commit message, see http://cpython-devguide.re
adthedocs.io/gitbootcamp.html#accepting-and-merging-a-pull-request If this
is not clear enough, please propose a PR or file an issue.


Back to the original issue with reviewing the PR https://github.com/python/
cpython/pull/851

Other than not being able to review the diff, is there any other problem?
Can the PR be reviewed as is?

Martin, you said: "I’m not really set up to properly review and push stuff
with the new Git Hub setup,"
Are you wanting to make edits to the PR yourself?
If so, maybe you can try these instructions: http://cpython-devguide.
readthedocs.io/gitbootcamp.html#editing-a-pull-request-prior-to-merging



Mariatta Wijaya

On Tue, Apr 11, 2017 at 11:30 AM, Terry Reedy <tjre...@udel.edu> wrote:

> On 4/11/2017 1:21 PM, Donald Stufft wrote:
>
>>
>> On Apr 11, 2017, at 12:25 PM, Terry Reedy <tjre...@udel.edu
>>> <mailto:tjre...@udel.edu>> wrote:
>>>
>>
> I was under the impression that the green [commit] button would do the
>>> squashing.   Or at least that it could.
>>>
>>>
>> Yes it can, and IIRC for CPython we have it set so it _only_ does that.
>> Although the commit message may be ugly if you don’t adjust it in the
>> text editor that pops up when GitHub asks you to confirm the merge since
>> it by default just concats all of the commit messages into a list so you
>> might get a commit message like:
>>
>> * implement feature
>>
>> * fix thing
>>
>> * ugh
>>
>> * address review
>>
>> Instead of a nice clean one. That’s going to be up to the person hitting
>> the merge button to edit the commit message to be clean though.
>>
>
> I think committers should always be responsible for the commit message.
> This will usually mean editing submissions from non-committers.  Since
> message is truncated to first line in some displays, the latter should
> summarize main point of commit.
>
>
> ___
> 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] [Core-mentorship] Regarding reviewing test cases written for tabnanny module

[Mariatta Wijaya]

"View Changes" doesn't work when commits in PR were squashed, which seems
to be the case in https://github.com/python/cpython/pull/851

I wonder if there is a way to unsquash the commits? Will it help with
reviewing this PR?

Mariatta Wijaya

On Tue, Apr 11, 2017 at 2:55 AM, Donald Stufft <don...@stufft.io> wrote:

> If someone makes a review on github (as opposed to a simple comment) I
> believe the state of the code as it was when that review as made can be
> viewed by hitting the “View Changes” button next to that review in the
> timeline.
>
> On Apr 10, 2017, at 3:18 PM, Guido van Rossum <gu...@python.org> wrote:
>
> Thanks for the clarification. We should probably move this discussion to
> the python-committers list rather than core-mentorship.
>
> On Mon, Apr 10, 2017 at 12:12 PM, Terry Reedy <tjre...@udel.edu> wrote:
>
>> On 4/10/2017 12:54 PM, Guido van Rossum wrote:
>>
>>> So the response from Martin Panter
>>> (https://github.com/python/cpython/pull/851#issuecomment-292755992)
>>> sounds like he's not set up for the new GitHub workflow. I'm CC'ing
>>> Martin here.
>>>
>>
>> The specific issue Martin raised is "Sorry but I don’t have an easy way
>> to see your fixes relative to the old version I reviewed."  If the original
>> and modified patches were posted in proper format to b.p.o., then one could
>> hit [review] to start Rietveld and request a side-by-side diff of the two
>> versions.  This is perfect for reviewing responses to comments, especially
>> those made in-line.  For this issue, Martin made about 20 inline comments.
>>
>> I don't see any way to get the equivalent on a github PR.  It appears
>> that the original patch is replaced by the revised patch.  To me, Rietveld
>> was a great review tool and its loss a regression in the work process. I
>> hope that this can be fixed somehow.
>>
>> tjr
>>
>>
>>
>> ___
>> Core-mentorship mailing list
>> core-mentors...@python.org
>> https://mail.python.org/mailman/listinfo/core-mentorship
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> ___
> 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/
>
>
___
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] Deprecation Policy PEP Thread

[Mariatta Wijaya]

> My assumption is, there is still in active interest in documenting our
> deprecation policy, and it might be a good idea to move forward with a
> pep PR?

+1

> I suspect that there is something in the devguide also
I searched the devguide about deprecation policy, and it didn't turn up
anything.


Mariatta Wijaya

On Sun, Apr 9, 2017 at 9:20 PM, Terry Reedy <tjre...@udel.edu> wrote:

> On 4/9/2017 3:09 PM, Senthil Kumaran wrote:
>
>> I was looking for our Deprecation Policy and stumbled on this thread
>> from January 2016.
>>
>> -
>>
>> PEP: XXX
>> Title: Deprecation Policy
>> Version: $Revision$
>> Last-Modified: $Date$
>> Author: Ezio Melotti 
>> Status: Draft
>> Type: Process
>> Content-Type: text/x-rst
>> Created: 29-Jan-2016
>> Post-History:
>>
>> https://mail.python.org/pipermail/python-committers/2016-
>> January/003706.html
>>
>> I see that Ezio has already answered many questions in that thread,
>> and perhaps a minor update to the proposal text is required.
>>
>> My assumption is, there is still in active interest in documenting our
>> deprecation policy, and it might be a good idea to move forward with a
>> pep PR?
>>
>
> Yes.  I suspect that there is something in the devguide also, but users as
> well as contributors have an interest in the subject.
>
> tjr
>
>
> ___
> 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/

[python-committers] cherry_picker.py is now in core-workflow repo

[Mariatta Wijaya]

Hi,

I imported my cherry picker script into https://github.com/
python/core-workflow/tree/master/cherry_picker/

Please try it out if you need to do backports for CPython. It still needs
some improvement with handling merge conflict, but if you don't anticipate
any conflict then it should make things easy for you. (things that do not
involve Misc/NEWS, for example)

After the migration, I used it to cherry-pick this PR:
https://github.com/python/cpython/pull/670 can confirm it works.

Thanks Nick Coghlan who has started using and contributing to it too :)
I believe he has a PR coming soon that adds a --dry-run option, which I
look forward to :)

Mariatta Wijaya
___
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] 4 weeks with the new workflow: what needs changing?

[Mariatta Wijaya]

>
> Requiring Travis to pass


Yes please.

 Cherry-picking working out?

Works for me. And I've done a lot of this :)

are the labels for cherry-picking working out?

I like the [3.6] Prefix (Thanks Berker for suggesting it originally)
I think [cherry-pick for  3.6] label is still useful as a visual cue in the
GitHub Web UI, but it does create extra work for core devs to apply the
labels. Perhaps won't be an issue once the cherry-pick bot is in place?
Anyway, I think we should keep both :)

Is the mention bot helpful?
>
I think if we can reduce the number of reviewers from 5 to 3 or 2, it might
reduce the amount of spam people are getting?
When someone starts blacklisting themselves from the mention-bot, it
just means that another person will now get spammed, and then decided to
blacklist themselves too.

anything I missed?

I'm wishing for an easy way to differentiate/identify PRs where:
- It's been reviewed, changes were requested, but author has not
responded/made updates. --> so don't bother reviewing
- It's been reviewed, changes were requested, and author has updated the
PR. --> so it's ready for another look
At the moment, both of these scenarios are shown as  "Changes Requested" in
GitHub web UI. It's hard to determine whether it's time to re-review the PR
or not.

Maybe we can add [wip] in the title after we requested the change. Once PR
author made further changes, they can remove the [wip].

Right now, cherry-picking is very annoying but I'm not sure that
> merging would be much better with the PR requirement.  I'm looking
> forward to automation!


I have a semi-automated command line script here:
https://github.com/mariatta/chic_a_cherry_picker
Please try it out :) I've cherry-picked quite a number of commits with this.
Works well when you don't anticipate any merge conflicts :)

The command line is something like:
$ python -m cherry_picker some-commit-sha1 3.6 3.5
It will do the cherry-pick and opens up web browser for creating the PR,
with head and base branches preselected.
All you need to do is enter [3.5] or [3.6] in the description, and press
the shiny green 'Create Pull Request' button.

Related: here's a list of merged PRs that need backporting to 3.6
https://github.com/python/cpython/pulls?utf8=%E2%9C%93=is%3Apr%20label%3A%22needs%20backport%20to%203.6%22%20is%3Amerged%20


Overall, I'm positive on the move.  Thanks for continuing to shepherd
> the migration, Brett!

+1.Thanks!



Mariatta Wijaya

On Sat, Mar 11, 2017 at 8:05 AM, Donald Stufft <don...@stufft.io> wrote:

>
> On Mar 11, 2017, at 3:03 AM, Zachary Ware <zachary.ware+py...@gmail.com>
> wrote:
>
>
> Is the mention bot helpful? (Our config is at
> https://github.com/python/cpython/blob/master/.mention-bot and the docs
> are
> at https://github.com/facebook/mention-bot)
>
>
> I think so, it has prompted me to give a quick review on a couple of
> PRs.  It is occasionally annoying, but it's not hard to ignore.  I can
> see how it would be *very* annoying for anyone who has touched large
> swaths of the codebase, though.  If there's a way to make it opt-in,
> perhaps we could give that a spin?
>
>
>
> There’s no way to make it opt-in except by having people explicitly list
> what files they want to be notified on (either on an always basis, or on a
> “if you couldn’t find enough people through your heuristics” basis).
>
> —
> 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/
>
___
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] REMINDER: GitHub migration is scheduled for today

[Mariatta Wijaya]

So exciting!
Good luck and thanks for all the hard work!


On Feb 10, 2017 7:56 AM, "Brett Cannon"  wrote:

> Assuming you can't commit to Mercurial anymore and the next email from me
> will either be an introduction email to our new workflow or me apologizing
> for something going horribly wrong. Either way I'm hoping you will hear
> from me later today. :)
>
> ___
> 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/

[python-committers] New team member intro

[Mariatta Wijaya]

Hi!

Thank you all, for inviting me here. It's a real honor.

I still have a lot to learn from all of you, and I realize that the real
hard work is just starting now.
But at least I was promised a fun club to be in ;)

Looking forward contributing more and working with everyone here :)

Raymond, Guido, thank you again for taking me under your wing.

Mariatta Wijaya
___
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/