> On Thu, 12 Dec 2019 22:31:10 +0100,
> Dr Paul Dale wrote:
> >
> > A red blocker along the lines of: "Triviality Unconfirmed". One of
> > the reviewers needs to remove this before the PR can be merged.
> >
> > It's in our face, it prevent accidental merges and its low overhead.
>
> I still thin
A better example of this problem: #10607. Both Paul and I approved it
yesterday and I merged it today without noticing until too late that it was
tagged “CLA: trivial” :(
I’ve not reverted it at this point but will if necessary.
Let’s get the label in.
Pauli
--
Dr Paul Dale | Distinguished A
On Thu, 12 Dec 2019 22:31:10 +0100,
Dr Paul Dale wrote:
>
> A red blocker along the lines of: “Triviality Unconfirmed”. One of
> the reviewers needs to remove this before the PR can be merged.
>
> It’s in our face, it prevent accidental merges and its low overhead.
I still think simply adding th
On Thu, 12 Dec 2019 12:15:30 +0100,
Dr. Matthias St. Pierre wrote:
>
> As for a possible semi-automated solution:
>
> The problem is more fundamental: currently both the GitHub bot and
> the git commit hook only watch out for the 'CLA: trivial' marker.
Correct re the clacheck hook (that's the Gi
On Thu, 12 Dec 2019 13:06:33 +0100,
Dr. Matthias St. Pierre wrote:
>
> > > The server-side commit hook ensures that
> > >
> > > - the "CLA: trivial" annotation is present in *all* commits of the PR if
> > > and only if the [cla: trivial]
> > > label is set.
> > > - the [cla: ok] label is set if
On 12/12/2019 21:31, Dr Paul Dale wrote:
> A red blocker along the lines of: “Triviality Unconfirmed”. One of the
> reviewers needs to remove this before the PR can be merged.
>
> It’s in our face, it prevent accidental merges and its low overhead.
Sounds workable.
Matt
>
>
> Pauli
> --
>
Great idea.
пт, 13 дек. 2019 г., 0:31 Dr Paul Dale :
> A red blocker along the lines of: “Triviality Unconfirmed”. One of the
> reviewers needs to remove this before the PR can be merged.
>
> It’s in our face, it prevent accidental merges and its low overhead.
>
>
> Pauli
> --
> Dr Paul Dale | Di
A red blocker along the lines of: “Triviality Unconfirmed”. One of the
reviewers needs to remove this before the PR can be merged.
It’s in our face, it prevent accidental merges and its low overhead.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031
Before we start over engineering a solution, how about we try just having an
automatic visual indicator for trivial PRs.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 13 Dec 2019, at 3:24 am, Kurt Roeckx wrote:
>
>
On Thu, Dec 12, 2019 at 12:10:35PM +, Matt Caswell wrote:
>
> But in principle I agree that addrev could be used to do this. It's not
> quite as robust as doing it in the commit hook - because you don't
> *have* to use addrev. But, AFAIK, everyone does - so that's probably
> good enough.
I ha
Dear Matt,
On Thu, Dec 12, 2019 at 1:25 PM Matt Caswell wrote:
>
> On 12/12/2019 09:29, Dmitry Belyavsky wrote:
> > - the contributor agreed to sign the CLA and
> > - there was a mark that CLA is signed and
> > - all the necessary approves were present
> > I decided that there is no problem to m
On 12/12/2019 12:06, Dr. Matthias St. Pierre wrote:
>>> The server-side commit hook ensures that
>>>
>>> - the "CLA: trivial" annotation is present in *all* commits of the PR if
>>> and only if the [cla: trivial]
>>> label is set.
>>> - the [cla: ok] label is set if and only if the CLA is on
> > The server-side commit hook ensures that
> >
> > - the "CLA: trivial" annotation is present in *all* commits of the PR if
> > and only if the [cla: trivial]
> > label is set.
> > - the [cla: ok] label is set if and only if the CLA is on file
> > - the pull request is accepted only if the [cl
On 12/12/2019 11:15, Dr. Matthias St. Pierre wrote:
>
>> On 12/12/2019 09:43, Paul Yang wrote:
>>> Would it be better if 'CLA: trivial’ is in the commit message but no CLA
>>> on file, then a new label like ’warn: no CLA but trivial’ is added? This
>>> can inform the committer who will merge th
> On 12/12/2019 09:43, Paul Yang wrote:
> > Would it be better if 'CLA: trivial’ is in the commit message but no CLA
> > on file, then a new label like ’warn: no CLA but trivial’ is added? This
> > can inform the committer who will merge the PR for the CLA condition of
> > the commits.
> >
>
> Ye
On 12/12/2019 09:43, Paul Yang wrote:
> Would it be better if 'CLA: trivial’ is in the commit message but no CLA
> on file, then a new label like ’warn: no CLA but trivial’ is added? This
> can inform the committer who will merge the PR for the CLA condition of
> the commits.
>
Yes, I think th
It seems we have the same thoughts...
Regards,
Paul Yang
> On Dec 12, 2019, at 5:36 PM, Dr Paul Dale wrote:
>
> I agree that there is a possible flaw in the workflow. What’s saved us so
> far is that new contributors don’t generally include the "CLA: trivial" line
> or put it in the GitHub
Would it be better if 'CLA: trivial’ is in the commit message but no CLA on
file, then a new label like ’warn: no CLA but trivial’ is added? This can
inform the committer who will merge the PR for the CLA condition of the commits.
Regards,
Paul Yang
> On Dec 12, 2019, at 5:29 PM, Dmitry Belya
I agree that there is a possible flaw in the workflow. What’s saved us so far
is that new contributors don’t generally include the "CLA: trivial" line or put
it in the GitHub text.
Could we have a “trivial” tag that is added whenever the "CLA: trivial" line is
present? Better would be to add
Dear Matt,
As
- the contributor agreed to sign the CLA and
- there was a mark that CLA is signed and
- all the necessary approves were present
I decided that there is no problem to merge.
BTW, I am not sure the PR was trivial enough.
Anyway, the responsibility was mine, not the git one :)
On T
I notice that PR 10594 (Add support for otherName:NAIRealm in output)
got merged yesterday:
https://github.com/openssl/openssl/pull/10594
The commit description contained "CLA: trivial" and so the "hold: cla
required" label was not automatically applied to the PR. But the
discussion in the PR sugg
21 matches
Mail list logo
