Re: Re-requesting reviews on GitHub
On 30.10.19 10:14, Richard Levitte wrote: This is a good idea, and also a detectable event for a bot to listen to. Sounds like an excellent idea: If approvals and dismissals of approvals (resp. re-review requests) are all bot events, then the bot should be able to handle most state changes automatically, including the determination whether a normal or an omc review is required. This would be a great ease for the reviewer's workflow. Matthias
Re: Re-requesting reviews on GitHub
I think its a good idea. It would prevent issues like https://github.com/openssl/openssl/pull/9501 Patrick
Re: AW: Confirmed bug labels
On 29/10/2019 12:34, Matt Caswell wrote: > > > On 29/10/2019 12:24, Matthias St. Pierre wrote: >> >> It might be useful to add more reasons for why the issue is resolved. >> OTOH we should watch out that we don't create too many labels. >> >> "resolved: fixed" >> "resolved: answered" > > Not sure about the "resolved: fixed" one...most of the time where we > resolve an issue by fixing it, it gets closed automatically. Adding a > label probably doesn't add much. I suppose it might be useful in the > case where someone reports a bug that is *already* fixed in a later version. I found myself needing to use "resolved: answered" so I added it. Matt
Re: Re-requesting reviews on GitHub
This is a good idea, and also a detectable event for a bot to listen to. Cheers Richard "Dr. Matthias St. Pierre" skrev: (30 oktober 2019 09:30:11 CET) >> Independently of the new 'approval: *' state labelling I was >wondering whether it wouldn't >> be a good idea to adopt the habit of explicitly requesting a >re-review from the other reviewers >> after significant changes, using the mechanism provided by GitHub >(i.e. the button with the two > >To be more precise: not all reviews need to be invalidated by >requesting a re-review, only the approvals. -- Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.
AW: Re-requesting reviews on GitHub
> Independently of the new 'approval: *' state labelling I was wondering > whether it wouldn't > be a good idea to adopt the habit of explicitly requesting a re-review from > the other reviewers > after significant changes, using the mechanism provided by GitHub (i.e. the > button with the two To be more precise: not all reviews need to be invalidated by requesting a re-review, only the approvals.
Re-requesting reviews on GitHub
Independently of the new 'approval: *' state labelling I was wondering whether it wouldn't be a good idea to adopt the habit of explicitly requesting a re-review from the other reviewers after significant changes, using the mechanism provided by GitHub (i.e. the button with the two circling arrows next to the reviewer entry). In that way, outdated reviews would become more visible, and outdated reviews wouldn't be addrev'ed to the commit message when merging, unless they are renewed before the 24h grace period expires. For nit changes, the current informal way of re-approval could be kept of course. What's your opinion? Matthias