I only started to use the new workflow today. And I think that the new rules
are too restrictive. Enforcing checking and reviews and approvals is a
right thing, but what we have now feels like too much.
I feel like a lot of bug fixes will have to be backported. With the
current rules I have to o
You no longer need approval from someone else and you can open a cherry-pick PR
prior to merging if you want.
Sent from my iPhone
> On Mar 2, 2017, at 6:31 PM, Yury Selivanov wrote:
>
> I feel like a lot of bug fixes will have to be backported. With the
> current rules I have to open a new PR
Hi Yuri,
On Thu, Mar 2, 2017 at 3:31 PM, Yury Selivanov wrote:
> I only started to use the new workflow today. And I think that the new rules
> are too restrictive. Enforcing checking and reviews and approvals is a
> right thing, but what we have now feels like too much.
You are actually experi
On 2017-03-02 6:40 PM, Senthil Kumaran wrote:
Hi Yuri,
On Thu, Mar 2, 2017 at 3:31 PM, Yury Selivanov wrote:
I only started to use the new workflow today. And I think that the new rules
are too restrictive. Enforcing checking and reviews and approvals is a
right thing, but what we have now
On 2017-03-02 6:36 PM, Donald Stufft wrote:
You no longer need approval from someone else and you can open a cherry-pick PR
prior to merging if you want.
OK, thanks for the clarification! Will try it later today.
Thank you,
Yury
___
core-workflow
One thing I forgot to mention is that cherry picking before a merge might
result in more overall work if someone does review your original PR and it ends
up causing changes since you'll need to pull those changes into each backport
PR too.
Sent from my iPhone
> On Mar 2, 2017, at 6:44 PM, Yur
On 2017-03-02 6:36 PM, Donald Stufft wrote:
You no longer need approval from someone else and you can open a cherry-pick PR
prior to merging if you want.
But I still can't push a cherry-picked commit without a PR for it?
Yury
___
core-workflow mai
Correct. Everything goes through a PR now. Ideally we will automate PRs for
backports.
Sent from my iPhone
> On Mar 2, 2017, at 7:00 PM, Yury Selivanov wrote:
>
>
>
>> On 2017-03-02 6:36 PM, Donald Stufft wrote:
>> You no longer need approval from someone else and you can open a cherry-pick
I'm on my phone but unless Travis is backed up it sounds like something got
lost somewhere. Multi hour waits is not typical.
Sent from my iPhone
> On Mar 2, 2017, at 7:07 PM, Yury Selivanov wrote:
>
> Well, I guess my only complaint about this is that Travis is extremely slow.
> I've been wa
The discussion of automating the creation of cherry-pick PRs is at
https://github.com/python/core-workflow/issues/8. And the requirement of
the PR is to force people to go through CI to verify the cherry-pick took
cleanly (and the Travis config is structured to only run the test suite if
the PR cha
On 2017-03-02 7:01 PM, Donald Stufft wrote:
Correct. Everything goes through a PR now. Ideally we will automate PRs for
backports.
Got it.
Well, I guess my only complaint about this is that Travis is extremely
slow. I've been waiting a couple of hours for my PR to pass the check
(and it's
On 2017-03-02 7:11 PM, Donald Stufft wrote:
I'm on my phone but unless Travis is backed up it sounds like something got
lost somewhere. Multi hour waits is not typical.
Travis is overloaded a little bit at the moment. It looks like it takes
it 20-30 minutes to fully test one PR. And it loo
On 2017-03-02 7:06 PM, Brett Cannon wrote:
The discussion of automating the creation of cherry-pick PRs is at
https://github.com/python/core-workflow/issues/8. And the requirement of
the PR is to force people to go through CI to verify the cherry-pick took
cleanly (and the Travis config is stru
On Thu, 2 Mar 2017 at 16:16 Yury Selivanov wrote:
>
>
> On 2017-03-02 7:11 PM, Donald Stufft wrote:
> > I'm on my phone but unless Travis is backed up it sounds like something
> got lost somewhere. Multi hour waits is not typical.
>
> Travis is overloaded a little bit at the moment. It looks lik
14 matches
Mail list logo
