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

the Docs build process emits, you may be able to dramatically cut down on the false positives without having to interactively update an additional data file. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core

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

l" the default, then the convention could instead be to add "WIP: " to tell Bedevere to skip adding the "Awaiting merge" label. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-w

[core-workflow] Re: Using CLA-assistant for Python

ustom cla-assistant-specific disaster recovery plan. 'tis the beauty and wonder of combining traditional three-tier open source web applications with an automated app management platform like Kubernetes :) Cheers, Nick. P.S. See https://p.datadoghq.com/sb/7dc8b3250-85dcf667bd for the current P

[core-workflow] Re: Using CLA-assistant for Python

gnatories, or else running the PSF's own instance of the service (which may also provide some more freedom in making the check advisory rather than strictly enforced). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ cor

[core-workflow] Re: Label colors

ot; IMO. > "needs backport to " are mostly for the bot most of the time, except when > there's conflict. Aye, that's the kind of breakdown I had in mind when I suggested using muted colours (but didn't express very well). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com |

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

On Tue., 24 Jul. 2018, 5:17 am Carol Willing, wrote: > A couple of years ago, I completely agreed that the labels were > distracting when we were using them on Jupyter. Over time, I found that > they were very helpful for triaging issues and viewing status/next actions > when you have a large

[core-workflow] Re: Improving CLA signing process

On 15 June 2018 at 20:27, Nick Coghlan wrote: > On 15 June 2018 at 11:34, Brett Cannon wrote: > >> ther big issue with bpo as CLA host is we don't have easy way that can >>> let the-knights-who-say-ni update the label in the PR once the contributor >>> has signe

[core-workflow] Re: Improving CLA signing process

ey're the way they are because very few people are showing up to help with improving them. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-workflow mailing list -- core-workflow@python.org To unsubscribe send a

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

ing an approach like that in the dev guide is that none of the current core developers work that way, so we'd have a hard time providing good support to any newcomers that decided to take it up. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia

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

y to the channel after you log in). Cheers, Nick. [1] https://pythondev.slack.com/account/gateways -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-workflow mailing list -- core-workflow@python.org To unsubscribe send an email to core-w

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

s (since not all changes along these lines are going to be about code as such - e.g. syncing up changes to the docs build system). "maintainability", perhaps? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___

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

to mark refactoring changes as "enhancement", but I'm thinking there would be value in making it clear that we don't expect end users to notice a particular change, it's just for the benefit of current and future maintainers. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail

[core-workflow] Adding some concrete examples to the NEWS entry guide?

on to be about deciding whether or not those entries are needed -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-workflow mailing list -- core-workflow@python.org To unsubscribe send an email to core-workflow-le...@py

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

Aye, that's the specific message that makes me roll my eyes and think "Yes, Bedevere, thank you, I already know how that bit of the process works". I think the other message: "please review the changes made to this pull > request" should remain. > Good point, that's a u

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

. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-workflow mailing list -- core-workflow@python.org To unsubscribe send an email to core-workflow-le...@python.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s This list

[core-workflow] Re: Migration of this list to Mailman 3 imminent

een migrated now :) I also created https://github.com/python/core-workflow/issues/200 as a request to start building a checklist for list migrations. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-workflow ma

[core-workflow] Migration of this list to Mailman 3 imminent

-dev, python-ideas, and distutils-sig. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code

Re: [core-workflow] Moving to Buildbot 9 and Python 3

ible deployment of Twisted running Python 3, > and aligns with python.org's direction to move the world to Python 3. :) Very cool! -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-workflow mailing list core-workflow@pytho

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

igger - it just shouldn't be the main documented one). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This

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

On 20 June 2017 at 11:55, Brett Cannon <br...@python.org> wrote: > On Mon, Jun 19, 2017, 18:15 Nick Coghlan, <ncogh...@gmail.com> wrote: >> "Awaiting changes" -> "Awaiting merge": Core dev implements changes > > > They could change their revie

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

quot;Awaiting merge": Core dev implements changes themselves and pushes to submitter's branch Core dev PR -> "Awaiting core review" Core dev PR -> "Awaiting changes" Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___

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

On 19 June 2017 at 02:36, Brett Cannon <br...@python.org> wrote: > 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: >> > >> >

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

lete tangent. I was mainly trying to explain why I think we genuinely need a core developer's review before promoting a PR that far in the process. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-workfl

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

an OpenStack style flow where Bedevere actually *merges* patches in this state if their CI run succeeds, so it wouldn't be reasonable to get here based solely on non-core reviews. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia

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

ag -> PyPI release without any manual intervention (that's how I publish contextlib2 releases these days). Things like the docs theme could then also happily live under core-workflow from a release automation perspective. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com |

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

convey strictly less information than that, since they won't indicate the original PR number or the cherry-picked commit hash. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-workflow mailing list core-workflow@p

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

hat still needs backporting, but nothing changes in the process based on whether or not a maintenance branch PR is a cherry-pick or not. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-workflow mailing list c

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

out how to make it work, I think that plus a status check would be the best option. Failing that, I think a comment would be a bit spammy, unless Bedevere was smart enough not to comment on backport PRs. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Bris

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

y 2 weeks with both approaches when we review the process so we can > make an informed decision. > Thanks, the new setup where Travis is required and codecov is advisory is looking pretty good to me so far (I just accepted a PR with bad codecov stats as the branches it was complaining lacked

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

hiy, since I was importing a patch he wrote), it seems GitHub doesn't actually *show* the Author information anywhere that I can find. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-workflow mailing list core-work

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

thanks again Senthil and Ezio! > > Just an FYI, first version of the extension can be found at > https://github.com/berkerpeksag/cpython-bpo-linkify It's not perfect, > but it does its job for now :) Feel free send bug reports, suggestions > and pull requests. Nice! Cheers, Nic

Re: [core-workflow] Migration is done!

On 11 February 2017 at 00:25, Brett Cannon <br...@python.org> wrote: > A massive thank you to everyone who helped with this. It has been a long > road but we finally reached the end of it! Thanks once again to you and everyone else involved! Cheers, Nick. -- Nick Coghlan

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

On 9 February 2017 at 19:35, Brett Cannon <br...@python.org> wrote: > On Thu, 9 Feb 2017 at 10:15 Nick Coghlan <ncogh...@gmail.com> wrote: >> That's actually the way hg.python.org injects the links now: >> https://hg.python.org/cpython/rev/b07d454e45a2 >&g

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

On 9 February 2017 at 18:59, Zachary Ware <zachary.ware+py...@gmail.com> wrote: > On Thu, Feb 9, 2017 at 11:52 AM, Nick Coghlan <ncogh...@gmail.com> wrote: >> You can't readily do that with "#12345" or even "Issue #12345" because >> they're too gene

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

utomated conversion into a hyperlink via a client side script in GreaseMonkey or similar. You can't readily do that with "#12345" or even "Issue #12345" because they're too generic. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___

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

tthias). For what it's worth, NAME-12345 is the way JIRA handles autolinking of references, since it assumes the JIRA instance is specific to a particular organisation and lets you specify short prefix codes for the projects. One benefit of a hyphen based syntax would be reducing the temptatio

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

mmit hook that looks for the "#12345" and actively disallows it? (akin to the one that handles the whitespace check locally) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-workflow mailing list cor

Re: [core-workflow] New core-workflow issue tracker

ctually planned. Makes sense to me. If you're so inclined, you may also want to take a look at https://waffle.io/ as a possible way of visualising work in progress. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-w

Re: [core-workflow] Getting help w/ testing Travis and CircleCI

entire compile-and-test aspect can be skipped, since it's just a docs change. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/li

Re: [core-workflow] instructions for cherrypicking a change from master

cover with "git commit --amend") Recommending "--no-commit" as the default makes the first flow longer by adding a separate commit step without actually simplifying the others. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia __

Re: [core-workflow] The peps repo has been migrated!

since it will eliminate the "copy to hg.python.org" step. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/cor

[core-workflow] Reviewing/updating the README for GitHub migration?

though we already have the developer guide :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list

Re: [core-workflow] New Github Features

erging, rebasing, squashing, or some combination thereof) There's still value in a "check" CI run to see whether a patch is even worth trying to commit, but it's a separate activity from actually gating commits on the test suite passing. Cheers, Nick. -- Nick Coghlan | ncogh..

Re: [core-workflow] Spelling out a suggested local workflow for sending PRs?

On 7 March 2016 at 19:13, Nick Coghlan <ncogh...@gmail.com> wrote: > The audience here is folks that don't already have a preferred > workflow for interesting with GitHub repos, s/interesting/interacting/ :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisban

[core-workflow] Presentation on Rust's GitHub based automation tools

nance load with Mozilla rather than going for a completely custom setup. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow

Re: [core-workflow] Updated draft of PEP 512

the VCS info at least get a really clear indicator when we change version control systems, even if they're not closely following upstream process changes. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-workflow m

Re: [core-workflow] PEP 512: migrating hg.python.org to GitHub

get into the habit of pasting the resulting commit into the PR when it > gets closed. It also falls into the category of problem that a workflow bot addresses - it just becomes a requirement for the bot to comment on and close the original PR with a reference to the commit,

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

se as a requirement. It should probably implement > a commit queue like Zuul or Homu (and both of those can be considered as the > basis of the bot). Also gating commits on passing a test run probably would > also be good. Something else worth considering

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

ff to find the lines affected by a patch and specifically looks up *those lines* in a coverage report, so it can ensure that any lines changed by a patch are covered by the regression test suite. It appears to be a neat way of guiding a code base towards more comprehensive test coverage. Cheer

Re: [core-workflow] Standard library separation from core (was Re: My initial thoughts on the steps/blockers of the transition)

and only drop support for those old versions when the Linux vendors do). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo

Re: [core-workflow] We will be moving to GitHub

can't find any examples of direct integration of Rietveld with GitHub, so that would presumably require setting up some webhooks, similar to what Eric described doing for Reviewboard. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia __

Re: [core-workflow] Longer term idea: consider Rust's homu for CPython merge gating

penStack use to identify intermittent failures based on patterns detected in log files: http://docs.openstack.org/infra/elastic-recheck/readme.html#idea Relevant dashboard for the OpenStack integrated release gate: http://status.openstack.org/elastic-recheck/ -- Nick Coghlan | ncogh...@gmail.com

Re: [core-workflow] Longer term idea: consider Rust's homu for CPython merge gating

ction in a CPU failing - you have to flush the pipeline and start over again from the point of the failure. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-workflow mailing list core-workflow@python.org https://mai

Re: [core-workflow] We will be moving to GitHub

ing Author/Committer data for old commits), which aren't generally relevant to future contributors (so don't belong in the developer guide), but also weren't part of the repository hosting decision making process (so don't really belong in PEP 507). Cheers, Nick. -- Nick Coghlan | ncogh...@gma

Re: [core-workflow] We will be moving to GitHub

On 2 Jan 2016 07:37, "R. David Murray" wrote: > > On Fri, 01 Jan 2016 20:25:11 +, Stefan Krah < skrah.temporar...@gmail.com> wrote: > > Brett Cannon writes: > > > I don't think this will be a shock to anyone who has followed the > > discussion on this list.

[core-workflow] Longer term idea: consider Rust's homu for CPython merge gating

ck. [1] http://graydon2.dreamwidth.org/1597.html [2] http://huonw.github.io/blog/2015/03/rust-infrastructure-can-be-your-infrastructure/ -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-workflow mailing list core-w

Re: [core-workflow] PEP 481 repo URL branding

ardless of what else happens with the development workflow. The idea also raises the question of how long we preserve hg.python.org/cpython as a read-only Mercurial mirror of the new git repo. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia __

Re: [core-workflow] Questions about the proposed workflows

specific web interface in use - if it was set up, any such mirror repo would be read/write from a "you can submit and work with change requests here", rather than "you can use git to push updates here". Cheers, Nick. > > Sent from my iPhone > >> On Dec 14, 2

Re: [core-workflow] Questions about the proposed workflows

sonable" in various contexts to suspect that an anonymous survey (that is still somehow restricted to core developers) would be the only way to get an even halfway accurate assessment. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _

Re: [core-workflow] Questions about the proposed workflows

akin to the PR->MR component of github2gitlab to create and update MRs based on GitHub PRs Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-workflow mailing list core-workflow@python.org https://mail

Re: [core-workflow] Other thoughts on the workflow

l. (I had a quick look through some of the command line clients listed at https://about.gitlab.com/applications/, but didn't see anything as workflow focused as git-pulls or hub, so "good support for terminal based usage" may count as a concrete technical differentiator here) Cheers, Nic

Re: [core-workflow] Other thoughts on the workflow

gh the review process: http://doc.gitlab.com/ce/workflow/protected_branches.html Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/l

Re: [core-workflow] Testing out proposed new workflows

On 5 August 2015 at 22:05, Nick Coghlan ncogh...@gmail.com wrote: On 5 August 2015 at 08:26, Brett Cannon bcan...@gmail.com wrote: Nick and Donald, do you think you can have such a test setup up and running by October 31 (Halloween, 88 days away)? I'm planning to use Kallithea as my guinea

Re: [core-workflow] Starting the improved workflow discussion again

weekend, and then the weekend after I'm off to the US for a couple of weeks to attend Fedora's Flock conference and PyGotham. I can at least get the PEP 474 update done before I leave for the US, though, and I can include some of these ideas in there as possible future work. Cheers, Nick. -- Nick

Re: [core-workflow] GSoC idea: bug.python.org improvements

On 22 March 2015 at 14:11, Ezio Melotti ezio.melo...@gmail.com wrote: On Sat, Mar 21, 2015 at 9:33 PM, R. David Murray rdmur...@bitdance.com wrote: On Sat, 21 Mar 2015 23:13:13 +1000, Nick Coghlan ncogh...@gmail.com wrote: I don't think we've discussed it anywhere yet (unless I mentioned

Re: [core-workflow] bugs.python.org-related GSoC project

On 17 March 2015 at 01:36, Barry Warsaw ba...@python.org wrote: On Mar 16, 2015, at 09:52 PM, Nick Coghlan wrote: I've found one neat trick for this kind of scenario is to devise standalone projects that are likely to be useful regardless of what happens in the broader context. REST-API

Re: [core-workflow] bugs.python.org-related GSoC project

is concerned. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code

Re: [core-workflow] PEP awareness statistics

As Anatoly has chosen to ignore my request that he refrain from participating in this group, I am now unsubscribing from this list. As he has not specifically misbehaved here, there are no grounds to ban him from it. However, I refuse to work with someone that has repeatedly demonstrated such a

Re: [core-workflow] Adding a requires C keyword?

On 4 Aug 2014 09:37, Ezio Melotti ezio.melo...@gmail.com wrote: Hi, On Sun, Aug 3, 2014 at 4:23 PM, Nick Coghlan ncogh...@gmail.com wrote: Chatting to an experienced C/C++ developer at PyCon AU today, they were worried that their *Python* skills might not be good enough to contribute

Re: [core-workflow] Tracker workflow proposal

On 9 May 2014 04:32, Carol Willing willi...@willingconsulting.com wrote: and decision needed means someone higher up has to make a call on a question. My apologies in advance if my ability to communicate in writing my next point is below par. Before I say what I am feeling, I want to be clear

Re: [core-workflow] Tracker workflow proposal

On 8 May 2014 01:59, R. David Murray rdmur...@bitdance.com wrote: On Wed, 07 May 2014 08:09:03 -0700, Carol Willing willi...@willingconsulting.com wrote: I'm wondering if decision needed might be more accurately named triage needed? Looking at David's well documented proposals and other