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

old branches and automatically proposes a forward merge as well. Can you explain what you think the differences are between the multiple systems that affect PRs differently than they affect the other systems that makes it harder? --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE

Re: [core-workflow] the Misc/NEWS problem

> On Aug 6, 2015, at 4:06 PM, Brett Cannon wrote: > > > > On Thu, Aug 6, 2015 at 12:46 PM R. David Murray > wrote: > On Thu, 06 Aug 2015 18:16:53 -, Brett Cannon > wrote: > > > However, having a commit log based generator offers a r

Re: [core-workflow] Software Factory

fo/core-workflow > This list is governed by the PSF Code of Conduct: > https://www.python.org/psf/codeofconduct TBH I really really hate Gerrit. The workflow it enables is fine, but Gerrit itself is horrible. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356

Re: [core-workflow] Software Factory

> On Nov 23, 2015, at 7:50 AM, Victor Stinner wrote: > > 2015-11-23 13:42 GMT+01:00 Donald Stufft : >> TBH I really really hate Gerrit. The workflow it enables is fine, but Gerrit >> itself is horrible. > > This kind of feedback is not really helpful :-/ Can you

Re: [core-workflow] Software Factory

I forgot to do that update. Yes I am going to remove the Phabricator bits. We would also be yet another project on GitHub though it would be trivial to mirror it to git.p.o if we wanted it. Sent from my iPhone > On Nov 25, 2015, at 11:25 AM, Barry Warsaw wrote: > >> On Nov 25, 2015, at 04:17

Re: [core-workflow] Software Factory

heard some rumblings that improvements may be coming. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ core-workflow m

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

te.net/show/77b17a2571f0 <https://bpaste.net/show/77b17a2571f0> Line #14 is the important part. This also makes my local master and develop branch track the upstream repository, while my own branches get pushed to my fork which is the origin remote. - Donald Stufft PGP: 0x6E3C

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

Nick and Barry have hinted that GitLab would host us, listen > to our needs, etc., but it has always seemed to be speculation. Do we have > concrete information as to what GitLab is willing to do for us? - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926

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

that’s available right now. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ core-workflow mailing list core-workflow@python.org https

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

//mail.python.org/mailman/listinfo/core-workflow> > This list is governed by the PSF Code of Conduct: > https://www.python.org/psf/codeofconduct > <https://www.python.org/psf/codeofconduct> > ___ > core-workflow mailing list > core-workflow@python.org > https:

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

tes to run, Travis allows up to 50. https://travis-ci.org/fake-python/cpython/jobs/89432399 ----- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed w

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

> On Dec 2, 2015, at 2:45 PM, R. David Murray wrote: > > On Wed, 02 Dec 2015 14:23:41 -0500, Donald Stufft wrote: >> >>> On Dec 2, 2015, at 2:21 PM, R. David Murray wrote: >>> >>> That's interesting. I thought someone had already tried tra

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

It seems pretty hypocritical to be against GitHub because it's proprietary and hosted by a company that can sell your data (both things I've seen people say against GitHub) and be pro GitLab EE (either hosted by Gitlab or ourselves) or pro using a Hosted Gitlab. I don't personally have a problem

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

I don't think GitHub took any VC money until just recently and they only took VC money after they had been successful, ubiquitous, and profitable. The money was taken to be able to build an enterprise sales team / pipeline for GitHub:FI (Github's self hosted option). Sent from my iPhone > On

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

Reminder that Github existed many years before they took outside investments and they were successful and profitable long before they did. They took investment to expand an already profitable company into enterprise, not to cover expenses while they figured out how to make money. Sent from my

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

> On Dec 13, 2015, at 7:55 AM, Christian Heimes wrote: > > On 2015-12-02 00:32, Donald Stufft wrote: >> >>> On Dec 1, 2015, at 6:24 PM, Brett Cannon wrote: >>> >>> It's Dec 1, which means it's time for any questions people have about the

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

n either > platform. > > On Sun, 13 Dec 2015, 05:39 Donald Stufft <mailto:don...@stufft.io>> wrote: > > > On Dec 13, 2015, at 7:55 AM, Christian Heimes > <mailto:christ...@python.org>> wrote: > > > > On 2015-12-02 00:32, Donald Stufft

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

FF merge without merge commits because there is no longer any record that a merge took place at all. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail

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

> On Dec 14, 2015, at 11:46 AM, Barry Warsaw wrote: > > On Dec 14, 2015, at 11:35 AM, Donald Stufft wrote: > >> You don’t really need the merge commit if you’re doing squash merges > > Just to be clear though, with a GitHub choice, you'd either have to accept >

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

d then maintaining it ourselves. --------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ core-workflow mailing list core-work

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

Only if the review system is used. You still have split brain problems for people merging manually or pushing direct to master. Sent from my iPhone > On Dec 14, 2015, at 10:58 PM, Nick Coghlan wrote: > > going with a bot-based workflow even > means that we could even offer a read-write GitLab

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

It's just github.com. We can do a read only mirror to git.python.org if we would like. Sent from my iPhone > On Dec 15, 2015, at 10:02 AM, Barry Warsaw wrote: > > This isn't described in PEP 481. I think this was briefly mentioned in a > previous message, but I can't find it so I'm starting

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

th a bot that has permissions to just inline edit comments so that the typical syntax gets linked to b.p.o. This won’t work in commit messages or such though. --------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Me

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

irement. 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. > > I'm sure we will want to use some labels and milestones to tra

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

etty easily with git > submodules. They could also use a subtree merge - https://jrsmith3.github.io/merging-a-subdirectory-from-another-repo-via-git-subtree.html ----- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Mess

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

> On Jan 4, 2016, at 10:45 PM, Nick Coghlan wrote: > > On 5 January 2016 at 11:08, Donald Stufft wrote: >> >> On Jan 4, 2016, at 7:42 PM, Brett Cannon wrote: >>> We should try to get test coverage wired up as well per CI. I don't know if >>> cove

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

x27;t need to create and use two separate > accounts. Can we allow (not mandate) login to b.p.o with a GitHub account? That should solve #1 and should sort of solve #3 as well. Ideally it’d allow you to associate a Github account with an existing b.p.o account (and doing so should also automatical

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

> > > If we keep hg.p.o around and updated, we might not have to do this now > (even though now is better than never). > > > This gets us to the bare minimum needed to function. > > > > Parity with hg.python.org <http://hg.python.org/> > > ---

[core-workflow] Octohook (for Python Github Bots)

I just saw this https://github.com/pyupio/octohook and thought it might be useful for CPython’s Github hooks. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail

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

y fork, and I can checkout PRs locally using: $ git checkout pr/N # Checks out the PR as a branch tracking the PR $ git checkout -b whatever upstream/pr/N # checkout out the PR as a a new branch based on the PR. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 63

[core-workflow] New Github Features

clogged up with needless commits from people who don't edit history to keep their PRs clean, however it might lose history from people who do. --------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Mess

Re: [core-workflow] New Github Features

s checks; won't happen until our test > suite is not flaky, though). https://warehouse.python.org/project/towncrier/ <https://warehouse.python.org/project/towncrier/> Might be useful. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C B

Re: [core-workflow] What would it take to split the stdlib out into its own git repo?

> 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 Conduct: > https://www.python.org/psf/codeofconduct — Donald Stufft ___ co

[core-workflow] GitHub New Feature

-github-universe-announcing-new-tools-forums-and-features — Donald Stufft ___ 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 Conduct: https

Re: [core-workflow] CircleCI or Travis?

ed and stuff if we need it is something that *may* be possible. — Donald Stufft ___ 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 Conduct: ht

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

to this called “Projects” as well - https://github.com/blog/2256-a-whole-new-github-universe-announcing-new-tools-forums-and-features <https://github.com/blog/2256-a-whole-new-github-universe-announcing-new-tools-forums-and-features> — Donald Stufft __

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

e project settings and > couldn't find a control for this, but I know other GH projects I contribute to > support self-approval.) > > Cheers, > -Barry > > ___ > core-workflow mailing list > core-workflow@python.org > https://mail.python.org/mailman/listinfo/core-w

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

https://github.com/python/core-workflow/issues/32 might help as well. Sent from my iPhone > On Feb 17, 2017, at 6:32 PM, Barry Warsaw wrote: > > As you say, reviewer bandwidth is a bottleneck (something that I'm personally > going to try to help with now that we're on GH), so at least for now,

Re: [core-workflow] Can core developers bypass PR checks?

y bitrotting and not keeping up with no tooling, changes, and ideas that can make it better. Forcing everyone onto the same process means that as we figure out and continuously improve the process for us, it also improves it for other people who do not have a commit bit. — Donald Stufft

Re: [core-workflow] Can core developers bypass PR checks?

> On Feb 19, 2017, at 6:29 PM, Steve Dower wrote: > > On 19Feb2017 1035, Donald Stufft wrote: >>> >>> On Feb 18, 2017, at 4:38 PM, Steve Dower >> <mailto:steve.do...@python.org>> wrote: >>> >>> (I'm not subscribed to this list,

Re: [core-workflow] Can core developers bypass PR checks?

> On Feb 19, 2017, at 7:01 PM, Steve Dower wrote: > > On 19Feb2017 1554, Donald Stufft wrote: >> We don’t actually have Windows tests being run at all on pull requests >> (largely because AppVeyor took too long to run), though we obviously >> still have the buildbo

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

hat requires reviews and just turn on the thing that requires passing tests. Having been in that situation it has never once bothered me to have someone cherry pick my change and amend it. — Donald Stufft ___ core-workflow mailing list

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

gt; even for core developers" experiment going for at least another few > weeks. I’m happy to switch this around, but I don’t know whose call it is. Does Brett need to make this call? I dunno. — Donald Stufft ___ core-workflow mailing

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

can check the box (which I *believe* is checked by default) to allow maintainers to edit their PR. If that is checked, then maintainers can edit their branch on their fork directly, in which case no credit gets lost. So just make your changes directly in their branch, and things will continue

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

got branch from them. Sent from my iPhone > On Feb 22, 2017, at 2:16 PM, Ethan Furman wrote: > > On 02/22/2017 08:39 AM, Donald Stufft wrote: >>> On Feb 22, 2017, at 11:25 AM, Barry Warsaw wrote: > >>> Since we're squashing commits wouldn't that oblite

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

> On Feb 22, 2017, at 11:17 PM, Nick Coghlan wrote: > > On 23 February 2017 at 02:25, Barry Warsaw wrote: >> On Feb 22, 2017, at 11:10 AM, Donald Stufft wrote: >> >>> FWIW, I don’t think that creating a new PR and closing the original one is a >>

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

You no longer need approval from someone else and you can open a cherry-pick PR prior to merging if you want. Sent from my iPhone > On Mar 2, 2017, at 6:31 PM, Yury Selivanov wrote: > > I feel like a lot of bug fixes will have to be backported. With the > current rules I have to open a new PR

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

One thing I forgot to mention is that cherry picking before a merge might result in more overall work if someone does review your original PR and it ends up causing changes since you'll need to pull those changes into each backport PR too. Sent from my iPhone > On Mar 2, 2017, at 6:44 PM, Yur

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

Correct. Everything goes through a PR now. Ideally we will automate PRs for backports. Sent from my iPhone > On Mar 2, 2017, at 7:00 PM, Yury Selivanov wrote: > > > >> On 2017-03-02 6:36 PM, Donald Stufft wrote: >> You no longer need approval from someone else a

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

I'm on my phone but unless Travis is backed up it sounds like something got lost somewhere. Multi hour waits is not typical. Sent from my iPhone > On Mar 2, 2017, at 7:07 PM, Yury Selivanov wrote: > > Well, I guess my only complaint about this is that Travis is extremely slow. > I've been wa

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

> On Mar 3, 2017, at 5:53 PM, Tres Seaver wrote: > > Travis also throttles organizations with lots of builds. I’m seeing if I can get our default limit increased FWIW. — Donald Stufft ___ core-workflow mailing list core-workflow@p

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

> the appropriate message. > ___ > 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 Conduct: > https://www.python.org/psf/codeof

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

are not high maintenance but it would still be nice to get them off of our infra if possible/reasonable. — Donald Stufft ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is gove

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

What about editing the 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 wrote: > > 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 wa

Re: [core-workflow] travis bottleneck at sprints

ore dev work of course). That way people can review and mark as approved (or even explicit to auto merge) and once tests catch up the bot handles merging it. That would allow people to generally move on once everything but waiting on tests + pressing merge button is done. — Donald Stufft _

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

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 their work. Can we please use a phrase for this that makes more sense rather than, as Alex put it, “magic inside baseball language”. In jokes can be

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

On May 18, 2018, at 1:46 PM, Chris Angelico wrote: > > On Sat, May 19, 2018 at 1:38 AM, Brett Cannon wrote: >> But in the future, please give us the benefit of the doubt. I'm sitting in >> MSP trying to deal with this... > > Sorry for the dumb question... MSP? I'm guessing that's Microsoft some