[Python-Dev] Re: On the migration from master to main

[Terry Reedy]

On 5/3/2021 9:27 PM, Terry Reedy wrote:

On 5/3/2021 7:45 PM, Tim Peters wrote:

I'm guessing it's time to fiddle local CPython clones to account for
master->main renaming now?



Blob 2 ("upstream"):

"""
The CPython repository's default branch was renamed from ``master`` to 



``main``
after the Python 3.10b1 release. If you had cloned the repository 
before this

change, you can rename your local branch as follows::

 git branch -m master main
 git fetch upstream
 git branch -u upstream/main main
"""

 From my dim understanding, "upstream" makes more sense, but I don't
know.


For 'pull from upsteam, push to origin' workflow,
https://docs.github.com/en/github/administering-a-repository/renaming-a-branch 



says the 2nd, +
git remote set-head origin -a

+ optionally, 'to remove tracking references to the old branch name'
git remote prone origin

When I did this, there was a '[pruned]' line for every branch ever on 
the fork (about 200 for me), including the bots temporary backport 
branches.


I am now preparing a small PR and will test if creation works as usual.


It does.


--
Terry Jan Reedy


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HTIREIDBUIFYP5YDMARDBGTBL3MSMYEA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: On the migration from master to main

[Terry Reedy]

On 5/3/2021 7:45 PM, Tim Peters wrote:

I'm guessing it's time to fiddle local CPython clones to account for
master->main renaming now?

If so, I've seen two blobs of instructions, which are very similar but
not identical:

Blob 1 ("origin"):

"""
You just need to update your local clone after the branch name changes.
 From the local clone of the repository on a computer,
run the following commands to update the name of the default branch.

$ git branch -m master main
$ git fetch origin
$ git branch -u origin/main main

Apart from that, you should update any local script or command that uses
the name "master" to use the name "main".
"""

Blob 2 ("upstream"):

"""
The CPython repository's default branch was renamed from ``master`` to ``main``
after the Python 3.10b1 release. If you had cloned the repository before this
change, you can rename your local branch as follows::

 git branch -m master main
 git fetch upstream
 git branch -u upstream/main main
"""

 From my dim understanding, "upstream" makes more sense, but I don't
know.


For 'pull from upsteam, push to origin' workflow,
https://docs.github.com/en/github/administering-a-repository/renaming-a-branch

says the 2nd, +
git remote set-head origin -a

+ optionally, 'to remove tracking references to the old branch name'
git remote prone origin

When I did this, there was a '[pruned]' line for every branch ever on 
the fork (about 200 for me), including the bots temporary backport branches.


I am now preparing a small PR and will test if creation works as usual.
--
Terry Jan Reedy

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CWXHEKLX3ZDJFOPA3ALQRPJ3DN7NM6A6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: github and dependabot

[Jonathan Goble]

On Mon, May 3, 2021 at 9:15 PM Łukasz Langa  wrote:

> It's bogus automation, you can safely reject those pull requests. If you
> do merge any pull requests to `main` of your personal fork, your `main`
> branch will diverge from python/cpython's. Not recommended.
>
> I just merged the equivalent pull requests from dependabot on
> python/cpython. You can pull from upstream.
>
> - Ł
>
> > On 4 May 2021, at 02:59, Ethan Furman  wrote:
> >
> > I have two pull requests against my cpython fork from a dependabot --
> what is that, and should I merge them?
> >
> > --
> > ~Ethan~
>

This is a known issue on GitHub's end, specifically that disabling
Dependabot on a fork is broken:
https://github.com/dependabot/dependabot-core/issues/2804 (note that a
comment specifically about the impact on CPython exists there as well).

The only workaround at the moment is to delete and recreate your fork,
after which Dependabot should be disabled so long as you never touch the
setting again.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/P473NI2MIY6O3N6E6RR66ED5SXZLHSUP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: github and dependabot

[Łukasz Langa]

It's bogus automation, you can safely reject those pull requests. If you do 
merge any pull requests to `main` of your personal fork, your `main` branch 
will diverge from python/cpython's. Not recommended.

I just merged the equivalent pull requests from dependabot on python/cpython. 
You can pull from upstream.

- Ł

> On 4 May 2021, at 02:59, Ethan Furman  wrote:
> 
> I have two pull requests against my cpython fork from a dependabot -- what is 
> that, and should I merge them?
> 
> --
> ~Ethan~
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/OTX3F5RQFPTND3UGK2RRFNWDXAFOKXO4/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ECUMBNN2O2Q2FEP5MLWA6DU4A65KINJA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] github and dependabot

[Ethan Furman]

I have two pull requests against my cpython fork from a dependabot -- what is 
that, and should I merge them?

--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OTX3F5RQFPTND3UGK2RRFNWDXAFOKXO4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: On the migration from master to main

[Łukasz Langa]

> On 4 May 2021, at 02:04, Łukasz Langa  wrote:
> 
> Having renamed the branch in my fork first, the exact sequence I used on my 
> own clone was:
> 
> ❯ git checkout master
> ❯ git branch -m master main
> ❯ git fetch origin
> ❯ git branch -u origin/main main
> ❯ git remote set-head origin -a
> ❯ git fetch upstream
> ❯ git remote set-head upstream -a
> ❯ git pull upstream main
> 
> This worked, I can successfully pull from upstream's main and push to my 
> upstream's main. The `set-head` ones were suggested by the GitHub UI and 
> ended up with heads explicitly being listed in `git log` which I guess is 
> harmless.

Seeing Ned's and Mariatta's comments on the matter I guess I should clarify 
that my commands above are for a symmetrical setup, i.e. where I expect the 
default `git pull` to pull from origin, and the default `git push` to push to 
origin.

I might not be your typical user here, since I actually push to upstream too 
every now and again as part of release management, in particular pushing out 
signed release tags (which are full git objects with the same metadata as 
commits).

But I used this setup even before because I like to think about "upstream" as 
"more remote" than my personal fork. I like to have to explicitly call out that 
I'm pulling from upstream or pushing to it.

- Ł___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NAYOZNZVO7APEYORI2XN4VYPI64XT5FE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: On the migration from master to main

[Ned Deily]

On May 3, 2021, at 19:45, Tim Peters  wrote:
> Blob 1 ("origin"):
> 
> """
> You just need to update your local clone after the branch name changes.
> From the local clone of the repository on a computer,
> run the following commands to update the name of the default branch.
> 
> $ git branch -m master main
> $ git fetch origin
> $ git branch -u origin/main main
> 
> Apart from that, you should update any local script or command that uses
> the name "master" to use the name "main".
> """
> 
> Blob 2 ("upstream"):
> 
> """
> The CPython repository's default branch was renamed from ``master`` to 
> ``main``
> after the Python 3.10b1 release. If you had cloned the repository before this
> change, you can rename your local branch as follows::
> 
>git branch -m master main
>git fetch upstream
>git branch -u upstream/main main
> """
> 
> From my dim understanding, "upstream" makes more sense, but I don't
> know. On my box:
> 
> """
> $ git remote -v
> origin  https://github.com/tim-one/cpython (fetch)
> origin  https://github.com/tim-one/cpython (push)
> upstreamhttps://github.com/python/cpython (fetch)
> upstreamhttps://github.com/python/cpython (push)
> """
> 
> so sync\ing with the universally shared "upstream" just makes more sense to 
> me.

If you are using the 'pull from "upstream", push to "origin"' naming convention 
that GitHub recommends, yes, Blob 2 is likely what you want to do so that "git 
pull" by default pulls from "upstream".  If you executed Blob 1 by mistake, 
just doing 'git branch -u upstream/main main' should fix things up unless you 
have pushed commits to the master->main branch in your GitHub clome pointed to 
by "origin"; in that case, you may get a request to merge the two branches 
which you probably don't want to do. In that case, you may need to rename the 
branch in your origin clone (which is seldom a good idea for cpython since you 
aren't able to push directly to the main cpython repo) or use git log and git 
reset --hard to remove the offending commits, if you don't need them. If you 
have work-in-progress you don't want to lose, don't delete anything: it's 
probably easily salvageable!

--
  Ned Deily
  n...@python.org -- []

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OARMR5AKNYY5EWVFDKO7DUPJOHWXFHJD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: On the migration from master to main

[Łukasz Langa]

> On 4 May 2021, at 01:45, Tim Peters  wrote:
> 
> Right? Wrong? Do we need some mix of both? Something else?


Having renamed the branch in my fork first, the exact sequence I used on my own 
clone was:

❯ git checkout master
❯ git branch -m master main
❯ git fetch origin
❯ git branch -u origin/main main
❯ git remote set-head origin -a
❯ git fetch upstream
❯ git remote set-head upstream -a
❯ git pull upstream main

This worked, I can successfully pull from upstream's main and push to my 
upstream's main. The `set-head` ones were suggested by the GitHub UI and ended 
up with heads explicitly being listed in `git log` which I guess is harmless.

Cheers,
Łukasz

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HRLKK4QXASEAVJPPUPJMI53CJRCWIHPV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: On the migration from master to main

[Tim Peters]

I'm guessing it's time to fiddle local CPython clones to account for
master->main renaming now?

If so, I've seen two blobs of instructions, which are very similar but
not identical:

Blob 1 ("origin"):

"""
You just need to update your local clone after the branch name changes.
>From the local clone of the repository on a computer,
run the following commands to update the name of the default branch.

$ git branch -m master main
$ git fetch origin
$ git branch -u origin/main main

Apart from that, you should update any local script or command that uses
the name "master" to use the name "main".
"""

Blob 2 ("upstream"):

"""
The CPython repository's default branch was renamed from ``master`` to ``main``
after the Python 3.10b1 release. If you had cloned the repository before this
change, you can rename your local branch as follows::

git branch -m master main
git fetch upstream
git branch -u upstream/main main
"""

>From my dim understanding, "upstream" makes more sense, but I don't
know. On my box:

"""
$ git remote -v
origin  https://github.com/tim-one/cpython (fetch)
origin  https://github.com/tim-one/cpython (push)
upstreamhttps://github.com/python/cpython (fetch)
upstreamhttps://github.com/python/cpython (push)
"""

so sync\ing with the universally shared "upstream" just makes more sense to me.

Right? Wrong? Do we need some mix of both? Something else?

I'd rather get it right the first time than try to untangle a mess
after the fact ;-)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/X3V42DYOHFLGAUPODFLXMYZWDE3VY47W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [RELEASE] Python 3.8.10, 3.9.5, and 3.10.0b1 are now available

[Łukasz Langa]

This has been a very busy day for releases and on behalf of the Python 
development community we’re happy to announce the availability of three new 
Python releases.

Python 3.10 is now in Beta

Get it here: Python 3.10.0b1 

Python 3.10 is still in development. 3.10.0b1 is the first of four planned beta 
release previews. Beta release previews are intended to give the wider 
community the opportunity to test new features and bug fixes and to prepare 
their projects to support the new feature release.

We strongly encourage maintainers of third-party Python projects to test with 
3.10 during the beta phase and report issues found to the Python bug tracker 
 as soon as possible. While the release is planned to 
be feature complete entering the beta phase, it is possible that features may 
be modified or, in rare cases, deleted up until the start of the release 
candidate phase (Monday, 2021-08-02). Our goal is have no ABI changes after 
beta 4 and as few code changes as possible after 3.10.0rc1, the first release 
candidate. To achieve that, it will be extremely important to get as much 
exposure for 3.10 as possible during the beta phase.

Please keep in mind that this is a preview release and its use is not 
recommended for production environments.

The next pre-release, the second beta release of Python 3.10, will be 3.10.0b2. 
It is currently scheduled for 2021-05-25. Please see PEP 619 
 for details.

Development Begins on Python 3.11

With Python 3.10 moving to beta, it received its own 3.10 branch in the 
repository . All new features are now 
targeting Python 3.11, to be released in October 2022.

Using the opportunity with the creation of the 3.10 branch, we renamed the 
master branch of the repository to main. It’s been a bit rocky 

 but looks like we’re open for business. Please rename the main branch of your 
personal fork using the guide GitHub will give you when you go to your fork’s 
main page. In case of any outstanding issues, please contact the 3.11 RM 
.

Python 3.9.5

Get it here: Python 3.9.5 
Python 3.9.5 is the newest major stable release of the Python programming 
language, and it contains many new features and optimizations. There’s been 111 
commits since 3.9.4 which is a similar amount compared to 3.8 at the same stage 
of the release cycle. See the change log 
 for details.

On macOS, we encourage you to use the universal2 variant whenever possible. The 
legacy 10.9+ Intel-only variant will not be provided for Python 3.10 and the 
universal2 variant will become the default download for future 3.9.x releases. 
You may need to upgrade third-party components, like pip, to later versions 
once they are released. You may experience differences in behavior in IDLE and 
other Tk-based applications due to using the newer version of Tk. As always, if 
you encounter problems when using this installer variant, please check 
https://bugs.python.org  for existing reports and for 
opening new issues.

The next Python 3.9 maintenance release will be 3.9.6, currently scheduled for 
2021-06-28.

The Last Regular Bugfix Release of Python 3.8

Get it here: Python 3.8.10 

According to the release calendar specified in PEP 569 
, Python 3.8.10 is the final regular 
maintenance release. Starting now, the 3.8 branch will only accept security 
fixes and releases of those will be made in source-only form until October 
2024. To keep receiving regular bug fixes, please upgrade to Python 3.9.

Compared to the 3.7 series, this last regular bugfix release is relatively 
dormant at 92 commits since 3.8.9. Version 3.7.8, the final regular bugfix 
release of Python 3.7, included 187 commits. But there’s a bunch of important 
updates here regardless, the biggest being macOS Big Sur and Apple Silicon 
build support. This work would not have been possible without the effort of 
Ronald Oussoren, Ned Deily, Maxime Bélanger, and Lawrence D’Anna from Apple. 
Thank you!

Take a look at the change log 
 for details.

We hope you enjoy the new releases

Your friendly release team,
Ned Deily @nad 
Steve Dower @steve.dower 
Pablo Galindo Salgado @pablogsal 
Łukasz Langa @ambv ___

[Python-Dev] Re: [python-committers] [Release manager team communication] master blocked until 3.10 beta 1 is released

[Jonathan Goble]

On Mon, May 3, 2021 at 5:13 PM Victor Stinner  wrote:

> Hi,
>
> Please don't attempt to merge PRs until the GitHub issue described
> below is solved ;-)
>
> Pablo renamed the default "master" branch to "main" (in a live Twitch
> stream ;-)) but got a GitHub internal error! Maybe it's because the
> dialog announced that 1.4k+ pull requests and 700+ repositositories
> will be impacted which is not a common case. Right now, there are
> "main" and "master" branches.
>
> I reported the issue to GitHub Support forum:
>
> https://github.community/t/renaming-python-master-branch-to-main-1-4k-prs-700-repositories-triggered-server-http-error-500/178090
>
> Victor
>

To copy my reply from there:

Looks like it just needed time to process.
https://github.com/python/cpython/branches now shows “main” as the default
and no sign of a “master” branch. I checked one random PR and it now
targets “main”.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BNR5ZDNUQFOGCXQVGLN5U23QVRXMSSHW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] [Release manager team communication] master blocked until 3.10 beta 1 is released

[Victor Stinner]

Hi,

Please don't attempt to merge PRs until the GitHub issue described
below is solved ;-)

Pablo renamed the default "master" branch to "main" (in a live Twitch
stream ;-)) but got a GitHub internal error! Maybe it's because the
dialog announced that 1.4k+ pull requests and 700+ repositositories
will be impacted which is not a common case. Right now, there are
"main" and "master" branches.

I reported the issue to GitHub Support forum:
https://github.community/t/renaming-python-master-branch-to-main-1-4k-prs-700-repositories-triggered-server-http-error-500/178090

Victor

On Mon, May 3, 2021 at 5:59 PM Pablo Galindo Salgado
 wrote:
>
> Hi everyone,
>
> Unfortunately, the CI for master is currently quite unstable and he had some 
> problems that we
> have been fixing all weekend and today. We are doing our best to stabilize 
> the test suite and making
> sure that everything is ready to go for the release with no issues, but this 
> will take some time (also
> bear in mind that today is a bank holiday in the UK, so I am doing my best to 
> get the release ready
> in a holiday). Given this and the fact that we need to do a branch rename,
> **we have decided to block the master branch** until we can stabilize the 
> test suite.
>
> In the meantime, if you have some urgent fix or PR that you absolutely need 
> to get merge before
> feature freeze, you can add me as a reviewer to said PR so we can evaluate 
> the merge.
>
> Thanks for your understanding.
>
> I will update once master is unblocked again.
>
> Regards from cloudy London, Pablo Galindo Salgado
>
>
> ___
> python-committers mailing list -- python-committ...@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committ...@python.org/message/AKSCARRZJKKU427Z7DIMYO7MK5RSXOFR/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/LCCT76L7ILONS7VKLC72FBJAOYJIBZMU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [Release manager team communication] master blocked until 3.10 beta 1 is released

[Pablo Galindo Salgado]

Hi everyone,

Unfortunately, the CI for master is currently quite unstable and he had
some problems that we
have been fixing all weekend and today. We are doing our best to stabilize
the test suite and making
sure that everything is ready to go for the release with no issues, but
this will take some time (also
bear in mind that today is a bank holiday in the UK, so I am doing my best
to get the release ready
in a holiday). Given this and the fact that we need to do a branch rename,
**we have decided to block the master branch** until we can stabilize the
test suite.

In the meantime, if you have some urgent fix or PR that you absolutely need
to get merge before
feature freeze, you can add me as a reviewer to said PR so we can evaluate
the merge.

Thanks for your understanding.

I will update once master is unblocked again.

Regards from cloudy London, Pablo Galindo Salgado
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/AKSCARRZJKKU427Z7DIMYO7MK5RSXOFR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Announcing the CPython Docs Workgroup

[Carol Willing]

Raymond,

Anyone can contribute to the documentation and comment, and core devs can
accept patches. Nothing changes here.

The Steering Council did approve the initial members and charter.  The
intent has always been to be transparent and open. As discussed at last
year's Language Summit, the goal is to build a wider community of
documentarians, what I will refer to as the Documentation Team, and to
build a Working Group focused on one year to five year priorities. The
Working Group will also act as an Editorial Board made up of members who
are core developers as well as others who are passionate about
documentation and education.

On a personal note as I mentioned in the PyCascades Core Dev Panel, I have
had a very challenging last year including burnout and depression. I
imagine this past year has been hard for many. Any delay in the Docs
Workgroup falls squarely on my shoulders. Please assume that there is good
intent and transparency behind this workgroup. For the record, the four
individuals listed are those that were instrumental in last year's Language
Summit presentation as well as Julian Palard who has had a formal role in
CPython Documentation. There were many folks that worked on the charter
during the last Core Dev sprint who are not in this initial group, but it
is my sincere hope that they will apply, as I hope you will, along with any
others who are interested.

Thanks!

Carol

On Mon, May 3, 2021 at 1:15 AM Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:

> That seems exclusionary.   Right now, anyone can contribute to
> documentation, anyone can comment on proposals, and any core dev can accept
> their patches.
>
> In the interest of transparency, can you explain why the other initial
> members did not need to go through an application process?  ISTM the
> initial group excludes our most active documentation contributors and
> includes people who have only minimal contributions to existing
> documentation and mostly have not participated in any documentation reviews
> on the issue tracker. Did the SC approve all the initial members?
>
> Raymond
>
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/MTZNPTQBUURQABJWNLZA26CKA357SWFP/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/U3YQOU5RVJS3G24UTVGKWPZCAM5FDKU5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Announcing the CPython Docs Workgroup

[Raymond Hettinger]

That seems exclusionary.   Right now, anyone can contribute to documentation, 
anyone can comment on proposals, and any core dev can accept their patches.

In the interest of transparency, can you explain why the other initial members 
did not need to go through an application process?  ISTM the initial group 
excludes our most active documentation contributors and includes people who 
have only minimal contributions to existing documentation and mostly have not 
participated in any documentation reviews on the issue tracker. Did the SC 
approve all the initial members?

Raymond



___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MTZNPTQBUURQABJWNLZA26CKA357SWFP/
Code of Conduct: http://python.org/psf/codeofconduct/