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

2018-09-05 Thread 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

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

2018-08-30 Thread 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

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

2018-07-22 Thread 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,

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

2017-11-27 Thread 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 >

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

2017-02-11 Thread 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:

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

2017-02-10 Thread 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 --

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

2017-02-10 Thread 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 ___

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

2017-02-08 Thread 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

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

2017-02-01 Thread 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

Re: [core-workflow] Planning the GitHub migration

2017-01-31 Thread 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.

Re: [core-workflow] Planning the GitHub migration

2017-01-31 Thread 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

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

2016-07-10 Thread 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

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

2016-02-07 Thread 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: >

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

2016-01-07 Thread 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

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

2016-01-05 Thread 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

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

2016-01-02 Thread 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

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

2015-12-02 Thread 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