[core-workflow] Re: Hi everyone

I unsubscribed this user, added them to the ban list, and have turned on moderation for this list. If I can keep up with the moderation then great, otherwise we will most likely retire this list in favour of https://discuss.python.org/c/core-workflow/8. On Thu, Aug 13, 2020 at 3:37 AM wrote: >

[core-workflow] Re: Proposal for creating github spellcheck bot.

; > > > On Fri, Jun 7, 2019 at 1:58 AM Brett Cannon wrote: > >> Are you thinking something that adds checks to the PR or comments w/ >> proposed fixes? >> >> On Wed, Jun 5, 2019 at 8:39 PM Chen KunYu wrote: >> >>> Hi, >>> >>&

[core-workflow] Re: Proposal for creating github spellcheck bot.

Are you thinking something that adds checks to the PR or comments w/ proposed fixes? On Wed, Jun 5, 2019 at 8:39 PM Chen KunYu wrote: > Hi, > > Recently, tirkarthi (xtreak) works on finding and fixing typos. > > And I (18z) came up with the idea of creating a spellcheck bot to improve > the

[core-workflow] Re: "Awaiting merge" label for PRs from core devs

FYI I opened a poll at https://discuss.python.org/t/poll-what-label-should-prs-from-core-devs-automatically-receive/970 to settle this question of what label core dev PRs whould automatically receive. On Tue, Sep 11, 2018 at 2:49 PM Brett Cannon wrote: > > > On Tue, 11 Sep 2018 at 0

[core-workflow] Re: "Awaiting merge" label for PRs from core devs

On Tue, 11 Sep 2018 at 07:33 Nick Coghlan wrote: > On Tue, 11 Sep 2018 at 05:13, Brett Cannon wrote: > >> On Mon, 10 Sep 2018 at 11:50 Mariatta Wijaya >> wrote: >> >>> I prefer keeping the labeling as is, so core devs PR get "awaiting >>> me

[core-workflow] Re: "Awaiting merge" label for PRs from core devs

on. If it doesn't do that, then that's the > change we should implement, instead of the "no label by default". > I don't think it does. -Brett > > Mariatta > > ᐧ > > On Thu, Sep 6, 2018 at 12:47 PM Berker Peksağ > wrote: > >> On Thu, Sep 6, 2018

[core-workflow] Re: "Awaiting merge" label for PRs from core devs

On Wed, 5 Sep 2018 at 13:37 Zachary Ware wrote: > On Wed, Sep 5, 2018 at 3:31 PM Brett Cannon wrote: > > > > So the reasoning behind setting "awaiting merge" is because the "needs" > label is meant to represent what is holding up the PR from being closed, &

[core-workflow] Re: "Awaiting merge" label for PRs from core devs

So the reasoning behind setting "awaiting merge" is because the "needs" label is meant to represent what is holding up the PR from being closed, and so a PR from a core dev is really just blocked on merging since they don't have to receive a review. Now, if people would rather move it over to

[core-workflow] Re: Using Gitmate to help with PR triage

As the person who chose the colour scheme, I'll try to explain why I did it the way I did. :) If you look at https://github.com/python/cpython/labels you will notice all related labels that have the same prefix are the same colour *unless* there is a reason to make it stand out (e.g.

[core-workflow] Re: Please reenable AppVeyor

Done! On Sat, 9 Jun 2018 at 09:49 Victor Stinner wrote: > Hi, > > It seems like AppVeyor is stable again, and test_asyncio has been > fixed, so I suggest to make AppVeyor required again on 2.7, 3.6, 3.7 > and master branches. > > I just closed the issue of the most annoying test_asyncio

[core-workflow] Re: Time to switch off AppVeyor and start requiring VSTS for Windows?

I don't think it's a hard blocker. -Brett > > Victor > > 2018-06-05 20:07 GMT+02:00 Brett Cannon : > > > > > > On Tue, 5 Jun 2018 at 03:52 Victor Stinner wrote: > >> > >> Steve has no plan to support VSTS on Python 2.7: > >> > >>

[core-workflow] Re: Time to switch off AppVeyor and start requiring VSTS for Windows?

hanges than 3.x & master branches. > Yep, that's what I was thinking of doing on Friday. -Brett > > Victor > > 2018-06-04 20:34 GMT+02:00 Brett Cannon : > > We had to turn off AppVeyor as a requirement today due to it not running > any > > builds for the last 2

[core-workflow] Re: Time to switch off AppVeyor and start requiring VSTS for Windows?

On Mon, 4 Jun 2018 at 11:56 Ned Deily wrote: > On Jun 4, 2018, at 14:34, Brett Cannon wrote: > > We had to turn off AppVeyor as a requirement today due to it not running > any builds for the last 20 hours. Ned Deily suggested that since VSTS on at > least Windows has stabilize

[core-workflow] Re: The current thinking/plans around VSTS as our CI

On Fri, 1 Jun 2018 at 13:22 Mariatta Wijaya wrote: > that miss-islington doesn't distinguish between required and optional >> status checks when deciding whether to automatically merge. > > > What's the decision surrounding this? Should I make miss-islington ignore > the optional status checks?

[core-workflow] Re: The current thinking/plans around VSTS as our CI

ds > > Antoine. > > > > On Thu, 17 May 2018 10:54:27 -0400 > Brett Cannon <br...@python.org> wrote: > > Since both Paul Moore and Antoine Pitrou started to ask questions about a > > side comment I made about VSTS, I might as well start a discuss

[core-workflow] Re: Workflow for the PR?

On Wed, 23 May 2018 at 06:59 Stephane Wirtel <steph...@wirtel.be> wrote: > On 05/16, Brett Cannon wrote: > >On Tue, 15 May 2018 at 13:03 Berker Peksağ <berker.pek...@gmail.com> > wrote: > > > >> On Tue, May 15, 2018 at 6:12 PM, Stephane Wirtel <ste

[core-workflow] Re: The current thinking/plans around VSTS as our CI

On Fri, May 18, 2018, 21:32 Nick Coghlan, <ncogh...@gmail.com> wrote: > On 18 May 2018 at 02:44, Brett Cannon <br...@python.org> wrote: > >> I'll also not quite sure why this is different than the credits we get >> from e.g. Heroku/Salesforce for the bots or

[core-workflow] Re: The current thinking/plans around VSTS as our CI

On Fri, 18 May 2018 at 01:09 Gregory P. Smith wrote: > > Hi all, > > > > I had a long discussion with Steve at PyCon about VSTS. The benefits > seem promising. > > > > Perhaps a reasonable step forward is to run Travis, AppVeyor, and VSTS > as required for 3 > > months or 6

[core-workflow] Re: The current thinking/plans around VSTS as our CI

On Thu, 17 May 2018 at 12:57 Antoine Pitrou <solip...@pitrou.net> wrote: > > Hi Brett, > > On Thu, 17 May 2018 10:54:27 -0400 > Brett Cannon <br...@python.org> wrote: > > Since both Paul Moore and Antoine Pitrou started to ask questions about a > > side com

[core-workflow] The current thinking/plans around VSTS as our CI

Since both Paul Moore and Antoine Pitrou started to ask questions about a side comment I made about VSTS, I might as well start a discussion (Steve has also *just* emailed python-committers about this topic). Basically Steve Dower and I have been working directly with the VSTS team to improve

[core-workflow] Re: Workflow for the PR?

On Tue, 15 May 2018 at 13:03 Berker Peksağ wrote: > On Tue, May 15, 2018 at 6:12 PM, Stephane Wirtel > wrote: > > For me, normally, the label should be on "awaiting changes" and after > > a new commit/message from the author, the label should be

[core-workflow] Re: IRC vs Slack vs Discord vs Gitter

On Fri, 6 Apr 2018 at 20:59 Craig Rodrigues <rodr...@crodrigues.org> wrote: > On Thu, Apr 5, 2018 at 6:56 PM, Brett Cannon <br...@python.org> wrote: > >> >> >> Yes, you're jumping the gun.  As I mentioned yesterday, the plan is to >> open it up tomor

[core-workflow] Re: IRC vs Slack vs Discord vs Gitter

2018 at 11:20 Greg Price <g...@zulipchat.com> wrote: > On Mon, Apr 2, 2018 at 10:49 AM, Brett Cannon <br...@python.org> wrote: > >> Yep, I logged in without issue! I will start setting things up this week. >> > > Great! Naturally don't hesitate to let me

[core-workflow] Re: IRC vs Slack vs Discord vs Gitter

seems in order? > Yep, I logged in without issue! I will start setting things up this week. -Brett > > Greg > > > On Mon, Apr 2, 2018 at 9:51 AM, Brett Cannon <br...@python.org> wrote: > >> OK, then I'll hold off until we here from Greg about whether we can get >

[core-workflow] Re: IRC vs Slack vs Discord vs Gitter

n Sun, Apr 1, 2018 at 11:08 AM, Brett Cannon <br...@python.org> wrote: > >> >> >> On Sun, 1 Apr 2018 at 10:28 Brett Cannon <br...@python.org> wrote: >> >>> On Sun, 1 Apr 2018 at 01:09 Greg Price <g...@zulipchat.com> wrote: >>> >>&

[core-workflow] Re: IRC vs Slack vs Discord vs Gitter

On Sun, 1 Apr 2018 at 10:28 Brett Cannon <br...@python.org> wrote: > On Sun, 1 Apr 2018 at 01:09 Greg Price <g...@zulipchat.com> wrote: > >> [SNIP] <https://zulipchat.com/for/open-source/> >> >> To set up a Zulip community, someone can follow any of th

[core-workflow] Re: IRC vs Slack vs Discord vs Gitter

Speaking to my own experience, I have never gotten involved in IRC because I don't want to have pay for a reflector to know who mentioned me, I don't want to maintain a server just to have a reflector for free, and I don't want or have a PC to leave on 24/7 to simply stay connected. I personally

[core-workflow] Re: adding a news entry via the web interface

On Mon, 26 Mar 2018 at 10:31 Ethan Furman wrote: > On 03/26/2018 10:24 AM, Mariatta Wijaya wrote: > > > Not yet, I was thinking of implementing it, as I wanted this feature > too. But wasn't sure if others will also find it > > useful, so I haven't put a lot of effort into

[core-workflow] Re: Making 'blurb' more visible?

On Tue, 20 Feb 2018 at 09:51 Chris Angelico wrote: > On my recent PR (#340 on GitHub, fwiw), I got a Bedevere check failure > for not including a NEWS entry. Couldn't remember the name of the tool > used to create them, and had to go digging quite a bit before I found > it. Is

[core-workflow] Re: Add a "refactoring" type to the issue tracker?

I would consider a "code health" a more general type for things that are not user-facing. On Wed, Feb 14, 2018, 10:11 Nick Coghlan, wrote: > For https://bugs.python.org/issue32836, I ended up picking "behaviour" > as the issue type (since we're reporting that we're using a

[core-workflow] Re: Travis CI running out of disk space

The only reason I could think it's our fault is from the pip caching we have turned on. On Wed, Nov 29, 2017, 13:42 Doug Hellmann, wrote: > Excerpts from Mariatta Wijaya's message of 2017-11-29 09:35:36 -0800: > > I saw this twice in the past week, Travis build on CPython

[core-workflow] Re: Turning off bedevere-bot messages for core dev PRs?

So basically you want it to be permanently set to "awaiting merge" when a core dev is the PR creator regardless of where the reviews come from? The other option is introducing an 'awaiting nothing' label that automatically applies to PRs authored by core devs and that basically turns off touching

Re: [core-workflow] Using CircleCI

On Tue, 14 Nov 2017 at 10:57 Lev Lazinskiy wrote: > Hi team! > > I recently submitted a PoC PR to the dev guide repo [1] that shows how > this repo could be built on CircleCI. > > The immediate problem that I was trying to solve was to get a free and > easy way to store the

Re: [core-workflow] Use something other than an In-joke for Trigger Phrases

ll accidentally type that in conversation on a pull request. On Tue, 10 Oct 2017 at 00:09 Ethan Furman <et...@stoneleaf.us> wrote: > On 10/08/2017 09:44 AM, Brett Cannon wrote: > > > I actually wouldn't want the bot name in the trigger phrase since you're > not addressing the bot bu

Re: [core-workflow] Use something other than an In-joke for Trigger Phrases

See https://github.com/python/bedevere/pull/66 for a PR to support an additional, more muted trigger phrase (currently "Please review again"). On Sun, 8 Oct 2017 at 09:44 Brett Cannon <br...@python.org> wrote: > On Sun, 8 Oct 2017 at 00:55 Nick Coghlan <ncogh...@gmail

Re: [core-workflow] Use something other than an In-joke for Trigger Phrases

On Sun, 8 Oct 2017 at 00:55 Nick Coghlan wrote: > On 8 October 2017 at 07:38, Donald Stufft wrote: > >> Currently the workflow for CPython development requires people to say 'I >> didn't expect the Spanish Inquisition’ in order to request a re-review of >>

Re: [core-workflow] Devguide Reorganization

I haven't looked at the results of this work but it all sounds great! Thanks to everyone who worked on this! I really appreciate and support the shift towards "getting things done"-focused docs in the devguide where lower-level details get shifted in an appendix section that people can reference

[core-workflow] An update on my future workflow plans

With the addition of stage labels to Bedevere, I thought it was time to update the mailing list with my current plans for the workflow. 1. Status check for a news entry (I can probably just commit it since all news entries should be going in

Re: [core-workflow] Auto labeling PRs based on what stage they're in

they transition. Unless someone points out a major flaw or speaks up that they think the labels or this idea is really bad, I will probably merge it sometime next week (after I get my test coverage back up). On Sat, 17 Jun 2017 at 12:07 Brett Cannon <br...@python.org> wrote: > I don't k

[core-workflow] Looking for reviewers on a PR to add a check for whitespace

https://github.com/python/core-workflow/issues/3 is tracking adding a check for proper whitespace in PRs as we had that on hg.python.org but we are missing it on GitHub. I have a PR at https://github.com/python/cpython/pull/2367 that I think does the right thing, but I would appreciate a quick

Re: [core-workflow] Auto labeling PRs based on what stage they're in

On Mon, Jun 19, 2017, 18:15 Nick Coghlan, <ncogh...@gmail.com> wrote: > On 20 June 2017 at 03:39, Brett Cannon <br...@python.org> wrote: > > OK, here is a dot graph that lays out the stages and the flow between > them > > based on what has been discusse

Re: [core-workflow] Auto labeling PRs based on what stage they're in

proves PR", color=green] "Awaiting review" -> "Awaiting changes" [label="Core dev requests changes", color=green] "Awaiting core review" -> "Awaiting merge" [label="Core dev approves PR", color=green] "N

Re: [core-workflow] Auto labeling PRs based on what stage they're in

On Sun, Jun 18, 2017, 09:56 Mariatta Wijaya, <mariatta.wij...@gmail.com> wrote: > > On Sun, Jun 18, 2017 at 9:36 AM, Brett Cannon <br...@python.org> wrote: > >> At some point in the future, we >>> could potentially even go to an OpenStack style flow where Be

Re: [core-workflow] Auto labeling PRs based on what stage they're in

On Sat, 17 Jun 2017 at 18:11 Nick Coghlan <ncogh...@gmail.com> wrote: > On 18 June 2017 at 05:07, Brett Cannon <br...@python.org> wrote: > > The stages I see are: > > > > 1. Awaiting first review: no one has reviewed the PR > > I'd just make this "

[core-workflow] Auto labeling PRs based on what stage they're in

I don't know about the rest of you, but I want an easy way to glance at a pull request and know what it's currently blocking it from being merged (if I'm wrong then let me know). I opened https://github.com/python/core-workflow/issues/94 for this idea, but I figured what the exact stages should be

Re: [core-workflow] Do we still have mention-bot?

Facebook's instance that we use was returning a 500 to the webhooks. I just redelivered the payloads for the failures on the first page of webhook events. On Sun, 11 Jun 2017 at 10:05 Mariatta Wijaya wrote: > The newest PRs in CPython don't have any comment from

[core-workflow] Creating a PyPI account for workflow tools

I'm thinking we should create an account to own things like cherry_picker and blurb for when they get put on PyPI. I'm not sure if it should be specific to core-workflow or generic to python-dev, though? Anyone have an opinion on the scope of the account?

Re: [core-workflow] Requirements to make AppVeyor a required status check

On Sat, 3 Jun 2017 at 03:17 Antoine Pitrou <solip...@pitrou.net> wrote: > On Fri, 02 Jun 2017 19:10:52 +0000 > Brett Cannon <br...@python.org> wrote: > > https://github.com/python/core-workflow/issues/41 is tracking the idea > of > > requiring AppVeyor to

Re: [core-workflow] Prefix GitHub labels to group them?

n Ehtesham <uehtesha...@gmail.com> wrote: > >> My vote is on full word prefixes (small words where and when possible) >> >> > On May 26, 2017, at 5:36 PM, Brett Cannon <br...@python.org> wrote: >> > >> > Something the Rust project does is prefix all the

Re: [core-workflow] travis bottleneck at sprints

Donald is our contact with Travis, so I've explicitly added him to this email. To give some details: we get 25 concurrent jobs across all the various "official" Python projects on GitHub hosted under the Python, PyPA, and PyCA organizations (which is a substantial bump from what most projects

Re: [core-workflow] Workflow for applying b.p.o patches to GitHub

On Mon, 15 May 2017 at 09:49 Mariatta Wijaya wrote: > Hi, > > I'd like to get clarification of the proper workflow for applying patches > from b.p.o to GitHub. > > Technically, one can use patch command, or using hg diff --git, and this > will be documented in

Re: [core-workflow] Are the "cherry-pick for *" labels on GitHub useful?

Since everyone who voiced an opinion agreed that the label is unnecessary, I will happily accept your offer to remove it from everything that's relevant, Mariatta. :) On Fri, 12 May 2017 at 23:42 Mariatta Wijaya wrote: > OK then it seems like the there is no real need

[core-workflow] Are the "cherry-pick for *" labels on GitHub useful?

Enough people who work on CPython still use email that instead of just using labels to flag PRs as cherry-picks we also edit the title, e.g. a 3.6 cherry-pick will have both a "cherry-pick for 3.6" label and "[3.6]" prepended to the title. My question is whether anyone is actually using the

Re: [core-workflow] What do people want Bedevere to do for issue numbers in PRs?

original message to include a link in addition to > the status check? > > Sent from my iPhone > > On Apr 15, 2017, at 6:21 PM, Brett Cannon <br...@python.org> wrote: > > When I implemented Bedevere's bpo issue number detection it was to do it > as a status check as I thou

[core-workflow] What do people want Bedevere to do for issue numbers in PRs?

When I implemented Bedevere's bpo issue number detection it was to do it as a status check as I thought that's what people wanted ( https://github.com/python/core-workflow/issues/13). But now others are saying they want a comment with a link to the issue number (

Re: [core-workflow] Where to host documentation? (was: Voting on possible subdomains for the devguide)

On Tue, 11 Apr 2017 at 12:29 Elvis Pranskevichus <elpr...@gmail.com> wrote: > On Tuesday, April 11, 2017 3:11:10 PM EDT Brett Cannon wrote: > > > GH Pages support custom domain redirects [1]. "setup" in this case > > > is putting together scripts to

[core-workflow] Where to host documentation? (was: Voting on possible subdomains for the devguide)

On Tue, 11 Apr 2017 at 11:28 Elvis Pranskevichus <elpr...@gmail.com> wrote: > On Tuesday, April 11, 2017 2:09:33 PM EDT Oleg Broytman wrote: > > On Tue, Apr 11, 2017 at 05:58:38PM +0000, Brett Cannon <br...@python.org> > wrote: > > > On Tue, 11 Apr 2017 a

Re: [core-workflow] Voting on possible subdomains for the devguide

On Tue, 11 Apr 2017 at 10:52 Elvis Pranskevichus wrote: > On Tuesday, April 11, 2017 1:41:45 PM EDT Guido van Rossum wrote: > > Last I heard from then, RTD was struggling financially. Hosting isn't > > really free, you know -- nor is administering a site like that :-). > > The

Re: [core-workflow] Voting on possible subdomains for the devguide

On Tue, 11 Apr 2017 at 10:42 Guido van Rossum wrote: > Last I heard from then, RTD was struggling financially. Hosting isn't > really free, you know -- nor is administering a site like that :-). The PSF > should offer to cover their costs for hosting the Python docs, which I >

[core-workflow] Voting on possible subdomains for the devguide

With part of the goal of moving to GitHub being to minimize how much infrastructure we have to run, one of the long-term goals I have is to use Read the Docs to host Python's documentation. But to get there we have to move any "special" docs over first. That means relocating the devguide (it also

[core-workflow] I have created https://github.com/python/bedevere

The Heroku instance is set up, but I have not turned it on for the CPython repo yet as I'm sick and that just means I will mess up any debugging I may need to do if something goes wrong. :) So once I'm well I will turn it on (the way I'm feeling, probably not until the latter half of next week :(

Re: [core-workflow] Please disable CLA checking for trivial GitHub patches

As shown in the response to your PR, core devs are able to override the bot by simply ignoring the check (that's why it's not required to pass for PR acceptance). But the bot will never be adjusted to make its own call on what is or is not covered. It's too risky legally to get this wrong, e.g.

[core-workflow] Working towards a decision on Misc/NEWS

https://github.com/python/core-workflow/issues/6#issuecomment-287472168 We have three tools in the running: towncrier from Twisted, reno from OpenStack, and blurb from Larry Hastings. We have PRs containing example output for each tool for people to look at to see what the input and output will

[core-workflow] My new, asynchronous GitHub library

Since people have been discussing writing various bots to help automate the workflow, I thought I should let this list know that I have created https://github.com/brettcannon/gidgethub. Specifically this is a GItHub library that is asynchronous from the bottom-up so there won't be any scaling

Re: [core-workflow] self-approving pull requests

On Thu, 2 Mar 2017 at 16:16 Yury Selivanov wrote: > > > On 2017-03-02 7:11 PM, Donald Stufft wrote: > > I'm on my phone but unless Travis is backed up it sounds like something > got lost somewhere. Multi hour waits is not typical. > > Travis is overloaded a little bit at

Re: [core-workflow] self-approving pull requests

The discussion of automating the creation of cherry-pick PRs is at https://github.com/python/core-workflow/issues/8. And the requirement of the PR is to force people to go through CI to verify the cherry-pick took cleanly (and the Travis config is structured to only run the test suite if the PR

[core-workflow] Travis is now required to be passing, reviews are not

I didn't turn on Codecov requirements for the patch because we seem to still have variance in them where some module that are inconsistently being tested (there is a test for the whole project but I left that off as well). I think we should definitely work towards fixing the coverage variance as I

Re: [core-workflow] self-approving pull requests

Two things. One, has someone verified that if a core dev edits a PR that the squash commit still gives the PR creator the author credit in the git metadata? I remember doing an edit like this once and GitHub didn't show any author credit in the web UI because I assume GitHub refused to guess who

[core-workflow] Migration is done!

A massive thank you to everyone who helped with this. It has been a long road but we finally reached the end of it! As for what's next, I think getting Misc/NEWS straightened out and then getting cherry-picking PRs automated are the next important items. As always

Re: [core-workflow] The migration has started

r Canada Dry, though. :) -Brett > > On 10 Feb 2017, at 18:52, Brett Cannon <br...@python.org> wrote: > > We are hanging out in #python-dev on Freenode if you care to swing by > while we work on things. I also created > https://trello.com/b/S5WbJfjP/github-migration to tra

Re: [core-workflow] Final chance to express opinion on history rewrite for issue #s

Szulik <solt...@gmail.com> wrote: > On Thu, Feb 9, 2017 at 6:37 PM, Brett Cannon <br...@python.org> wrote: > > (Maciej was positive but didn't say +1 or +0; Martin said -0.5 which isn't > a valid vote, so I rounded up for him; I'm personally on the fence so > voting conser

Re: [core-workflow] Final chance to express opinion on history rewrite for issue #s

on how this test goes. :) On Thu, 9 Feb 2017 at 15:00 Yury Selivanov <yselivanov...@gmail.com> wrote: > If it's not too late my opinion is `-1`. I agree with MAL. > > Yury > > On 2017-02-09 12:37 PM, Brett Cannon wrote: > > +1: Nick, Senthil, Chris > > +0: ... &g

Re: [core-workflow] Final chance to express opinion on history rewrite for issue #s

On Thu, 9 Feb 2017 at 11:51 Senthil Kumaran wrote: > On Thu, Feb 9, 2017 at 10:43 AM, Nick Coghlan wrote: > >> If people don't like that idea the appending works for me if it isn't > >> difficult for Senthil. > > > > but I'd still prefer this to not

Re: [core-workflow] Final chance to express opinion on history rewrite for issue #s

On Thu, 9 Feb 2017 at 10:15 Nick Coghlan wrote: > On 9 February 2017 at 18:59, Zachary Ware > wrote: > > On Thu, Feb 9, 2017 at 11:52 AM, Nick Coghlan > wrote: > >> You can't readily do that with "#12345" or even "Issue

[core-workflow] Final chance to express opinion on history rewrite for issue #s

+1: Nick, Senthil, Chris +0: ... -0: Martin, Brett -1: Naoki, Berker (Maciej was positive but didn't say +1 or +0; Martin said -0.5 which isn't a valid vote, so I rounded up for him; I'm personally on the fence so voting conservatively now but can switch that view) If you have an opinion please

[core-workflow] Choosing a label format for cherry-picking reminders

Since we are going to need reminders of what versions of Python to cherry-pick a PR into, I figured this was a perfect use of labels. If you want to provide feedback on possible formats for the label, add appropriate reactios to https://github.com/python/core-workflow/issues/17 .

[core-workflow] Block direct pushes to the cpython repo?

I opened https://github.com/python/core-workflow/issues/16 to track the idea of turning off direct pushes to the git repo after the migration at some point. But immediately both Senthil and Barry voted to say they thought we should just start off on the proper footing and just block direct pushes

Re: [core-workflow] Choosing a prefix/label for issue numbers

On Fri, 3 Feb 2017 at 16:25 Ned Deily <n...@python.org> wrote: > On Feb 3, 2017, at 19:16, Brett Cannon <br...@python.org> wrote: > > On Fri, 3 Feb 2017 at 16:06 Ned Deily <n...@python.org> wrote: > >> 2. What about Misc/NEWS entries? Are we going to continu

[core-workflow] Draft of letter announcing migration

I have written up what I will say to python-committers once the migration is complete: https://paper.dropbox.com/doc/CPython-workflow-changes-mx1k8G6M0rg5JLy80F1r6 . Feel free to leave comments if you think there is something I missed (which can include thanking you; this has taken so long I'm

[core-workflow] GitHub migration scheduled for Friday, Feb 10

I plan to start writing a doc covering workflow changes today or tomorrow in preparation for Friday. ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of

Re: [core-workflow] Choosing a prefix/label for issue numbers

On Fri, 3 Feb 2017 at 17:32 Senthil Kumaran <sent...@uthcode.com> wrote: > On Fri, Feb 3, 2017 at 5:20 PM, Brett Cannon <br...@python.org> wrote: > > And since we will be creating a new project there will be no pre-existing > > issues to accidentally link to when

Re: [core-workflow] Choosing a prefix/label for issue numbers

n <sent...@uthcode.com> wrote: > > On Wed, Feb 1, 2017 at 4:51 PM, Brett Cannon <br...@python.org> wrote: > >> That's a question for Senthil, but I would be a little worried about > editing > >> the history as the match should be probably s/issue #(\d+)/bpo-\1/

Re: [core-workflow] Choosing a prefix/label for issue numbers

On Fri, 3 Feb 2017 at 16:06 Ned Deily <n...@python.org> wrote: > On Feb 3, 2017, at 18:24, Brett Cannon <br...@python.org> wrote: > > It looks like people in general prefer "bpo-" (sorry, Ned and MAL). > > I'll live. :) > > > Maciej, can we

Re: [core-workflow] Choosing a prefix/label for issue numbers

It looks like people in general prefer "bpo-" (sorry, Ned and MAL). Maciej, can we update the requisite regexes so that bpo- is acceptable in PR titles, PR comments, and commit messages? On Wed, 1 Feb 2017 at 09:43 Brett Cannon <br...@python.org> wrote: > Historica

Re: [core-workflow] Choosing a prefix/label for issue numbers

On Wed, 1 Feb 2017 at 15:45 Ned Deily <n...@python.org> wrote: > On Feb 1, 2017, at 18:14, Brett Cannon <br...@python.org> wrote: > > On Wed, 1 Feb 2017 at 14:34 Ned Deily <n...@python.org> wrote: > >> On Feb 1, 2017, at 16:35, Brett Cannon <br...@pytho

Re: [core-workflow] Choosing a prefix/label for issue numbers

On Wed, 1 Feb 2017 at 14:34 Ned Deily <n...@python.org> wrote: > On Feb 1, 2017, at 16:35, Brett Cannon <br...@python.org> wrote: > > On Wed, 1 Feb 2017 at 12:23 Ned Deily <n...@python.org> wrote: > >> Perhaps I'm misunderstanding something. Are we planning

Re: [core-workflow] Choosing a prefix/label for issue numbers

On Wed, 1 Feb 2017 at 12:23 Ned Deily wrote: > Perhaps I'm misunderstanding something. Are we planning to alter existing > commit messages as part of the hg to fit transition? > No, we are not mucking with the history as part of the transition. -Brett > > -- > Ned

Re: [core-workflow] Choosing a prefix/label for issue numbers

On Wed, Feb 1, 2017, 11:43 Ned Deily, <n...@python.org> wrote: > On Feb 1, 2017, at 14:14, Brett Cannon <br...@python.org> wrote: > > On Wed, 1 Feb 2017 at 11:02 Ned Deily <n...@python.org> wrote: > >> On Feb 1, 2017, at 12:43, Brett Cannon <br...@python

Re: [core-workflow] Choosing a prefix/label for issue numbers

ookup also now supports "git" and "hg" prefixes on commit IDs/hashes to easily differentiate since Python as a project continues to outlive the infrastructure it runs on :) . -Brett > > Cheers, > -- > M > > > > > > On Wed, Feb 1, 2017

Re: [core-workflow] Choosing a prefix/label for issue numbers

On Wed, 1 Feb 2017 at 11:02 Ned Deily <n...@python.org> wrote: > On Feb 1, 2017, at 12:43, Brett Cannon <br...@python.org> wrote: > > Historically commit messages for CPython have had the form of "Issue > #: did something". The problem is that Github autom

Re: [core-workflow] Planning the GitHub migration

[another missing step; I can't wait to put all of these proverbial "spinning plates] On Tue, 31 Jan 2017 at 10:26 Brett Cannon <br...@python.org> wrote: > [for my own notes, I forgot something in the list] > > On Mon, 30 Jan 2017 at 15:21 Brett Cannon <br...@python.org&g

[core-workflow] last blocker for the GitHub migration is in!

Thanks to the very hard work of Maciej and Ezio, the final change required of bpo is in! That should be the last blocker for the migration. ( https://github.com/python/peps/blob/master/pep-0512.txt#L698 as always is the "official" todo list.) If there is any critical blocker that people feel

[core-workflow] Update on the GitHub migration

The last blocker is updating issues on bugs.python.org when a commit is made that references an issue (Maciej is working on it, although as usual I'm sure help is welcome). Once that's in then it will be time to choose a date to stop commits and do the conversion. Once that's done it will be a

Re: [core-workflow] GitHub migration update for 2016-12-19

; On Tue, 20 Dec 2016 02:49:03 + > > Brett Cannon <br...@python.org> wrote: > >> The biggest update is I have updated the code for hg.python.org/lookup. > >> Once the hg repo is read-only I will generate a final JSON file > containing > >> ever

Re: [core-workflow] GitHub migration update for 2016-12-19

to hg.python.org). On Mon, 19 Dec 2016 at 23:49 Antoine Pitrou <solip...@pitrou.net> wrote: > On Tue, 20 Dec 2016 02:49:03 +0000 > Brett Cannon <br...@python.org> wrote: > > The biggest update is I have updated the code for hg.python.org/lookup. > > Once the hg repo is read-onl

[core-workflow] New core-workflow issue tracker

I have created https://github.com/python/core-workflow to track ideas and plans related to this mailing list. Figured that while this list is nice for discussion an issue tracker was needed to track is actually planned. ___ core-workflow mailing list

Re: [core-workflow] GitHub migration update for 2016-12-03

On Mon, 5 Dec 2016 at 04:14 Antoine Pitrou <solip...@pitrou.net> wrote: > On Sun, 04 Dec 2016 00:40:49 +0000 > Brett Cannon <br...@snarky.ca> wrote: > >- I got the code for hg.python.org/hglookup > > - Asking if there's any reason I can't post it publ

[core-workflow] GitHub migration update for 2016-12-03

- Started the conversation with Zach Ware about updating the buildbots (doesn't sound too troublesome) - Maciej and Ezio got a GitHub PR field added to bugs.python.org - Next step is to review http://psf.upfronthosting.co.za/roundup/meta/issue589 so that PRs

Re: [core-workflow] Choosing a code coverage reporter

Codecov was the clear winner among people who left a reaction on the issue and it's also my personal choice, so the code coverage reporter has been chosen! Thanks to everyone who helped out with it. On Tue, 22 Nov 2016 at 12:08 Brett Cannon <br...@python.org> wrote: > I have bot

Re: [core-workflow] Choosing a code coverage reporter

e, 22 Nov 2016 20:08:48 +0000 > Brett Cannon <br...@python.org> wrote: > > I have both Codecov and Coveralls up and running. If you have an > > opinion/preference, please vote at > > https://github.com/brettcannon/cpython-ci-test/issues/27 using the > > reacti

  1   2   >