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
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
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,
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
>
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:
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 --
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
___
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
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
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.
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
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
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:
>
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
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
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
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
17 matches
Mail list logo