Migration to oauthlib community

[JonathanHuot]

Hi everyone,

Since @idan accepted the oauthlib community migration, as a team, we should list what do we need to progress as a true community. I suggest to start with a small list, and please anyone, feel free to participate by adding any suggestions :-)

Define/Improve release process:

• : Tagging
  Wrong releases numbers: we have 2.0.3 on github's releases, 2.0.5 in __init__.py and 2.0.6 on pypi...something wrong for sure
• : Publishing
  I'd recommand to continue to use Travis for publishing, however we could define version directly by using environment variable TRAVIS_TAG (see example at https://github.com/thomsonreuters/bottle-oauthlib/blob/master/setup.py instead of our current hard-coded value: https://github.com/oauthlib/oauthlib/blob/master/oauthlib/__init__.py ). Also, I've seen @ib-lundgren is the actual publisher of the pypi package, he looks inactive since years, but dunno if it's an issue.
• : Documentation
  README needs to be updated with the updated badge for travis-ci.org repository URL (owner must enable it, AFAIK), and also add a badge for the documentation build, cuz it's failing since long time: https://readthedocs.org/projects/oauthlib/builds/6483131/
  DONE IN: Add shields for Python versions, license and RTD #520
• : Communication
  No objection to continue using github issues and Google+, however it seems a bit outdated. Also, the #oauthlib IRC channel is empty, wondering if we could create a Slack room if interested?
  CONCLUSION: gitter came to the rescue. Feel free to join at https://gitter.im/oauthlib/Lobby

Future, roadmap:

• : Do periodic bugs washes could be beneficial

Also, a quick round table could be great. I start the introductions, I'm currently working on a OAuth2.0 RequestValidator implementation with bottle, and I've never worked with OAuth1.0, nor Django nor Pyramid nor Flask. However, I'm trying to have a good knowledge around the RFC involved here (oauth2, introspect, revocation, jwt...). I have not started yet the OpenID integration, but it will come soon.

[skion]

All great ideas @JonathanHuot!

And what do people think about:

• Cleaning up some of the old branches.
• Starting to use GitHub's milestones to plan releases (happy to make a first run on e.g. 3.0, 3.1, 4.0).
• Planning to drop support for Python 2 in one of the major releases (4.0 perhaps).
• Introducing type annotations (after having dropped Python 2).
• Introducing a coding style.

[wiliamsouza]

@JonathanHuot I'm trying clear things a little bit here #512

[duaneking]

Anything I can do just ask.

[MattBlack85]

chiming in :) while working on a PR I noticed there is no coding style around which makes things sometimes hard to follow. I'd like to work on that if you guys are ok. Maybe starting with a issue containing a proposal and after that being accepted, starting to 💅 the codebase?

[JonathanHuot]

Hi @MattBlack85, it's a good idea, any work in this direction is welcomed ! :-)

[ViktorHaag]

re: coding style. I've found in projects I've worked on that by using autopep8 and yapf, I can basically let tooling clean up the coding style so I don't have to worry about it (except in cases where the cleaned up version is far less useful than having it un-cleaned-up, usually to do with line-lengths that would be clearer and only exceed the length boundary by a character or two). I use elpy-mode in Emacs to make that easy, but I suspect it could easily be done in command-line, and CI, as well.

Having an .editorconfig in the root of the repo has also been useful.

[skion]

Just thinking we probably want to have a run merging the currently open PRs before passing the code through a formatter. I'm all for pep8/flake8/yapf.

[MattBlack85]

👍

[duaneking]

👍

I'm a big fan of just keeping things PEP8.

[JonathanHuot]

If no objections, I declare this task done 🍾

The new community has released one patch 2.0.7 and one minor 2.1.0 releases and we're working toward a major 3.0.0 release.

Don't hesitate to chip in and participate to this new exciting release !