Ok, no problem, let's say that a core dev should not merge a PR written by
another core dev.
In fact, I was already following this rule. I hesitated many times to click
on Merge, but I wanted first to open a discussion. Here we are :-)
Obvious, the good practice is to put as many approval as pos
середа, 20 вересня 2017 р. 23:27:49 EEST Victor Stinner написано:
> My question is: is someone opposed that a core developer clicks on the
> [Merge] button for a PR proposed by a different core developer?
I'm opposed. The author can be more acquainted with the writing code than
reviewers. The aut
It's funny. At Dropbox, engineers *have* to merge their own work (we call
it "landing"). When I first got to use GitHub (for asyncio, IIRC) I could
land other people's patches once I approved of them. That was very
satisfying, and felt like the "better" workflow, and we adopted this for
mypy. Cases
On Sep 20, 2017, at 20:54, Nick Coghlan wrote:
>
> On 21 September 2017 at 07:27, Victor Stinner
> wrote:
>> Hi,
>>
>> Before the GitHub era, in the old "Mercurial era", the unwritten rule
>> was to not merge a patch written by a developer who has the commit
>> bit, to not "steal" his/her work
On 21 September 2017 at 07:27, Victor Stinner wrote:
> Hi,
>
> Before the GitHub era, in the old "Mercurial era", the unwritten rule
> was to not merge a patch written by a developer who has the commit
> bit, to not "steal" his/her work. The old workflow (patches attached
> to the bug tracker) did
On Wed, Sep 20, 2017 at 11:27 PM, Victor Stinner
wrote:
> Hi,
>
> Before the GitHub era, in the old "Mercurial era", the unwritten rule
> was to not merge a patch written by a developer who has the commit
> bit, to not "steal" his/her work. The old workflow (patches attached
> to the bug tracker)
On Thu, Sep 21, 2017 at 12:27 AM, Victor Stinner
wrote:
> Hi,
>
> Before the GitHub era, in the old "Mercurial era", the unwritten rule
> was to not merge a patch written by a developer who has the commit
> bit, to not "steal" his/her work. The old workflow (patches attached
> to the bug tracker)
On Wed, Sep 20, 2017 at 2:49 PM, Victor Stinner
wrote:
> > I think it's a good idea in many cases, but not required.
>
> I'm not sure that I understood correctly, what is a good idea? To
> merge the PR if I consider that it's now good enough to be merged?
>
Sorry, yes.
> E.g. you may be OK
> >
> I think it's a good idea in many cases, but not required.
I'm not sure that I understood correctly, what is a good idea? To
merge the PR if I consider that it's now good enough to be merged?
> E.g. you may be OK
> with the diff but still ask the author to clean up some small nits, and then
> th
On Wed, Sep 20, 2017 at 2:27 PM, Victor Stinner
wrote:
> Before the GitHub era, in the old "Mercurial era", the unwritten rule
> was to not merge a patch written by a developer who has the commit
> bit, to not "steal" his/her work. The old workflow (patches attached
> to the bug tracker) didn't a
Hi,
Before the GitHub era, in the old "Mercurial era", the unwritten rule
was to not merge a patch written by a developer who has the commit
bit, to not "steal" his/her work. The old workflow (patches attached
to the bug tracker) didn't allow to easily keep the author. You had to
find the author e
11 matches
Mail list logo