Hi everyone,
After talking with Victor Stinner on some ideas on how to encourage
contributions to CPython and how to give more visibility to contributors
(see Victor notes: http://pythondev.readthedocs.io/community.html),
based on the https://thanks.rust-lang.org/ project (than in turn was based
on http://contributors.rubyonrails.org/) I have created the following
prototype
in my daily commute time:
https://thanks-python.herokuapp.com/
The project runs on Heroku at this moment, it fetches the latest changes
from the git
repository and updates every 30 minutes to get the latest information. You
can click on
any release to get the contributor names:
Example: https://thanks-python.herokuapp.com/tag/v3.6.5
(the names are obtained from the commit messages)
and you can in turn click any contributor name to get the list of commits:
https://thanks-python.herokuapp.com/contributor/Mariatta
You can also obtain a list of all contributors (all time contributors):
https://thanks-python.herokuapp.com/all_time
I want also to emphasize that this is just a very basic prototype made for
evaluating the idea and
the possible benefit that it has,
but is functional
:)
The repo is located here:
https://github.com/pablogsal/thanks-python
At this point is a very simple flask app with a celery worker running in
the background and a redis
interface for celery and for storing the git data (so is very easy to
bootstrap as the first thing it does
when started is to clone the repo and fetch the data again).
What are your opinions on the matter?
P.S. Don't be to critic on my horrible html and web design skills ;)
Regards from sunny London
Pablo Galindo Salgado
Hi all,
I have read the workflow in the code of Bedevere
(https://github.com/python/bedevere/blob/master/bedevere/stage.py#L7),
and there is one thing I do not understand.
Here is the PR - https://github.com/python/cpython/pull/5132
Steps:
1. label: "awaiting review"
2. I did the review and ask for some changes, so in this case, I don't
approve the review.
3. the label has been changed to "awaiting core review" by Bedevere, but
Why? I requested some changes and the PR is not in "awaiting changes"
For me, normally, the label should be on "awaiting changes" and after
a new commit/message from the author, the label should be "awaiting review"
Thank you,
Stéphane
--
Stéphane Wirtel - https://wirtel.be - @matrixise
Currently, people wanting to contribute to projects like peps, devguide,
core-workflow, bedevere, need to sign CLA, which requires a bpo account,
and then they need to add their GitHub account to their bpo account.
I find this quite complicated process and a barrier of entry.
I think it will be great to have this process simplified. I think people
should not need to have bpo account unless they're actually participating
in the bug tracker for CPython.
1. Can we have people sign CLA and not require their bpo account?
2. Other big issue with bpo as CLA host is we don't have easy way that can
let the-knights-who-say-ni update the label in the PR once the contributor
has signed the CLA.
I've brought this up at the language summit, as one of the necessary step
before we can start using GitHub issues. (that is not yet decided, and this
is not the thread to argue about it).
But whether we are using GitHub issues or not, the current process needs
improvement anyway.
Mariatta
ᐧ
Hi,
It seems like AppVeyor is stable again, and test_asyncio has been
fixed, so I suggest to make AppVeyor required again on 2.7, 3.6, 3.7
and master branches.
I just closed the issue of the most annoying test_asyncio failure,
test_start_tls_server_1():
https://bugs.python.org/issue33694
Note: There are still two known test_asyncio random failures, but they
seem to be rare.
* https://bugs.python.org/issue31007 : test_pipe_handle
* https://bugs.python.org/issue33531 : test_stdin_broken_pipe
Victor
We had to turn off AppVeyor as a requirement today due to it not running
any builds for the last 20 hours. Ned Deily suggested that since VSTS on at
least Windows has stabilized that maybe we should switch off AppVeyor off
entirely and make the Windows VSTS builder required.
Since
https://python.visualstudio.com/cpython/_build/index?context=mine&path=%5C&…
shows the builder has been stable I would like to make this required for
master today/tomorrow and then flip it on for the other 3.x branches on
Friday if we don't see any instability.
Any objections/opinions about doing this?
Since both Paul Moore and Antoine Pitrou started to ask questions about a
side comment I made about VSTS, I might as well start a discussion (Steve
has also *just* emailed python-committers about this topic).
Basically Steve Dower and I have been working directly with the VSTS team
to improve their Python support. Along the way they have announced they are
adding anonymous access to build logs which was always a major blocker for
using it in open source. VSTS gave us early access to the anonymous access
that they are launching along with 20 concurrent builders which is more
than what we currently have on Travis and AppVeyor.
At this point Steve has added the appropriate YAML files in the .vsts
directory that control the build jobs so we can test out the integration
and see what the performance is like. But based on what we have been seeing
there will be no queue in getting PRs tested and that applies to Windows,
macOS, and Linux (IOW better coverage and no more issues about performance
or having to wait too long for CI to go green ;) . There is also other
benefits like making at least Windows builds easier to release as signing
those builds can now be automated.
My expectation is that once we are convinced that the VSTS builds are
passing consistently and everything is working as everyone wants for e.g. a
week, we can plan to turn off Travis and AppVeyor for master and 3.x
branches (no one wants to bother with trying to get 2.7 to work on this and
we can simply continue to rely on Travis and AppVeyor as necessary for the
next 18 months). I don't think we want to run multiple CIs indefinitely on
the same branch as it does take time and effort to keep CI green on a
provider since they all have their own quirks.
I should also mention that this free access is not limited to just CPython
and any project can get free accounts and credits now, you just have to
talk to Steve about getting in on the anonymous access before it launches
to the general public (I have no timeline on when that's happening).
