[core-workflow] Re: "Awaiting merge" label for PRs from core devs

[Berker Peksağ]

On Wed, Sep 5, 2018 at 3:28 PM INADA Naoki  wrote:
> Other option is set "awaiting review" label instead of
> "awaiting merge", like PRs from other contributors.

+1. Personally, most of the time I request a review from another core
developer, so setting the "awaiting review" label seems reasonable to
me.

--Berker
___
core-workflow mailing list -- core-workflow@python.org
To unsubscribe send an email to core-workflow-le...@python.org
https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/
This list is governed by the PSF Code of Conduct: 
https://www.python.org/psf/codeofconduct

[core-workflow] Re: Using CLA-assistant for Python

[Berker Peksağ]

On Thu, Aug 30, 2018 at 1:15 AM Mariatta Wijaya 
wrote:

> - Since the status check will be made required, it means every
> contribution no matter how trivial, requires CLA. Without it, we can't
> merge the pull request. (Maybe only the admins can still merge). Sounds
> like this is a good thing anyway (for Python).
>

I don't think this is a good idea. We are getting a good amount of PRs that
fix typos or markup errors and requiring CLA would make people refrain from
contributing to Python. Personally, I wouldn't bother contributing if I was
asked to sign a CLA just to get a simple documentation fix merged.

Also, the amount of work required just to make it usable on python/cpython
seems like a good indication that it's not worth the trouble :)

--Berker
___
core-workflow mailing list -- core-workflow@python.org
To unsubscribe send an email to core-workflow-le...@python.org
https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/
This list is governed by the PSF Code of Conduct: 
https://www.python.org/psf/codeofconduct

[core-workflow] Re: Using Gitmate to help with PR triage

[Berker Peksağ]

On Fri, Jul 20, 2018 at 9:49 PM, Mariatta Wijaya
 wrote:
> Several of its features I'd like to try out for now:
> - automatically add size labels on pull requests. It can analyze the content
> of the pull request, and apply the size labels (xs, s, m, etc)

It would be better if we use less labels, to be honest. Even now, the
amount of labels and different colors make the pull request list
harder to look at: https://github.com/python/cpython/pulls

And I don't find these labels useful especially if there is no way to
ignore auto-generated files such as Python/importlib.h.

> - apply stale label for inactive pull requsts

When will we apply the stale label? Is there a way to apply it for
multiple reasons? For example, 1) PRs older than a year 2) PRs need
rebase 3) PRs update Misc/NEWS

--Berker
___
core-workflow mailing list -- core-workflow@python.org
To unsubscribe send an email to core-workflow-le...@python.org
https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/
This list is governed by the PSF Code of Conduct: 
https://www.python.org/psf/codeofconduct

[core-workflow] Re: Adding some concrete examples to the NEWS entry guide?

[Berker Peksağ]

On Mon, Nov 27, 2017 at 2:10 PM, Victor Stinner
 wrote:
> "Patch by" was useful with Mercurial which didn't allow to store an
> author and a committer. Git now stores the author and the committer:
>
> vstinner@apu$ git show --pretty=full
> 5b48dc638b7405fd9bde4d854bf477dfeaaddf44 --stat
> commit 5b48dc638b7405fd9bde4d854bf477dfeaaddf44
> Author: Jonas Haag 
> Commit: Antoine Pitrou 
>
> I'm not sure about added *manually* the author in the NEWS entry. I
> would prefer to have a generated page like
> https://thanks.rust-lang.org/ to limit the work of the reviewer (and
> of the author).

thanks.rust-lang.org basically dumps all author names without giving
zero context. Contributor A might just a fix a typo or contribute a
non-trivial feature. There is no way to figure it out without doing
some research.

Instead, everyone who reads our changelog at
https://docs.python.org/3/whatsnew/changelog.html can see what
Contributor A exactly contributed to Python.

"Patch by" marker is already documented at
https://devguide.python.org/committing/#what-s-new-and-news-entries
and it's not hard to ask the contributor to add it. I usually add it
myself in less than a minute.

--Berker
___
core-workflow mailing list -- core-workflow@python.org
To unsubscribe send an email to core-workflow-le...@python.org
https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/
This list is governed by the PSF Code of Conduct: 
https://www.python.org/psf/codeofconduct

Re: [core-workflow] Final chance to express opinion on history rewrite for issue #s

[Berker Peksağ]

On Fri, Feb 10, 2017 at 9:08 PM, Berker Peksağ <berker.pek...@gmail.com> wrote:
> +1, I've already started to write an extension and I'm converting the
> regex to JS flavor now so thanks again Senthil and Ezio!

Just an FYI, first version of the extension can be found at
https://github.com/berkerpeksag/cpython-bpo-linkify It's not perfect,
but it does its job for now :) Feel free send bug reports, suggestions
and pull requests.

--Berker
___
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinfo/core-workflow
This list is governed by the PSF Code of Conduct: 
https://www.python.org/psf/codeofconduct

Re: [core-workflow] Final chance to express opinion on history rewrite for issue #s

[Berker Peksağ]

On Fri, Feb 10, 2017 at 8:51 PM, Brett Cannon  wrote:
> In the end I decided NOT to do the history mutation/rewrite basically
> because I didn't discuss this with python-committers ahead of time (so it's
> entirely my fault this didn't go forward). The history of this repo -- along
> with the code -- is collectively owned by all of the people who have
> contributed to it. The idea of mutating the history like this was not
> discussed with the stakeholders/contributors of that history ahead of time
> and thus I don't feel it is my place to unilaterally muck with it without
> having a proper discussion ahead of time (I unfortunately didn't have this
> thought until this morning). While I realize I have been given the rights to
> change our workflow, none of these changes are permanent (as our regular
> changes to it show :) . But changing the history is permanent and thus a
> much heftier thing to do with the dictatorial powers I have for this
> migration.
>
> Had I thought to reach out ahead of time then it's possible I could have
> gotten the permission necessary. But since leaving this as-is doesn't hurt
> anything (thanks to GH doing the linking eagerly and thus not picking up any
> of the issue numbers that pre-exist), I felt it was better to err on the
> side of caution and not upset people by springing this on them.
>
> Obviously a huge thanks to Senthil and Ezio for giving this a go. The regex
> will be useful for anyone who wants to write a browser plug-in to add the
> automatic linking so I don't view the work as wasted.

+1, I've already started to write an extension and I'm converting the
regex to JS flavor now so thanks again Senthil and Ezio!

--Berker
___
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinfo/core-workflow
This list is governed by the PSF Code of Conduct: 
https://www.python.org/psf/codeofconduct

Re: [core-workflow] Final chance to express opinion on history rewrite for issue #s

[Berker Peksağ]

On Fri, Feb 10, 2017 at 5:00 PM, Senthil Kumaran  wrote:
> If any of you were -1 yesterday and you changed your mind after seeing
> the results, please take chance to explicitly toggle your vote.

Count me as +1.

--Berker
___
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinfo/core-workflow
This list is governed by the PSF Code of Conduct: 
https://www.python.org/psf/codeofconduct

Re: [core-workflow] Choosing a prefix/label for issue numbers

[Berker Peksağ]

On Wed, Feb 8, 2017 at 9:03 PM, Senthil Kumaran  wrote:
> _If we decide to rewrite_, I see the following areas of improvement.
>
> 1) Rename #, Issue #, issue #, Issue, issue to bpo-
> 2) Looking for numbers 1000 and above which don't start with SF, is
> okay with me as it can reduce the false positives.

Count me as -1 for history rewrite. There are many different commit
message styles and we probably will miss some edge cases :)

> Also, other feedback from Martin was to not have hg branch annotation.
> E.g: https://github.com/orsenthil/cpython-migration-test/commit/851c48a
>
> That can be removed. I am unable to decide on the merits/de-merits.
> hg-git tool seems to be doing that commit extra messages by default.
> The annotation gives information that commit was originally done in
> that particular hg branch.

+1 for removing the branch annotation. +0 if there is no easy way to do it.

Thank you for working on this, Senthil!

--Berker
___
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinfo/core-workflow
This list is governed by the PSF Code of Conduct: 
https://www.python.org/psf/codeofconduct

Re: [core-workflow] Choosing a prefix/label for issue numbers

[Berker Peksağ]

On Thu, Feb 2, 2017 at 1:33 AM, Ned Deily  wrote:
> On Feb 1, 2017, at 16:35, Brett Cannon  wrote:
>> On Wed, 1 Feb 2017 at 12:23 Ned Deily  wrote:
>>> Perhaps I'm misunderstanding something. Are we planning to alter existing 
>>> commit messages as part of the hg to fit transition?
>> No, we are not mucking with the history as part of the transition.
>
> Sorry, I don't mean to resurrect any old discussions that I've forgotten 
> about here but, just to be clear, that means that we will no longer be able 
> to click through from the web pages of the tens of thousands of old commits 
> back to their corresponding bug web pages as we can do today?
>
> For example, https://hg.python.org/cpython/rev/aa7ac93d23b2 (eventually) 
> links back to https://bugs.python.org/issue20185 (at least it should if the 
> SSL certificate weren't expired today), whereas the corresponding git commit 
> (https://github.com/python/cpython/commit/9f889393ab0362229c42bc31056f3ef9735a1d27)
>  does not and will not provide a link back?  That's ... unfortunate.

Correct, but that can be solved by using a small browser extension. I
once wrote an extension that automatically generates
bugzilla.mozilla.org/show_bug.cgi?id= links for "Bug " markers
on GitHub.

--Berker
___
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinfo/core-workflow
This list is governed by the PSF Code of Conduct: 
https://www.python.org/psf/codeofconduct

Re: [core-workflow] Planning the GitHub migration

[Berker Peksağ]

On Wed, Feb 1, 2017 at 1:43 AM, Brett Cannon <br...@python.org> wrote:
>
>
> On Tue, 31 Jan 2017 at 14:01 Berker Peksağ <berker.pek...@gmail.com> wrote:
>>
>> On Tue, Jan 31, 2017 at 2:21 AM, Brett Cannon <br...@python.org> wrote:
>> > Update docs.python.org to build from GitHub (push
>> > https://github.com/python/psf-salt/pull/91; Berker?)
>>
>> I can review and test this on my development environment, but we
>> probably need someone from the infra team to do the merging :)
>
>
> I've emailed them to see if there's anything I can do to make it easier for
> them.

Thanks! I don't think I have commit rights to that repo so hopefully
they will only need to press the merge button :)

--Berker
___
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinfo/core-workflow
This list is governed by the PSF Code of Conduct: 
https://www.python.org/psf/codeofconduct

Re: [core-workflow] Planning the GitHub migration

[Berker Peksağ]

On Tue, Jan 31, 2017 at 2:21 AM, Brett Cannon  wrote:
> Update docs.python.org to build from GitHub (push
> https://github.com/python/psf-salt/pull/91; Berker?)

I can review and test this on my development environment, but we
probably need someone from the infra team to do the merging :)

--Berker
___
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinfo/core-workflow
This list is governed by the PSF Code of Conduct: 
https://www.python.org/psf/codeofconduct

Re: [core-workflow] Github Mirrors - Should Disallow Pull Request / Issue Creation Until the migration

[Berker Peksağ]

On Sun, Jul 10, 2016 at 4:33 PM, Senthil Kumaran  wrote:
> On Sun, Jul 10, 2016 at 12:15 AM, Nick Coghlan  wrote:
>>
>> I don't see any problem with doing that early - we already carry a 
>> .gitignore file for the benefit of folks using hg-git bridges, so if we 
>> wanted to start experimenting with GitHub workflows (including things like 
>> Travis CI), why gate that on actually doing the migration first if we can 
>> use the existing mirrors for it?
>
>
> I am in favor of introducing this before the migration. It seems like
> an easy thing to setup without any clutter to the existing setup.
> For e.g, for the pull request template,  We can have the
> PULL_REQUEST_TEMPLATE.md as suggested by Carol inside a .github
> directory in hg repo and communicate our intention.  That should
> address one of the points in this thread.

I'm not sure how that would solve the main problem: People do not like
to read project descriptions and contribution guides :) python/cpython
description already states that it's a read-only mirror of the
Mercurial repository and it took me a second to realize that
python-git/python is a way outdated mirror of the old SVN repository.

I'd propose to set a webhook that will close all pull requests
automatically (with a short informative message) on python/cpython.
I'm planning to finish my merge bot this month so I can write a simple
webhook quickly if needed.

--Berker
___
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinfo/core-workflow
This list is governed by the PSF Code of Conduct: 
https://www.python.org/psf/codeofconduct

Re: [core-workflow] Presentation on Rust's GitHub based automation tools

[Berker Peksağ]

On Sun, Feb 7, 2016 at 9:21 AM, Nick Coghlan  wrote:
> I was at linux.conf.au 2016 last week, and one of the presentations
> was from Mozilla's Emily Dunham on some of the infrastructure
> automation they use with Rust and other GitHub based projects:
> https://www.youtube.com/watch?v=dIageYT0Vgg

I just watched it, great talk. Thanks for sharing!

> In addition to their merge bot project homu (which we've talked about
> previously), they also have:
>
> highfive (a greeter bot): https://github.com/nrc/highfive

This is a good idea.

> starters (an issue curator): https://starters.servo.org/
>
> While these wouldn't necessarily be something we wanted to set up
> immediately, it likely makes a lot of sense to try to share the tool
> maintenance load with Mozilla rather than going for a completely
> custom setup.

The biggest problem of these tools is that they don't provide an API
or a framework to use as a base. They have a lot of project specific
code and they don't work on Python 3. So you'll need to write your own
code anyway. We are going to write a lot of bots in the next months so
I think we will eventually create some sort of framework to share some
code.

Coordinating with Mozilla (or any other organization) requires a big
amount of time, and I simply don't have enough time and motivation
right now. However, I'm planning to send an email to the
django-developers list [1] when I finish to document my bot. I have a
test organization at https://github.com/fayton. See also
https://github.com/fayton/cpython/pull/1 for an example pull request
(the name of the bot is just a placeholder, Brett will give it a name
:))

--Berker

[1] They might be interested since we (will) have almost identical
workflow with them (they also have multiple maintenance branches for
example)
___
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinfo/core-workflow
This list is governed by the PSF Code of Conduct: 
https://www.python.org/psf/codeofconduct

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

[Berker Peksağ]

On Thu, Jan 7, 2016 at 8:40 PM, Ezio Melotti  wrote:
> The goal is to generate at least 1 message/email if a review (possibly
> comprising several comments) is posted.
> If there are no new comments, nothing is posted, but if there are new
> comments, a new message will be posted at some point.
> We just need to find a compromise between delay and number of messages
> (and that's something we can figure out later with a bit of trial and
> error).
> Checking daily might result in hours of delay, but no more than one
> daily message.
> Checking hourly has less delay, but it might result in more messages.
> We can also try to do something smarter by checking e.g. every 15
> minutes and posting the message only if no new messages have been
> added in the last 15 minutes (so the reviewer has likely finished
> commenting).

I think this still will create too much noise. I'd prefer not to see
comments like "this needs to be tested", "needs versionadded", "please
don't change function signature" etc. in issues. I like following
Windows and IDLE issues, but I'm not really interested seeing review
comments about them, for example. Wouldn't a new pull request field in
the issue detail page be enough to link pull requests? Django uses a
similar solution to this: https://code.djangoproject.com/ticket/25995
(see "Pull Requests: 5928 build:success") We could show total number
of comments too.
___
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinfo/core-workflow
This list is governed by the PSF Code of Conduct: 
https://www.python.org/psf/codeofconduct

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

[Berker Peksağ]

On Tue, Jan 5, 2016 at 8:13 PM, Brett Cannon  wrote:
> Day 1 summary
> 
>
> Decisions made
> ---
> - We will create a python-dev team in the python org and add that team to
> all of the relevant repos that get migrated
> - We will add a GitHub field to Roundup and then write/get a CLA bot that
> will query Roundup to check if someone has (not) signed the CLA
> - For ancillary repos, the merge-of-least-resistance workflow is fine, so no
> need to worry about maintaining a linear history
> - We are going to keep all of the cpython history in a single repo
> - We will have PRs go against master and then we will cherry pick into
> bugfix branches
> - Misc/ACKS will be kept and we will write code to update it on occasion --
> probably at release time -- based on git commit data
> - Seems like our current commit ID -> URL service can be updated to handle
> our transition
>
>
> Open issues
> ---
> - What tools and commands will we use to convert the repos?
> - How do we want to handle Misc/NEWS?
> - What are the exact commands we are going to expect core devs to run (which
> will be documented in the devguide)?

I use the following commands for python.org:

$ git pr NNN

"git pr" is an alias and an equivalent of

$ git fetch upstream pull/NNN/head:pr/NNN
$ git checkout pr/NNN

For example, if I want to review
https://github.com/python/pythondotorg/pull/859, I use "git pr 859".

Run tests, tweak commit message, code style, and commit

$ git commit -m "Update foo bar"

Squash commits

$ git rebase -i HEAD~2

And merge

   $ git checkout master
   $ git merge --ff-only pr/NNN

(--ff-only can be added to .gitconfig)

Backport to 3.5 (the branch name is "release" for python.org)

   $ git checkout 3.5
   $ git cherry-pick `git rev-parse master`

And push to upstream

   $ git push --all upstream

We probably should mention the -u option (or create a new section for
Git configuration and best practices) in the devguide.

> - Who to use for CI (although Donald is the only one to speak up and likes
> Travis as do I, so this might be decided)?

+1 to use Travis as a pre-merge CI. I'd vote for keeping Travis
configuration simple (e.g. use only Linux and GCC, run rstlint in
Doc/)

--Berker
___
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinfo/core-workflow
This list is governed by the PSF Code of Conduct: 
https://www.python.org/psf/codeofconduct

Re: [core-workflow] We will be moving to GitHub

[Berker Peksağ]

On Sun, Jan 3, 2016 at 12:35 AM, Ezio Melotti  wrote:
> On Sat, Jan 2, 2016 at 8:45 PM, Brett Cannon  wrote:
>> Basically a way to map an issue to a PR (or vice-versa). Probably the
>> simplest solution is to allow pasting in a GitHub PR URL or the PR # to make
>> the association. The other option is for the bot to accept a command to make
>> the association. No reason we can't have both, though. But either way we
>> should have a way to connect PRs to issues.
>>
>
> I'll have to think a bit about the best way to implement this and the
> UI (I already have some ideas).

This can be done without a bot. We just need a webhook server to
listen pull_request[1] events. If the action type of the event is
"opened" and the pull request title contains "Issue #", we can
communicate with the new Roundup detector. I don't know how the
Roundup part works, though.

[1] https://developer.github.com/v3/activity/events/types/#pullrequestevent

> There's also another point that I haven't seen being discussed: how we
> will handle the author and the committer fields.
> Currently we only know the committer so, while migrating to git, this
> can either be duplicated in the author field or just preserved in the
> committer field leaving the author field empty.  Afterwards we can
> start using the two fields for what they are meant for.
> A possible problem is how to update them when commits/merges are
> performed by bots (e.g. if b.p.o automatically converts a patch into a
> pull request, or if a core dev merges a patch by clicking on a
> button).  Perhaps someone more familiar with Git/GitHub can clarify
> this (I think it's possible to specify author/committer manually, but
> I don't know how GitHub handles it on its side).

There is no way to store both contributor and committer information
via GitHub's web interface. It can be done either manually in terminal
or a bot can temporarily set GIT_COMMITTER_NAME and
GIT_COMMITTER_EMAIL env variables before doing fast-forward merge (we
can get the core developer's name and email address from
https://developer.github.com/v3/issues/comments/ and
https://developer.github.com/v3/users/)
___
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinfo/core-workflow
This list is governed by the PSF Code of Conduct: 
https://www.python.org/psf/codeofconduct

Re: [core-workflow] Questions about the proposed workflows

[Berker Peksağ]

On Wed, Dec 2, 2015 at 1:24 AM, Brett Cannon  wrote:
> It's Dec 1, which means it's time for any questions people have about the
> proposed workflows so we can get answers by Dec 15.
>
> I have one question that applies to both proposals and one specific to
> GitLab. The general one is whether both Guido and me can both be happy. :)
> Guido doesn't want intermediate commits nor what he calls "merge turds" to
> show up in the history. I want to be able to do merges from the browser. Do

I agree with Guido. --no-ff merge is probably the only GitHub feature
that I really dislike. It would be good to have a GitHub bot to handle
ff merges.

For example, with a bot, a core developer can add one of the following
comments to merge the PR;

@biggles merge  # merges into master

@biggles merge 3.5+  # merges into 3.5 and master (or merges into
master then cherry-pick it to 3.5)

This will also solve the pull request and email flood problem since a
contributor won't have to open N pull requests if their patch needs to
be backported to maintenance branches.

I will have some spare time to work on such a tool in the next months.

--Berker
___
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinfo/core-workflow
This list is governed by the PSF Code of Conduct: 
https://www.python.org/psf/codeofconduct