OTC quick votes [WAS: RE: OTC vote PR #16171: config_diagnostic]
Tim Hudson
tjh at cryptsoft.com
Sun Aug 29 19:53:42 UTC 2021
You cannot meaningfully vote on the PR without reviewing it. It is that
simple. There is zero point in providing details beyond that as the PR is
the details. The subject of the PR doesn't remove the need to read the
details to form a view.
The commentary on the PR and the code itself is what needs to be reviewed
in order to form a view point - and that journey needs to be gone through
if you want to offer a meaningful opinion on a PR.
Any attempt to make a decision based on any form of summary of a PR is
completely missing the point of participation in the review process - you
might as well toss a coin to form your vote if you aren't going to look at
the actual details.
Reviewing the code changes and the comments is what is necessary for that
purpose and the PR itself is where we want any additional comments to be
made.
Remember that this context is where and OTC member has placed a hold on a
PR for a discussion and decision to be made and there is no clear consensus
in the OTC meeting on the path forward or any OTC member wants a formal
decision made for whatever reason. There is always a discussion prior to
the vote being called.
A substantial portion of the PRs result in one or more OTC member
acknowledging that the didn't realise the PR meant what it means from
having seen its title or summary description - and actually having to read
the full commentary *and* the code to understand the context was absolutely
necessary.
Remember that someone has gone to the effort generally of raising and issue
and the creating a proposed solution in a PR and multiple people have
looked at it and provided feedback and one or more of them decided that we
need a decision made for some reason (and those reasons widely vary). To
make an informed decision reasonably requires reviewing all that
information to form a view.
There is no short cut to reading the PR itself and the vote text reflects
that reality.
In our OTC meetings we review the issues and review the PRs and we do that
by going through the details - not by working off the title of the issue or
PR.
If you want to only comment on PRs off a summary list then go to GitHub and
use its summary views to get that.
We could perhaps even add another label with OTC vote pending which might
get close to what you want in a single GitHub view.
It won't avoid the need to actually read the details to be able to form a
view prior to voting.
Tim.
On Sun, 29 Aug 2021, 22:35 Kurt Roeckx, <kurt at roeckx.be> wrote:
> I currently fail to see why you can't describe in words what you
> intend to fix. The PR itself has a subject, so have the commits.
>
> One of the reasons we have this vote is public is so that people
> reading this list can comment on it. Just some number doesn't tell
> them anything without having to go and look it up and spend time
> trying to understand. A simple summary of what we intend to vote
> on will help them understand if they want to look at this or not.
>
> If you feel that it should not be part of the vote text, can we at
> least have some introduction text?
>
> For instance PR 16203 was about adding the TLS 1.3 KDF. I can see
> several vote text for that:
> - Add the TLS 1.3 KDF to the provider in 3.0.
> - Add the TLS 1.3 KDF to the provider, and use it in the ssl library
> in 3.0 so that TLS 1.3 can be used in FIPS mode.
> - Add support for using TLS 1.3 in FIPS mode in 3.0
>
> Most of our votes are not about how it's implemented, but really
> a general direction. As you say yourself, it's about proceeding in
> that direction. I don't see why you can't describe that direction
> with words.
>
> Some of the PR and issues we vote on have different view
> points based on the comments. Am I voting on the last comment
> made in the PR or issue? With a PR you can argue it's not the
> comments but the code, but what happens in case the PR is changed
> before I can vote? We have also voted on issue, were several
> things were mentioned in the issue, some things I agree we should
> do, others I don't.
>
>
> Kurt
>
> On Wed, Aug 04, 2021 at 08:25:59AM +1000, Tim Hudson wrote:
> > The votes on the PR are precisely that - to vote to proceed with the PR
> via
> > the normal review process - and that means looking at the varying
> > viewpoints.
> > If we reached a consensus that overall we didn't think the PR made sense
> > then we wouldn't form a vote of that form.
> >
> > What you are voting for is that what the PR holds is what makes sense to
> > proceed with - subject to the normal review process - i.e. this isn't a
> > push-the-PR-in-right-now vote - it is a "proceed" vote.
> >
> > A PR has a discussion in the PR comments, and generally an associated
> > issue, and always (as it is a PR) the suggested code change.
> > That is what is being voted on - to proceed with the PR - via the normal
> > review process.
> >
> > As otherwise the PR remains blocked on an OTC decision - and the OTC
> > decision is to not continue to block the PR (blocked on an OTC decision).
> >
> > Repeating again - the PR itself is what is being voted about - not a set
> of
> > different unstated viewpoints - it is what is in the PR - fix this
> problem
> > - and generally there is nothing critical seen in the code approach - but
> > our normal review processes still apply to handle it. Which means the PR
> > simply needs the two approvals.
> >
> > The majority of the time in the OTC discussions we are actually looking
> at
> > the PR details in terms of the code changes - we aren't reviewing it as
> > such (although that does sometimes happen on the call) - we are looking
> at
> > the PR code changes providing the additional detail to help in the
> decision
> > making.
> >
> > There are very few PRs which describe what is going to change in a useful
> > form independent of the code changes - they don't usually state things
> like
> > what is going to be changed - they are focused on what is wrong and the
> PR
> > is going to fix it - there isn't usually anything meaningful about what
> is
> > going to be changed in order to fix what is wrong.
> >
> > A PR doesn't hold a range of code fixes to choose between - it holds a
> > discussion (comments) and a specific code fix - and perhaps that specific
> > code fix is the result of a sequence of code fixes that have evolved
> > through the discussion.
> >
> > So the precise viewpoint you are voting for in those PRs is to proceed to
> > include that PR in the work for the current release while continuing to
> use
> > our normal review and approval processes - that is the vote text - and it
> > makes the intent of the vote.
> >
> > Where there is a view that we should not take a particular approach
> > represented in a PR and should take an alternate approach then we don't
> > form a vote that way - we actually allocate someone to produce an
> alternate
> > PR. Often we leave the initial PR and alternate PR open until such time
> as
> > we can compare the approaches in concrete form and then we can make a
> > decision - but that would be accepting one PR over another PR. We have
> had
> > "competing" PRs regularly - and we then vote on the alternatives - where
> it
> > is clear what the alternatives are. A single PR vote is about that PR.
>
> > On Wed, Aug 4, 2021 at 8:07 AM Kurt Roeckx <kurt at roeckx.be> wrote:
> >
> > > On Wed, Aug 04, 2021 at 07:21:57AM +1000, Tim Hudson wrote:
> > > >
> > > > This isn't about the OTC meeting itself - this is about the details
> of
> > > the
> > > > topic actually being captured within the PR.
> > > > You need to actually look at the PR to form a view. And we do add to
> the
> > > > PRs during the discussion if things come up and we review the PR
> details.
> > > > So the vote isn't about an OTC discussion - the vote is precisely
> about
> > > the
> > > > PR itself.
> > > >
> > > > One of the things we have explicitly discussed on multiple calls is
> that
> > > in
> > > > order to be informed of the details, you need to consult the PR which
> > > has a
> > > > record of the discussion and often viewpoints that offer rather
> different
> > > > positions on a topic - and those viewpoints are what should be being
> > > > considered.
> > >
> > > I am happy to read the issue/PR to see the different view points.
> > > But different viewpoints is exactly the problem, which of those am
> > > I voting for?
> > >
> > > During a meeting, there probably was a consensus about what you're
> > > actually voting for, but that information is lost.
> > >
> > > In general, I want a vote to be about what is going to change, the
> > > how isn't important most of the time.
> > >
> > >
> > > Kurt
> > >
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-project/attachments/20210830/8b5a776a/attachment-0001.html>
More information about the openssl-project
mailing list