Skip to content

Update workflow in PEP 1 #38

Closed
Closed

Description

@berkerpeksag

PEP 1 needs to be updated to reflect the new GitHub workflow. For example, the following part is now outdated. They can send a pull request on GitHub:

 Updates to existing PEPs also come in to peps@python.org.  Many PEP
 authors are not Python committers yet, so PEP editors do the commits for them.

Activity

  1. warsaw commented on Aug 2, 2016

    @warsaw
    Member

    This is done now, right?

  2. berkerpeksag commented on Aug 2, 2016

    @berkerpeksag
    MemberAuthor

    No, not really :) We still need to update the part I quoted for example: They can just send a pull request now.

  3. reopened this on Aug 2, 2016
  4. warsaw commented on Aug 2, 2016

    @warsaw
    Member

    @berkerpeksag Okay! I reopened the issue.

  5. warsaw commented on Oct 13, 2016

    @warsaw
    Member

    The PEP also says:

    Following a discussion on python-ideas, the proposal should be sent as a
    draft PEP to the PEP editors <peps@python.org>.
    

    Is there any objection to just accepting new draft PEPs as PRs too? We'll leave peps@python.org around for questions, help, and such but I don't see much of a need of it for any workflow. It's barely used now as it is.

  6. added a commit that references this issue on Oct 13, 2016
    352ac9e
  7. gvanrossum commented on Oct 13, 2016

    @gvanrossum
    Member

    +1, it's been made obsolete by the tracker and PR workflow. (I'd encourage
    questions in the tracker too -- it's working great for mypy.)

    On Thu, Oct 13, 2016 at 1:46 PM, Barry Warsaw notifications@github.com
    wrote:

    The PEP also says:

    Following a discussion on python-ideas, the proposal should be sent as a
    draft PEP to the PEP editors peps@python.org.

    Is there any objection to just accepting new draft PEPs as PRs too? We'll
    leave peps@python.org around for questions, help, and such but I don't
    see much of a need of it for any workflow. It's barely used now as it is.

    —
    You are receiving this because you are subscribed to this thread.
    Reply to this email directly, view it on GitHub
    #38 (comment), or mute
    the thread
    https://github.com/notifications/unsubscribe-auth/ACwrMqLls9K9v8yweCbenpXmcXFtdp13ks5qzpiXgaJpZM4I-flC
    .

    --Guido van Rossum (python.org/~guido)

  8. warsaw commented on Oct 13, 2016

    @warsaw
    Member

    +1. I think we should mostly discourage peps@python.org. We can even assign PEP numbers by PR. We'll leave that address live though just in case someone wants to contact the editors semi-privately. Let me do an update to #116

  9. Rosuav commented on Oct 13, 2016

    @Rosuav
    Contributor

    Hmm. In principle I'm fine with that, as long as it's practical for everyone. For non-core-devs, the normal thing to do used to be to request a PEP number - is the new workflow going to be that every PEP author starts by picking a number and making sure there's no conflict, or do we modify the PR to pick a number?

  10. warsaw commented on Oct 13, 2016

    @warsaw
    Member

    I would like to see people use an XXX number and we can either assign them a number via PR or modify the PR to assign a number.

  11. gvanrossum commented on Oct 13, 2016

    @gvanrossum
    Member

    (Yeah, the new GitHub feature that lets PR reviewers edit the PR is great
    for this!)

    Personally I'm totally fine with retiring peps@python.org or letting it
    bounce a link to the README in the peps repo -- we can then update the
    README with typical workflows. (E.g. to reserve a PEP number file an
    issue, otherwise use XXX in the PR and allow the reviewers to edit your
    branch.)

    On Thu, Oct 13, 2016 at 2:01 PM, Barry Warsaw notifications@github.com
    wrote:

    I would like to see people use an XXX number and we can either assign them
    a number via PR or modify the PR to assign a number.

    —
    You are receiving this because you commented.
    Reply to this email directly, view it on GitHub
    #38 (comment), or mute
    the thread
    https://github.com/notifications/unsubscribe-auth/ACwrMnLnbQpxV8DhKsXFQj1Ya5f7O5Buks5qzpxBgaJpZM4I-flC
    .

    --Guido van Rossum (python.org/~guido)

  12. Rosuav commented on Oct 13, 2016

    @Rosuav
    Contributor

    Yeah. Has anyone used the "project admins may tweak the PR" workflow? I'm thinking something along the lines of:

    1. PEP author clones peps repo, creates pep-xxx.rst, and creates a PR.
    2. An editor checks the file for structural errors and other issues, and if all looks okay, modifies the PR with a second commit that renames pep-xxx.rst to pep-1234.rst.
    3. Squash commit this PR onto master.
  13. Rosuav commented on Oct 13, 2016

    @Rosuav
    Contributor

    And... Guido's post and mine crossed. Sounds like you have something similar in mind.

  14. warsaw commented on Oct 13, 2016

    @warsaw
    Member

    +1

  15. added a commit that references this issue on Oct 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions