OTC quick votes [WAS: RE: OTC vote PR #16171: config_diagnostic]

[Kurt Roeckx]

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
> >
> >