I have always implicitly assumed Matt view, but I am happy to conform to
what the consensus is.
I believe this discussion is very useful and could contribute a new entry
in the commiter guidelines.
Nicola
On Fri, May 24, 2019, 07:21 Matt Caswell wrote:
>
>
> On 24/05/2019 15:10, Richard Levitt
I forgot one word:
On 24.05.19 17:45, Matthias St. Pierre wrote:
(Otherwise, the missing approvers need to be from the Reviewed-by list
and additional approvals would be needed).
need to be _removed_ from the Reviewed-by list
On 24.05.19 16:54, Richard Levitte wrote:
On Fri, 24 May 2019 16:39:51 +0200,
Matt Caswell wrote:
On 24/05/2019 15:30, Richard Levitte wrote:
Not in practice. We *do* ask on the PR in question if it should be
cherry-picked to 1.1.1 and seek approval for that action, but then it
hasn't at
On Fri, 24 May 2019 16:39:51 +0200,
Matt Caswell wrote:
>
>
>
> On 24/05/2019 15:30, Richard Levitte wrote:
> >
> > Not in practice. We *do* ask on the PR in question if it should be
> > cherry-picked to 1.1.1 and seek approval for that action, but then it
> > hasn't at all been clear what sho
On 24/05/2019 15:30, Richard Levitte wrote:
> On Fri, 24 May 2019 16:20:59 +0200,
> Matt Caswell wrote:
>> On 24/05/2019 15:10, Richard Levitte wrote:
>>> If we go with the idea that an approval also involves approving what
>>> branches it goes to, then what happens if someone realises after som
On Fri, 24 May 2019 16:20:59 +0200,
Matt Caswell wrote:
> On 24/05/2019 15:10, Richard Levitte wrote:
> > If we go with the idea that an approval also involves approving what
> > branches it goes to, then what happens if someone realises after some
> > time that a set of commits (a PR) that was app
Hello,
On Fri, May 24, 2019 at 5:21 PM Matt Caswell wrote:
>
> On 24/05/2019 15:10, Richard Levitte wrote:
> > If we go with the idea that an approval also involves approving what
> > branches it goes to, then what happens if someone realises after some
> > time that a set of commits (a PR) that
On 24/05/2019 15:10, Richard Levitte wrote:
> Not sure I see it as picking nits, it's rather about some fundamental
> difference in what we thinking we're approving, and how we actually
> act around that.
>
> My idea has always been that I approve a code change, i.e. essentially
> a patch or a
Not sure I see it as picking nits, it's rather about some fundamental
difference in what we thinking we're approving, and how we actually
act around that.
My idea has always been that I approve a code change, i.e. essentially
a patch or a set of patches, without regard for exact branches it ends
u
Matt and Richard, I think you are mixing up cherry-picking and nit-picking
here. (Sorry for the pun ;-)
Matthias
> To be picky, may I assume that you meant a reviewed-by tag for you
> > should be *added*? The commit itself (its contents) having been
> > reviewed by those already there, I cannot
10 matches
Mail list logo
