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

Antoine Pitrou wrote: On Thu, 15 Feb 2018 14:38:39 -0500 Barry Warsaw <ba...@python.org> wrote: Brett Cannon wrote: I would consider a "code health" a more general type for things that are not user-facing. I've generally seen these types of issued labeled "tech debt&quo

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

Brett Cannon wrote: > I would consider a "code health" a more general type for things that are > not user-facing. I've generally seen these types of issued labeled "tech debt". -Barry ___ core-workflow mailing list -- core-workflow@python.org To

[core-workflow] Re: [python-committers] I created the "needs backport to 3.7" label on GitHub

On Jan 31, 2018, at 18:58, Mariatta Wijaya wrote: > > I'm not sure. Maybe the release managers know? There is PEP 101.. I’ll bet Ned is either updating PEP 101 as he goes, or is keeping notes to update that PEP once things calm down. It’s a rare enough event, and

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

On Feb 18, 2017, at 01:38 PM, Steve Dower wrote: >Was there any discussion about allowing core developers to bypass any of the >PR checks? Or was there an assumption that we'd just push directly to the >main repo? I echo Donald's comments. And while this may be something we want to change, it's

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

On Feb 17, 2017, at 03:45 PM, Senthil Kumaran wrote: >On Fri, Feb 17, 2017 at 2:39 PM, Barry Warsaw ><barry-+zn9apsxkcednm+yrof...@public.gmane.org> wrote: >> >> But now I'm stuck and I'm impatient. ;) > >No more. :) Thanks Senthil! And thanks Berker who also

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

On Feb 17, 2017, at 06:24 PM, Donald Stufft wrote: >2) Turn it off, but turn on requiring status checks which will still >effectively require a PR (there is one way around this, but it is so >convoluted nobody would be able to do it by accident, and things still get >tested anyways). I do like

[core-workflow] self-approving pull requests

I submitted PR#138 on bpo-22807. I got a nice review from a community member and made a small change. All checks have passed. But now I'm stuck and I'm impatient. ;) The change is small enough and I'm happy with it, and I could patiently wait for another core dev to approve it, but in the

Re: [core-workflow] codecov.io on PRs feedback

On Feb 16, 2017, at 10:09 AM, Matthias Bussonnier wrote: >Travis CI is doing coverage, and it pushes coverage.xml to codecov.io. >Codecov will "just" aggregate coverage report from different travis-ci matrix >entries to get the complete coverage. You can push coverage to codecov.io >from your

[core-workflow] codecov.io on PRs feedback

Hey cool, I've just submitted my first PR against GH, and it's *so* nice to be able to use git, I might have to do this more often . https://github.com/python/cpython/pull/138 But I have questions about the coverage reports. In bbdef4c, coverage failed because my diff wasn't 100% covered, and

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

On Oct 09, 2016, at 12:43 PM, Nick Coghlan wrote: >It probably makes more sense to assume a successful backport as the >default case We'll have to see. Maybe Python's code won't change so much between major versions, but I've been on projects where refactorings and other changes do result in

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

On Oct 07, 2016, at 11:31 PM, Maciej Szulik wrote: >There's one nit with that cherry-pick, it already creates the commit, and >current description states you should create a commit after running tests >[1]. You can also use cherry-pick -n/--no-commit. Cheers, -Barry pgpKczvGZ8e6Z.pgp

Re: [core-workflow] GitLab 8.11

On Aug 23, 2016, at 01:22 PM, Nick Coghlan wrote: >You noticed that, too, huh? :) Oh yes! Mailman 3 is hosted on GitLab, and I host almost all my personal projects there, so I also get their newsletter. >While the update makes me even more keen to move some of our work projects >away from

[core-workflow] GitLab 8.11

Just FYI, there are some really cool new features in GitLab 8.11 announced today. I haven't played with them yet, but the ones I'm excited about are: * Kanban-like issue boards. Automatically generated from issue labels. * Thru-the-web merge conflict resolution. * Resolve discussions *

Re: [core-workflow] GitHub Workflow

On Mar 17, 2016, at 06:44 PM, Oleg Broytman wrote: >Me too. I have never used squashed merge. But "branchiful" >development has its own troubles like problems with bisect. Only when you don't have a clear main-line-of-development (like git ). But I usually don't squash merges or feature branches

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

On Mar 06, 2016, at 12:27 PM, Nick Coghlan wrote: >The easy way: > >* clone the upstream repo read-only >* add your fork as an additional read/write remote: > * e.g. "git remote add pr " >* work in a branch > * e.g. "git checkout master && git checkout -b issue-summary-of-issue" >* publish

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

On Jan 05, 2016, at 06:03 PM, Brett Cannon wrote: >If people are that worried about others being so adverse to using GitHub that >they won't even do an anonymous clone from their servers then we can get a >Bitbucket or GitLab clone set up Once the migration settles down, I do plan on hooking up

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

On Jan 05, 2016, at 12:42 AM, Brett Cannon wrote: >The way I see it, we have 4 repos to move: devinabox, benchmarks, peps, >devguide, and cpython. Arthur: Each core dev converts four repos... Knight: Five repos Arthur: He who converts the repos four... Knight: Five repos Arthur: Five repos may

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

On Jan 03, 2016, at 03:40 PM, Nick Coghlan wrote: >For the last hosting transition, PEP 374 covered the process of >choosing a distributed VCS, while PEP 385 covered the actual >Subversion -> Mercurial transition, and I think that's a good way to >go. Yes, for the transition tasks, a PEP makes

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

On Dec 15, 2015, at 09:15 AM, Guido van Rossum wrote: >I would hope it would be hosted on GitHub. Getting out of the sysadmin >business is one of my goals here. The two aren't mutually exclusive. For PEP 507, I propose a donated and managed GitLab instance answering to git{,lab}.python.org.

[core-workflow] Questions for GitHub's Director of Community

Over on the committers mailing list, I mentioned that Jono Bacon, a former colleague of mine and former Ubuntu Community Manager is now Director of Community at GitHub. If you have specific questions about GitHub that you think Jono can answer in his official capacity, please send them to me

[core-workflow] PEP 481 repo URL branding

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 a new thread. If PEP 481 is accepted, will we be getting a GitHub enterprise instance that we can run on git{,hub}.python.org, or will we just use

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

On Dec 13, 2015, at 01:55 PM, Christian Heimes wrote: >Merge commits are the single most idiotic feature in GitHub because GitHub >enforces non fast-forward merges. Merge commits bloat and clutter the >revision history with useless junk, e.g.

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

On Dec 11, 2015, at 03:27 AM, Brett Cannon wrote: >Any news from the gitlab CEO about what they will offer and what the plan >is? I'm still aiming to get everything squared away by Dec 15 so I have 2 >weeks to think things through. Brett, see my question from 01-Dec - I think we should still try

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

On Dec 08, 2015, at 12:46 PM, Nick Coghlan wrote: >Something I've been pondering recently is whether we might be able to >"have our cake and eat it too", by setting up the workflow to use >GitHub to facilitate easy contributions by folks with a GitHub account >(and allowing folks that don't want

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

On Dec 02, 2015, at 06:58 PM, Brett Cannon wrote: >Barry has said that GitLab supports runners but you have to run them >yourselves. There are now some shared runners that we can probably use. I haven't had much time to investigate them though. Cheers, -Barry pgpjMH_vaU4G3.pgp Description:

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

On Nov 29, 2015, at 08:08 PM, Guido van Rossum wrote: >What?! I've never worked with a GitHub-based project where you *had* to use >the web-based merge process. All GitLab merge requests have a button that pops up the commands you can copy and paste into your terminal to do a local, manual

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

On Nov 29, 2015, at 11:31 PM, Donald Stufft wrote: >I don’t know about Gitlab, but GitHub exposes PRs as heads in the remote >repository. Yes, GitLab has essentially the same thing. I personally recommend fetching the merge request branch, and then switching to it locally via some name, e.g. $

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

On Mar 19, 2015, at 12:37 AM, Nick Coghlan wrote: In the case of Roundup, the data model is actually very REST friendly, as the existing XML-RPC interface already embodies the collections of resources approach. In theory, it should just be a matter of exposing those collections through an