Re: [Python-Dev] How is the GitHub workflow working for people?

[Giampaolo Rodola']

I personally use a GIT commit hook which runs flake8 against the *modified
py files only* and rejects the commit in case of non-compliance:
https://github.com/giampaolo/psutil/blob/master/.git-pre-commit
...I install it via make:
https://github.com/giampaolo/psutil/blob/ad4acae5489f86fc3bef645505b3873f156b4867/Makefile#L186
...and once the whole code base is in a good shape have Travis run flake8
against the whole code base on each commit.

When I join an existing project I try to enforce the same workflow and rely
on pep8ify (https://github.com/spulec/pep8ify) to adjust the existing code.
In order to not be too "strict" I may modify the GIT hook to emit a warning
instead of rejecting the commit.

On one hand I think it would be great to do the same for cPython. On the
other hand I see 2 big downsides:

- losing "git blame" history for A LOT of lines of code
- even if you're familiar with PEP8 it's sometimes hard to spot
non-compliant lines unless you integrate flake8 into your IDE (I do for
Sublime); putting such a constraint on contributing users is probably too
much and may discourage contributions.


On Sun, Feb 25, 2018 at 6:13 AM, Guido van Rossum  wrote:

> It's easy to only analyze the files in the diff (these linters don't do
> cross-file analysis anyways, typically) and it's possible to write a filter
> that only keeps warnings about lines that are changed, but I don't know of
> a standard solution for the latter (places where I worked where I've seen
> this always had their own custom implementation).
>
> On Sat, Feb 24, 2018 at 7:35 PM, Mariatta Wijaya <
> mariatta.wij...@gmail.com> wrote:
>
>> Can any of these said linters analyze only the diff in the PR, instead of
>> the entire CPython codebase?
>>
>> Mariatta Wijaya
>>
>> ᐧ
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%
>> 40python.org
>>
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/g.
> rodola%40gmail.com
>
>


-- 
Giampaolo - http://grodola.blogspot.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Guido van Rossum]

It's easy to only analyze the files in the diff (these linters don't do
cross-file analysis anyways, typically) and it's possible to write a filter
that only keeps warnings about lines that are changed, but I don't know of
a standard solution for the latter (places where I worked where I've seen
this always had their own custom implementation).

On Sat, Feb 24, 2018 at 7:35 PM, Mariatta Wijaya 
wrote:

> Can any of these said linters analyze only the diff in the PR, instead of
> the entire CPython codebase?
>
> Mariatta Wijaya
>
> ᐧ
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Mariatta Wijaya]

Can any of these said linters analyze only the diff in the PR, instead of
the entire CPython codebase?

Mariatta Wijaya

ᐧ
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Nick Coghlan]

On 24 February 2018 at 16:45, Barry Warsaw  wrote:

> On Feb 21, 2018, at 19:03, Dan Stromberg  wrote:
> >
> > Is flake8 that much better than pylint, that pylint wouldn't even be
> discussed?
>
> I honestly don’t use pylint all that much these days, but when I was
> evaluating them years ago, I found pylint to be too noisy about
> not-incorrect code.  I also liked how flake8 has a very nice plugin system,
> and I use that on my personal projects to enforce a consistent style.  It’s
> certainly possible that both tools have advanced significantly since I last
> made my personal decision.
>

When I recommend pylint, I try to make it clear that the command I
personally recommend is `pylint -E`, as that's the level that automates
checking for outright bugs (name errors, attribute errors, etc), as well as
effectively checking for clever dynamic variable and attribute injection
code that is likely to confuse human readers in addition to confusing
static analysers.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Barry Warsaw]

On Feb 22, 2018, at 09:09, Eric Snow  wrote:
> 
> I had exactly that experience on one particularly large Go project (on
> GitHub, with slow CI, driven by bots).

One thing that’s nice to set up if you can is multiple, parallel, independent 
CI runs.  E.g. if your full test suite takes a long time to run, but you can 
run your code style tests pretty quickly (e.g. flake8 and mypy), then you can 
get more immediate feedback about your PR code style, and it’s not so painful 
if your test suite is slow.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Barry Warsaw]

> On Feb 22, 2018, at 08:08, Antoine Pitrou  wrote:
> 
> That's a fair point I hadn't considered.  OTOH the style issues I
> usually comment on as a reviewer aren't the kind that would be caught
> by an automated style check (I tend to ask for comments or docstrings,
> or be nitpicky about some variable or function name).  YMMV :-)

Those are aesthetic comments that are important, and are also difficult to 
automate.  What I really don’t want to comment on are things like whitespace 
(vertical, horizontal, trailing), import order or format, consistent 
indentation, etc.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Barry Warsaw]

On Feb 22, 2018, at 02:12, Antoine Pitrou  wrote:

> Everytime I contribute to a project which has automatic style checks in
> CI, I find myself having to push pointless "cleanup" commits because
> the CI is barking at me for some ridiculous reason (such as putting two
> linefeeds instead of one between two Python functions).  Then I have to
> wait some more until CI finishes, especially if builds take long or
> build queues are clogged.
> 
> Overall it makes contributing more of a PITA than it needs be.  Do
> automatic style *fixes* if you want, but please don't annoy me with
> automatic style checks that ask me to do tedious grunt work on my spare
> time.

Look at it from the other side though.  If I’m reviewing someone’s PR, and the 
style is so inconsistent with the existing code base, then I’m distracted by 
constantly asking the contributor to clean up little stylistic things.  This 
wastes my time as a reviewer, where I’d rather be thinking about the 
substantive content of the change.  To have no style checks can leave you with 
a chaotic jumbled ness that is much harder to navigate around, understand, and 
contribute to by others, and once you’ve gone down that path, you just build up 
technical debt to eventually try to clean it up.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Barry Warsaw]

On Feb 21, 2018, at 19:03, Dan Stromberg  wrote:
> 
> Is flake8 that much better than pylint, that pylint wouldn't even be 
> discussed?

I honestly don’t use pylint all that much these days, but when I was evaluating 
them years ago, I found pylint to be too noisy about not-incorrect code.  I 
also liked how flake8 has a very nice plugin system, and I use that on my 
personal projects to enforce a consistent style.  It’s certainly possible that 
both tools have advanced significantly since I last made my personal decision.

I agree with Guido in general though, that we’d need to do some actual analysis 
on the stdlib and see what the results are.  I do think that a plugin system, 
or really good configurability, will help us tailor whatever tool we decide to 
use, so that it’s only warning about the things we care about and ignoring the 
rest, without requiring lots of comment pragmas in the code.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Oleg Broytman]

On Fri, Feb 23, 2018 at 08:12:13AM -0500, Wes Turner  
wrote:
> A pre-commit hook with flake8

   The problem now is not how to configure git with flake8 (et al) but
how to configure flake8 (and other tools) to minimize the noise with the
current codebase.

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Wes Turner]

On Wednesday, February 21, 2018, Nick Coghlan  wrote:

> On 22 February 2018 at 08:19, Barry Warsaw  wrote:
> > As for the bug tracker, I still do like Roundup, and we have a huge
> investment in it, not just in resources expended to make it rock, but also
> in all the history in it and everything that integrates with it.  I
> wouldn’t stop anybody who’s motivated to spearhead a move to GH issues, but
> I also don’t think that can be taken up lightly.
>
> [...]
>

> Personally, the only things I really miss on Roundup vs GitHub issues
> are usability tweaks like Markdown support in the comment editor, and
> inline dropdowns for @-mentions of other users and #-mentions of other
> issues, so if someone is motivated to work on issue tracking
> enhancements, that seems like a more fruitful endeavour than trying to
> migrate wholesale to a proprietary third party service.


Additional Roundup ENHancements:

- [ ] ENH: Issue mention 'trackbacks'
  Optionally quoting the full issue title inline instead of just #123 would
be great: "#123: Issue title"

- [ ] ENH: GitHub OAuth integration; to make it easy to login to Roundup
with GitHub credentials

  http://python-social-auth.readthedocs.io/en/latest/backends/github.html


>
> Cheers,
> Nick.
>
> P.S. That said, one tracker that I think absolutely *would* be worth
> migrating to GitHub is the meta-tracker at
> http://psf.upfronthosting.co.za/roundup/meta. We haven't customised
> that instance the way we have bugs.python.org, and consolidating it
> and the source repo at http://hg.python.org/tracker/roundup/ into a
> single https://github.com/python/bugs.python.org repo would better
> align tracker development with development on other parts of the
> infrastructure.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> wes.turner%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Wes Turner]

On Friday, February 23, 2018, Nick Coghlan  wrote:

> On 23 February 2018 at 03:09, Eric Snow 
> wrote:
> > So, coupled with slow CI, linting failures were
> > particularly onerous.  We all got in the habit of locally running the
> > linter frequently.  IIRC, I even set up VIM to run the linter whenever
> > I saved.
>
> For reindent.py, we used to have instructions for setting that up as a
> local pre-commit hook in Mercurial. It may make sense to create
> similar instructions for git (if we don't already have those
> somewhere).


A pre-commit hook with flake8, clang-format, and the requisite CPython
style configs would be great.

https://git-scm.com/book/gr/v2/Customizing-Git-Git-Hooks

Batch and ad-hoc CLN commits to cleanup for style really muddle the git
blame history.


>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> wes.turner%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Nick Coghlan]

On 23 February 2018 at 03:09, Eric Snow  wrote:
> So, coupled with slow CI, linting failures were
> particularly onerous.  We all got in the habit of locally running the
> linter frequently.  IIRC, I even set up VIM to run the linter whenever
> I saved.

For reindent.py, we used to have instructions for setting that up as a
local pre-commit hook in Mercurial. It may make sense to create
similar instructions for git (if we don't already have those
somewhere).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Gregory P. Smith]

On Tue, Feb 20, 2018 at 6:50 PM Brett Cannon  wrote:

> It's been a year and 10 days since we moved to GitHub, so I figured now is
> as good a time as any to ask people if they are generally happy with the
> workflow and if there is a particular sticking point to please bring it up
> on the core-workflow mailing list so we can potentially address it.
>

+1 happy!  Especially with the amazing automation piled on top.

It makes it sooo much easier to deal with changes coming from people than
anything involving manual patch files and clients.  Even within github's
quite limited concept of a code review tool (from a Googler perspective).

I do feel like we need more CI resources during sprints.  But we always
need more everything resources during sprints so that is nothing new and
not related to github itself.

The move to our github workflow is a win for all Python users in the world.

-gps
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Gregory P. Smith]

How often do we find ourselves grumbling over .py file style in PRs on
github?  If the answer to that isn't very often, the rest of my response
below seems moot. :)

On Wed, Feb 21, 2018 at 7:30 PM Guido van Rossum  wrote:

> Where I work we have some teams using flake8 and some teams that use
> pylint, and while pylint is more thorough, it is also slower and pickier,
> and the general sense is to strongly prefer flake8.
>
> I honestly expect that running either with close-to-default flags on
> stdlib code would be a nightmare, and I wouldn't want *any* directives for
> either one to appear in stdlib code, ever.
>
> In some ideal future all code would just be reformatted before it's
> checked in -- we're very far from that, and I used to be horrified by the
> very idea, but in the Go world this is pretty much standard practice, and
> the people at work who are using it are loving it. So I'm trying to have an
> open mind about this. But there simply isn't a tool that does a good enough
> job of this.
>

I don't know the specifics of your idea of "a good enough job of this" for
an auto-formatter is (we'd need to settle on that definition in a PEP)..
but there is for my definition: yapf .

Many teams require it pre-check-in for their code at Google these days. We
also use it for auto-reformatting of surrounding lines of code during all
sorts of mass-refactorings.  IIRC Lukas said Instagram/Facebook adopted it
as standard practice as well.

Some teams go all the way to enforce a "yapf must suggest no changes to the
edited areas of .py files" pre-submit error on their projects.

As Eric (and I believe Lukas in the past) has mentioned: auto formatters
don't have to produce mythical(*) "perfect" style the way individuals might
choose - they need to be good enough to keep people from arguing about
style with one another.  That's the productivity and consistency win.

What we need now is not more opinions on which formatter or linter is best.
> We need someone to actually do some work and estimate how much code would
> be changed if we ran e.g. tabnanny.py (or something more advanced!) over
> the entire stdlib, how much code would break (even the most conservative
> formatter sometimes breaks code that wasn't expecting to be reformatted --
> e.g. we used to have tests with significant trailing whitespace), and how
> often the result would be just too ugly to look at. If you're not willing
> to work on that, please don't respond to this thread.
>

Indeed.  There are at *least* four Python style and gotcha checkers in wide
use for Python code out there today.  Prematurely picking one up front
rather than coming up for criteria of which limited set of things we would
want and could practically use on the stdlib + testsuite seems wrong.

I've added "run yapf on all of CPython's .py files" to my list of things to
explore (or encourage someone else to) some day...

-gps

(*) caveat: Given that Guido has obtained History status
 and is BDFL he
can define mythical perfect style
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Eric Snow]

On Thu, Feb 22, 2018 at 9:30 AM, Paul Moore  wrote:
> My experience on pip is that automated style review is helpful for
> avoiding debates over subjective details.

This is the allure of Go's official linting tools.  Nobody is happy
with *all* the style choices but there isn't any room to fuss about it
so people don't.  Without that overhead, folks are more apt to lint
their changes.  (At least, that was my experience after several years
working on projects written in Go.)  One nice thing is that it frees
you up to argue about other things. :)

> But it does result in a
> certain level of "tweak to satisfy the style checker" churn in PRs.
> That can be frustrating when CI takes a long time to run.

I had exactly that experience on one particularly large Go project (on
GitHub, with slow CI, driven by bots).  To make matters worse, the
project had a dozen people actively working on it, meaning a high
potential that your PR would not apply cleanly if you took too long to
merge it.  So, coupled with slow CI, linting failures were
particularly onerous.  We all got in the habit of locally running the
linter frequently.  IIRC, I even set up VIM to run the linter whenever
I saved.

FWIW, I'm fine with a bot that leaves a message (or a review) if there
are linting issues.  Regardless, we should careful about adding any
extra overhead to our workflow, particularly since the move to GH has
been driven by the desire to reduce overhead.

-eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Paul Moore]

On 22 February 2018 at 16:08, Antoine Pitrou  wrote:
> On Thu, 22 Feb 2018 07:51:17 -0800
> Steve Dower  wrote:
>> It then becomes grunt work for reviewers, who also have to carefully balance 
>> encouraging new contributors against preventing the code base from getting 
>> worse.
>
> That's a fair point I hadn't considered.  OTOH the style issues I
> usually comment on as a reviewer aren't the kind that would be caught
> by an automated style check (I tend to ask for comments or docstrings,
> or be nitpicky about some variable or function name).  YMMV :-)
>
>> I’d rather have a review bot that can detect problems in PRs and comment on 
>> them. We can choose to merge anyway and it won’t keep being noisy, but it 
>> also saves committers from potentially telling someone their contribution 
>> isn’t welcome because of their camelCase.
>
> Yeah, that sounds like an interesting feature.

My experience on pip is that automated style review is helpful for
avoiding debates over subjective details. But it does result in a
certain level of "tweak to satisfy the style checker" churn in PRs.
That can be frustrating when CI takes a long time to run.

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Antoine Pitrou]

On Thu, 22 Feb 2018 07:51:17 -0800
Steve Dower  wrote:
> It then becomes grunt work for reviewers, who also have to carefully balance 
> encouraging new contributors against preventing the code base from getting 
> worse.

That's a fair point I hadn't considered.  OTOH the style issues I
usually comment on as a reviewer aren't the kind that would be caught
by an automated style check (I tend to ask for comments or docstrings,
or be nitpicky about some variable or function name).  YMMV :-)

> I’d rather have a review bot that can detect problems in PRs and comment on 
> them. We can choose to merge anyway and it won’t keep being noisy, but it 
> also saves committers from potentially telling someone their contribution 
> isn’t welcome because of their camelCase.

Yeah, that sounds like an interesting feature.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Steve Dower]

It then becomes grunt work for reviewers, who also have to carefully balance 
encouraging new contributors against preventing the code base from getting 
worse.

I’d rather have a review bot that can detect problems in PRs and comment on 
them. We can choose to merge anyway and it won’t keep being noisy, but it also 
saves committers from potentially telling someone their contribution isn’t 
welcome because of their camelCase. (Maybe Mariatta’s tutorial will build this 
bot? Maybe I’ll go and learn how to do it myself :) )

(and here ends my contribution on this topic. Pretty sure we're firmly in 
core-workflow territory now.)

Top-posted from my Windows phone

From: Ethan Furman
Sent: Thursday, February 22, 2018 7:39
To: python-dev@python.org
Subject: Re: [Python-Dev] How is the GitHub workflow working for people?

On 02/22/2018 02:12 AM, Antoine Pitrou wrote:

> Overall it makes contributing more of a PITA than it needs be.  Do
> automatic style *fixes* if you want, but please don't annoy me with
> automatic style checks that ask me to do tedious grunt work on my spare
> time.

+1

--
~Ethan~

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/steve.dower%40python.org

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Ethan Furman]

On 02/22/2018 02:12 AM, Antoine Pitrou wrote:


Overall it makes contributing more of a PITA than it needs be.  Do
automatic style *fixes* if you want, but please don't annoy me with
automatic style checks that ask me to do tedious grunt work on my spare
time.


+1

--
~Ethan~

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Antoine Pitrou]

On Wed, 21 Feb 2018 14:19:54 -0800
Barry Warsaw  wrote:
> On Feb 21, 2018, at 13:22, Guido van Rossum  wrote:
> > 
> > I'm willing to reconsider if there's a good enough tool. Ditto for C code 
> > (or do we already do it for C?).  
> 
> For Python code, flake8 --possibly with our own custom plugins— is the way to 
> go.  It would probably take some kind of ratchet or transition period before 
> all of the stdlib were compliant.  We’d have to be careful of the inevitable 
> raft of PRs to fix things, which may distract from actual bug fixes and 
> improvements.  OTOH, that would be another external dependency pulled in for 
> core Python development.

Everytime I contribute to a project which has automatic style checks in
CI, I find myself having to push pointless "cleanup" commits because
the CI is barking at me for some ridiculous reason (such as putting two
linefeeds instead of one between two Python functions).  Then I have to
wait some more until CI finishes, especially if builds take long or
build queues are clogged.

Overall it makes contributing more of a PITA than it needs be.  Do
automatic style *fixes* if you want, but please don't annoy me with
automatic style checks that ask me to do tedious grunt work on my spare
time.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Abdur-Rahmaan Janhangeer]

>FWIW I'm personally hugely happy with
>the new workflow -- my only regret is
>that we're not using GitHub for issue
>tracking yet.

Btw you can create your own issue labels. some pythonic names can be
considered

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

On 22 Feb 2018 01:23, "Guido van Rossum"  wrote:

...
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Benjamin Peterson]

On Wed, Feb 21, 2018, at 13:22, Guido van Rossum wrote:
> On Wed, Feb 21, 2018 at 9:53 AM, Brett Cannon  wrote:
> 
> >
> >
> > On Wed, 21 Feb 2018 at 09:30 Yury Selivanov 
> > wrote:
> >
> >> FWIW I'm extremely happy with the current workflow. The recent
> >> improvements to @miss-islington (kudos to Mariatta!) allowing her to
> >> auto-backport PRs and commit them is a big time saver.
> >>
> >> I can only suggest a couple improvements:
> >>
> >> 1. Make our bots check the code style—fully enforce PEP 8, lint the
> >> code, and detect trailing whitespace on all lines that a PR modifies.
> >>
> >
> > Guido said "no" to this from the outset.
> >
> 
> I'm willing to reconsider if there's a good enough tool. Ditto for C code
> (or do we already do it for C?).

The C/C++ world has very good tooling for formating in the form of 
clang-format. If someone made a clang-format configuration file close to the 
current PEP 7 guide and existing code, I would support running it over the 
entire codbase and enforcing formatting in CI. Massive reformatings of CPython 
C have actually already uneventfully happened: several years ago Antoine 
removed all tabs from C sources.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Yury Selivanov]

On Wed, Feb 21, 2018 at 10:27 PM, Guido van Rossum  wrote:
[..]
> I honestly expect that running either with close-to-default flags on stdlib
> code would be a nightmare, and I wouldn't want *any* directives for either
> one to appear in stdlib code, ever.

It would be great to enable the linter on a per-module basis then.
For instance, I believe that all files in asyncio package pass flake8
with default flags (at least I'm doing my best to keep it that way).
Sometimes it takes an extra review round to fix the code style, having
the CI to enforce it would save time for everybody.

Something similar to "cpython/.github/CODEOWNERS" but for enabling
linters would work.

Yury
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Nick Coghlan]

On 22 February 2018 at 13:27, Guido van Rossum  wrote:
> What we need now is not more opinions on which formatter or linter is best.
> We need someone to actually do some work and estimate how much code would be
> changed if we ran e.g. tabnanny.py (or something more advanced!) over the
> entire stdlib, how much code would break (even the most conservative
> formatter sometimes breaks code that wasn't expecting to be reformatted --
> e.g. we used to have tests with significant trailing whitespace), and how
> often the result would be just too ugly to look at.

I believe we still run Tools/scripts/reindent.py and
Tools/scripts/reindent-rst.py as pre-merge checks. (I actually thought
we add a reindent-c.py script as well, since Py3 switched all the C
code over to using spaces for indentation to match the Python
conventions, but it appears not).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Nick Coghlan]

On 22 February 2018 at 13:03, Dan Stromberg  wrote:
> On Wed, Feb 21, 2018 at 2:19 PM, Barry Warsaw  wrote:
>> On Feb 21, 2018, at 13:22, Guido van Rossum  wrote:
>>>
>>> I'm willing to reconsider if there's a good enough tool. Ditto for C code 
>>> (or do we already do it for C?).
>>
>> For Python code, flake8 --possibly with our own custom plugins— is the way 
>> to go.
>
> Is flake8 that much better than pylint, that pylint wouldn't even be 
> discussed?
>
> pylint does warn about some relatively unimportant things out of the
> box, but it can be configured to ignore (almost?) everything it
> checks.

"pylint -E" is my own preferred IDE-level checker (since it's pretty
good about reserving the "Error" category for things that almost
certainly indicate bugs), but all of these tools share a common
problem when applied to CPython: we routinely break them :)

Part of that is permanent breakage in the test suite where we
deliberately test the compiler and interpreter's reaction to invalid
code, while the other part is transient breakage when we introduce new
syntax and other language level constructs.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Guido van Rossum]

Where I work we have some teams using flake8 and some teams that use
pylint, and while pylint is more thorough, it is also slower and pickier,
and the general sense is to strongly prefer flake8.

I honestly expect that running either with close-to-default flags on stdlib
code would be a nightmare, and I wouldn't want *any* directives for either
one to appear in stdlib code, ever.

In some ideal future all code would just be reformatted before it's checked
in -- we're very far from that, and I used to be horrified by the very
idea, but in the Go world this is pretty much standard practice, and the
people at work who are using it are loving it. So I'm trying to have an
open mind about this. But there simply isn't a tool that does a good enough
job of this.

What I was thinking of was a much weaker option like tabnanny.py by Tim
Peters (still in the stdlib!), but I don't know whether this is feasible.

What we need now is not more opinions on which formatter or linter is best.
We need someone to actually do some work and estimate how much code would
be changed if we ran e.g. tabnanny.py (or something more advanced!) over
the entire stdlib, how much code would break (even the most conservative
formatter sometimes breaks code that wasn't expecting to be reformatted --
e.g. we used to have tests with significant trailing whitespace), and how
often the result would be just too ugly to look at. If you're not willing
to work on that, please don't respond to this thread.

--Guido

On Wed, Feb 21, 2018 at 7:03 PM, Dan Stromberg  wrote:

> On Wed, Feb 21, 2018 at 2:19 PM, Barry Warsaw  wrote:
> > On Feb 21, 2018, at 13:22, Guido van Rossum  wrote:
> >>
> >> I'm willing to reconsider if there's a good enough tool. Ditto for C
> code (or do we already do it for C?).
> >
> > For Python code, flake8 --possibly with our own custom plugins— is the
> way to go.
>
> Is flake8 that much better than pylint, that pylint wouldn't even be
> discussed?
>
> pylint does warn about some relatively unimportant things out of the
> box, but it can be configured to ignore (almost?) everything it
> checks.
>
> I've been editing Python code in vim with syntastic.  I have syntastic
> set up to run pyflakes, pycodestyle and pydocstyle.  And I have a
> macro that saves the buffer, shells out and runs "make" with the
> default rule - and that default rule almost always does a
> whole-program pylint.
>
> It's possible to make pylint check just one file from syntastic, but I
> don't do that because it's too slow on large files.
>
> I've gotten the impression that pylint can detect some errors that
> pyflakes misses.  Not sure about flake8.
>
> I do like it that flake8 has a mccabe check.  pylint doesn't appear to
> have that, and instead relies on things like "too many statements",
> "too many branches" and "too many variables".
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Nick Coghlan]

On 22 February 2018 at 08:19, Barry Warsaw  wrote:
> As for the bug tracker, I still do like Roundup, and we have a huge 
> investment in it, not just in resources expended to make it rock, but also in 
> all the history in it and everything that integrates with it.  I wouldn’t 
> stop anybody who’s motivated to spearhead a move to GH issues, but I also 
> don’t think that can be taken up lightly.

There are also several additional challenges with migrating the issue
tracker that didn't impact the code migration (at least, not as
badly):

* Issue number preservation: because the previous issue tracker
migration was from SourceForge to self-hosted, the SourceForge issue
numbers could be injected directly into Roundup. As far as I know, we
wouldn't be able to do that for a migration into GitHub - all existing
issues would be arbitrarily renumbered. (The most viable solution to
this would probably be to continue running a redirector on
bugs.python.org that translated existing issue links to their GitHub
counterparts)
* External links to issues are far more common than external links
directly into source control, so a migration strategy for preserving
those would be highly desirable (the redirector above would also help
handle that)
* One of the requirements for the GitHub migration was to continue to
offer contribution workflows that don't require creation of an account
with a proprietary American service provider. That workflow is to post
a patch on Roundup and ask someone else to convert it into a GitHub
PR. As a result, migrating the issue tracker would also mean saying
we're dropping that workflow requirement, and deliberately excluding
everyone without a GitHub account entirely from the core development
process (they won't even be able to file issues any more).
* The Roundup tracker is the database-of-record for CLA signatures. We
don't have the ability to add arbitrary user metadata on GitHub, so if
the issue tracker migrates to GitHub, we'll need a different solution
for CLA tracking.
* Roundup's nosy list is integrated with the experts index in the
developer guide, so an equivalent for that would need to be worked out
for GitHub in order to help out triagers

Personally, the only things I really miss on Roundup vs GitHub issues
are usability tweaks like Markdown support in the comment editor, and
inline dropdowns for @-mentions of other users and #-mentions of other
issues, so if someone is motivated to work on issue tracking
enhancements, that seems like a more fruitful endeavour than trying to
migrate wholesale to a proprietary third party service.

Cheers,
Nick.

P.S. That said, one tracker that I think absolutely *would* be worth
migrating to GitHub is the meta-tracker at
http://psf.upfronthosting.co.za/roundup/meta. We haven't customised
that instance the way we have bugs.python.org, and consolidating it
and the source repo at http://hg.python.org/tracker/roundup/ into a
single https://github.com/python/bugs.python.org repo would better
align tracker development with development on other parts of the
infrastructure.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Mariatta Wijaya]

>
> It's been a year and 10 days since we moved to GitHub, so I figured now is
> as good a time as any to ask people if they are generally happy with the
> workflow


It's been great! Thanks!


> Said PEP may also need to mention the possibility of exporting
> > the history of GitHub issues, in case CPython ever migrates away from
> > GitHub; I remember that concern being raised when the original
> > migration was discussed.
> There are tools for it (e.g., I wrote
> https://github.com/mcepl/github-issues-export to move issues to
> Bugzilla, yes I am weird) and it is not that difficult to write
> something just to get data from GitHub’s all embracing arms. Of
> course, I am not sure how it would work on really large number
> of bugs, and it would be necessary to do some postprocessing
> (changing issue numbers etc.).


It's really more complicated than just copying over text from the bpo to
GitHub. Can we preserve the history and the existing discussions?
What about existing patches currently attached to issues? Can the issue
number be preserved?
Everywhere in our commit message we reference bpo-. What will happen to
those?
We'll need to come up with new workflow. How do we want to triage the
issues? And what does it mean to current bug tracker triage permission?

The recent
> improvements to @miss-islington (kudos to Mariatta!) allowing her to
> auto-backport PRs and commit them is a big time saver.


Thanks! I can't take all credit. The bots are easy to build and maintain
mainly because of Brett Cannon's gidgethub [1] library. Thanks Brett!
Also... is this a good time to advertise my PyCon tutorial [2] about
building GitHub bots?

 I still miss my “commit when CI completes” button, but oh well.


It is in my todo list, to at least notify when all CI completed so we can
go back and merge it.
I'll have time to think about this after PyCon US.

if there is a particular sticking point to please bring it up


This has been brought up several times in different mailing lists: Please
clean up the commit message before merging.

1. Ensure bpo-N is included.
If the bpo-N is not included, the commit doesn't get linked to the
issue in the b.p.o.

2. Ensure that the GitHub PR number is replaced, from (#12345) to (GH-12345)
In the b.p.o,  (#12345) links to bugs.python.org/issue12345 instead of
linking to GitHub PR number 12345.

3. Don't reference bpo-N as #N in the commit message.
tl;dr it breaks the bots. See [3] and [4]

One improvement I've been thinking about is related to the way we add news
entry using "blurb add" on the command line.
I wish there's a web UI for doing it. A place where I can type in the news
entry, give it the GitHub PR number, the bpo number, and with a button
click the News.d file magically created and added to the PR. Any thoughts
about this?


Mariatta Wijaya

[1] https://gidgethub.readthedocs.io/en/stable/
[2] https://us.pycon.org/2018/schedule/presentation/41/
[3] https://github.com/python/bedevere/issues/95#issuecomment-366570410
[4] https://github.com/python/bedevere/issues/97



ᐧ
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Dan Stromberg]

On Wed, Feb 21, 2018 at 2:19 PM, Barry Warsaw  wrote:
> On Feb 21, 2018, at 13:22, Guido van Rossum  wrote:
>>
>> I'm willing to reconsider if there's a good enough tool. Ditto for C code 
>> (or do we already do it for C?).
>
> For Python code, flake8 --possibly with our own custom plugins— is the way to 
> go.

Is flake8 that much better than pylint, that pylint wouldn't even be discussed?

pylint does warn about some relatively unimportant things out of the
box, but it can be configured to ignore (almost?) everything it
checks.

I've been editing Python code in vim with syntastic.  I have syntastic
set up to run pyflakes, pycodestyle and pydocstyle.  And I have a
macro that saves the buffer, shells out and runs "make" with the
default rule - and that default rule almost always does a
whole-program pylint.

It's possible to make pylint check just one file from syntastic, but I
don't do that because it's too slow on large files.

I've gotten the impression that pylint can detect some errors that
pyflakes misses.  Not sure about flake8.

I do like it that flake8 has a mccabe check.  pylint doesn't appear to
have that, and instead relies on things like "too many statements",
"too many branches" and "too many variables".
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Brett Cannon]

On Wed, 21 Feb 2018 at 14:21 Barry Warsaw  wrote:

> On Feb 21, 2018, at 13:22, Guido van Rossum  wrote:
> >
> > I'm willing to reconsider if there's a good enough tool. Ditto for C
> code (or do we already do it for C?).
>
> For Python code, flake8 --possibly with our own custom plugins— is the way
> to go.  It would probably take some kind of ratchet or transition period
> before all of the stdlib were compliant.  We’d have to be careful of the
> inevitable raft of PRs to fix things, which may distract from actual bug
> fixes and improvements.  OTOH, that would be another external dependency
> pulled in for core Python development.
>

As long as we pin the version and upgrade only consciously I don't think
it's a massive issue to have an external dependency.

As for C, maybe clang-format?


>
> > FWIW I'm personally hugely happy with the new workflow -- my only regret
> is that we're not using GitHub for issue tracking yet.
>
> I’m very happy with the workflow too, and Mariatta’s and others work has
> been hugely important in making things work so well.  I still miss my
> “commit when CI completes” button, but oh well.
>
> As for the bug tracker, I still do like Roundup, and we have a huge
> investment in it, not just in resources expended to make it rock, but also
> in all the history in it and everything that integrates with it.  I
> wouldn’t stop anybody who’s motivated to spearhead a move to GH issues, but
> I also don’t think that can be taken up lightly.  Just look at the vast
> amount of work Brett and others had to do to migrate code hosting.  It
> would be nice to have integrated reviews and issues (e.g. for auto-closing
> perhaps), but I also honestly don’t miss much with the current suite of
> tools.
>

All I will say is I don't plan on doing this one myself :) .
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Matěj Cepl]

On 2018-02-21, 21:49 GMT, Chris Angelico wrote:
> Said PEP may also need to mention the possibility of exporting 
> the history of GitHub issues, in case CPython ever migrates away from
> GitHub; I remember that concern being raised when the original
> migration was discussed.

There are tools for it (e.g., I wrote 
https://github.com/mcepl/github-issues-export to move issues to 
Bugzilla, yes I am weird) and it is not that difficult to write 
something just to get data from GitHub’s all embracing arms. Of 
course, I am not sure how it would work on really large number 
of bugs, and it would be necessary to do some postprocessing 
(changing issue numbers etc.).

Best,

Matěj
-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
God is not worried about my financial situation.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Antoine Pitrou]

On Wed, 21 Feb 2018 01:58:15 +
Brett Cannon  wrote:
> It's been a year and 10 days since we moved to GitHub, so I figured now is
> as good a time as any to ask people if they are generally happy with the
> workflow and if there is a particular sticking point to please bring it up
> on the core-workflow mailing list so we can potentially address it.

It works great for me.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Barry Warsaw]

On Feb 21, 2018, at 13:22, Guido van Rossum  wrote:
> 
> I'm willing to reconsider if there's a good enough tool. Ditto for C code (or 
> do we already do it for C?).

For Python code, flake8 --possibly with our own custom plugins— is the way to 
go.  It would probably take some kind of ratchet or transition period before 
all of the stdlib were compliant.  We’d have to be careful of the inevitable 
raft of PRs to fix things, which may distract from actual bug fixes and 
improvements.  OTOH, that would be another external dependency pulled in for 
core Python development.

> FWIW I'm personally hugely happy with the new workflow -- my only regret is 
> that we're not using GitHub for issue tracking yet.

I’m very happy with the workflow too, and Mariatta’s and others work has been 
hugely important in making things work so well.  I still miss my “commit when 
CI completes” button, but oh well.

As for the bug tracker, I still do like Roundup, and we have a huge investment 
in it, not just in resources expended to make it rock, but also in all the 
history in it and everything that integrates with it.  I wouldn’t stop anybody 
who’s motivated to spearhead a move to GH issues, but I also don’t think that 
can be taken up lightly.  Just look at the vast amount of work Brett and others 
had to do to migrate code hosting.  It would be nice to have integrated reviews 
and issues (e.g. for auto-closing perhaps), but I also honestly don’t miss much 
with the current suite of tools.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Chris Angelico]

On Thu, Feb 22, 2018 at 8:38 AM, Guido van Rossum  wrote:
> On Wed, Feb 21, 2018 at 1:28 PM, Bernát Gábor 
> wrote:
>>
>> Any reason in particular for not using github issues (or blockers in
>> achieving this)?
>
>
> Many core devs did not want to change their workflow, and Brett did not want
> to have to handle two migrations at once.
>
> When a new serious volunteer steps up we might consider it (a PEP would have
> to be written).
>

Said PEP may also need to mention the possibility of exporting the
history of GitHub issues, in case CPython ever migrates away from
GitHub; I remember that concern being raised when the original
migration was discussed.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Terry Reedy]

On 2/20/2018 8:58 PM, Brett Cannon wrote:
It's been a year and 10 days since we moved to GitHub, so I figured now 
is as good a time as any to ask people if they are generally happy with 
the workflow


***The nearly automatic backporting!!!  A responsible human *should* 
check backport PRs, as it is possible for a merge to 'work', but be 
wrong, but that is all that a human *needs* to do.


and if there is a particular sticking point to please bring 
it up on the core-workflow mailing list so we can potentially address it.


Neither Travis not *nix or Mac buildbots test tkinter code.  I will post 
on the c-w list, but I don't know if that covers buildbots.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Guido van Rossum]

On Wed, Feb 21, 2018 at 1:28 PM, Bernát Gábor 
wrote:

> Any reason in particular for not using github issues (or blockers in
> achieving this)?
>

Many core devs did not want to change their workflow, and Brett did not
want to have to handle two migrations at once.

When a new serious volunteer steps up we might consider it (a PEP would
have to be written).

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Ivan Levkivskyi]

> I'm personally hugely happy with the new workflow -- my only regret is
that we're not using GitHub for issue tracking yet.

I have the same feelings. I like the GitHub issue tracker, and it would be
great to migrate there (if possible).

--
Ivan



On 21 February 2018 at 21:22, Guido van Rossum  wrote:

> On Wed, Feb 21, 2018 at 9:53 AM, Brett Cannon  wrote:
>
>>
>>
>> On Wed, 21 Feb 2018 at 09:30 Yury Selivanov 
>> wrote:
>>
>>> FWIW I'm extremely happy with the current workflow. The recent
>>> improvements to @miss-islington (kudos to Mariatta!) allowing her to
>>> auto-backport PRs and commit them is a big time saver.
>>>
>>> I can only suggest a couple improvements:
>>>
>>> 1. Make our bots check the code style—fully enforce PEP 8, lint the
>>> code, and detect trailing whitespace on all lines that a PR modifies.
>>>
>>
>> Guido said "no" to this from the outset.
>>
>
> I'm willing to reconsider if there's a good enough tool. Ditto for C code
> (or do we already do it for C?).
>
> FWIW I'm personally hugely happy with the new workflow -- my only regret
> is that we're not using GitHub for issue tracking yet.
>
> --
> --Guido van Rossum (python.org/~guido)
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> levkivskyi%40gmail.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Bernát Gábor]

Any reason in particular for not using github issues (or blockers in
achieving this)?

On 21 Feb 2018 21:25, "Guido van Rossum"  wrote:

> On Wed, Feb 21, 2018 at 9:53 AM, Brett Cannon  wrote:
>
>>
>>
>> On Wed, 21 Feb 2018 at 09:30 Yury Selivanov 
>> wrote:
>>
>>> FWIW I'm extremely happy with the current workflow. The recent
>>> improvements to @miss-islington (kudos to Mariatta!) allowing her to
>>> auto-backport PRs and commit them is a big time saver.
>>>
>>> I can only suggest a couple improvements:
>>>
>>> 1. Make our bots check the code style—fully enforce PEP 8, lint the
>>> code, and detect trailing whitespace on all lines that a PR modifies.
>>>
>>
>> Guido said "no" to this from the outset.
>>
>
> I'm willing to reconsider if there's a good enough tool. Ditto for C code
> (or do we already do it for C?).
>
> FWIW I'm personally hugely happy with the new workflow -- my only regret
> is that we're not using GitHub for issue tracking yet.
>
> --
> --Guido van Rossum (python.org/~guido)
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> jokerjokerer%40gmail.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Guido van Rossum]

On Wed, Feb 21, 2018 at 9:53 AM, Brett Cannon  wrote:

>
>
> On Wed, 21 Feb 2018 at 09:30 Yury Selivanov 
> wrote:
>
>> FWIW I'm extremely happy with the current workflow. The recent
>> improvements to @miss-islington (kudos to Mariatta!) allowing her to
>> auto-backport PRs and commit them is a big time saver.
>>
>> I can only suggest a couple improvements:
>>
>> 1. Make our bots check the code style—fully enforce PEP 8, lint the
>> code, and detect trailing whitespace on all lines that a PR modifies.
>>
>
> Guido said "no" to this from the outset.
>

I'm willing to reconsider if there's a good enough tool. Ditto for C code
(or do we already do it for C?).

FWIW I'm personally hugely happy with the new workflow -- my only regret is
that we're not using GitHub for issue tracking yet.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Steve Holden]

On Wed, Feb 21, 2018 at 5:53 PM, Brett Cannon  wrote:

>
>
> On Wed, 21 Feb 2018 at 09:30 Yury Selivanov 
> wrote:
>
>>
>
>
>> Huge thanks to the core-workflow team!
>>
>>
​Hear, hear!

regards
 Steve​
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Brett Cannon]

On Wed, 21 Feb 2018 at 09:30 Yury Selivanov  wrote:

> FWIW I'm extremely happy with the current workflow. The recent
> improvements to @miss-islington (kudos to Mariatta!) allowing her to
> auto-backport PRs and commit them is a big time saver.
>
> I can only suggest a couple improvements:
>
> 1. Make our bots check the code style—fully enforce PEP 8, lint the
> code, and detect trailing whitespace on all lines that a PR modifies.
>

Guido said "no" to this from the outset.


>
> 2. AppVeyor and Travis are a bit slow at times.  Maybe it's possible
> to ask them to slightly increase our quotas (again).  Although usually
> this isn't a problem and CI is fast enough.
>

We already have a huge amount of quota from Travis and AppVeyor is no
special quota (we're just like any other open source project). Our contact
at Circle CI left the company so that option has walked away.

IOW we either have to find another CI provider who happens to be faster or
we are going to have to build our own.


>
> 3. It would be great if our buildbots could update the PR at blame
> when they detect a regression (I understand that this is a hard to
> implement feature...)
>

Possibly. This is starting to dive into Bors/Zuul-level regression
management which is more infrastructure to run, so we would have to decide
we seriously want this maintenance overhead.

-Brett


>
> Huge thanks to the core-workflow team!
>
> Yury
>
> On Tue, Feb 20, 2018 at 8:58 PM, Brett Cannon  wrote:
> > It's been a year and 10 days since we moved to GitHub, so I figured now
> is
> > as good a time as any to ask people if they are generally happy with the
> > workflow and if there is a particular sticking point to please bring it
> up
> > on the core-workflow mailing list so we can potentially address it.
> >
> > ___
> > Python-Dev mailing list
> > Python-Dev@python.org
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> >
> https://mail.python.org/mailman/options/python-dev/yselivanov.ml%40gmail.com
> >
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How is the GitHub workflow working for people?

[Yury Selivanov]

FWIW I'm extremely happy with the current workflow. The recent
improvements to @miss-islington (kudos to Mariatta!) allowing her to
auto-backport PRs and commit them is a big time saver.

I can only suggest a couple improvements:

1. Make our bots check the code style—fully enforce PEP 8, lint the
code, and detect trailing whitespace on all lines that a PR modifies.

2. AppVeyor and Travis are a bit slow at times.  Maybe it's possible
to ask them to slightly increase our quotas (again).  Although usually
this isn't a problem and CI is fast enough.

3. It would be great if our buildbots could update the PR at blame
when they detect a regression (I understand that this is a hard to
implement feature...)

Huge thanks to the core-workflow team!

Yury

On Tue, Feb 20, 2018 at 8:58 PM, Brett Cannon  wrote:
> It's been a year and 10 days since we moved to GitHub, so I figured now is
> as good a time as any to ask people if they are generally happy with the
> workflow and if there is a particular sticking point to please bring it up
> on the core-workflow mailing list so we can potentially address it.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/yselivanov.ml%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] How is the GitHub workflow working for people?

[Brett Cannon]

It's been a year and 10 days since we moved to GitHub, so I figured now is
as good a time as any to ask people if they are generally happy with the
workflow and if there is a particular sticking point to please bring it up
on the core-workflow mailing list so we can potentially address it.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com