Re: OTC quick votes [WAS: RE: OTC vote PR #16171: config_diagnostic]
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, 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). >
Re: OTC quick votes [WAS: RE: OTC vote PR #16171: config_diagnostic]
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 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
Re: OTC quick votes [WAS: RE: OTC vote PR #16171: config_diagnostic]
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. Tim. On Wed, Aug 4, 2021 at 8:07 AM Kurt Roeckx 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 > >
Re: OTC quick votes [WAS: RE: OTC vote PR #16171: config_diagnostic]
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
Re: OTC quick votes [WAS: RE: OTC vote PR #16171: config_diagnostic]
On Wed, Aug 4, 2021 at 5:26 AM Dr. Matthias St. Pierre < matthias.st.pie...@ncp-e.com> wrote: > > I'm starting to vote -1 on anything has a vote text that looks like > that, so -1. > > I perfectly understand Kurt's dislike of this kind of votes. The text is > not very informative for OTC members who > weren't able to participate at the weekly video meetings. > 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. If you wanted to form a view on the basis of vote text without a reference to the PR, then you would require replication of the issue, the PR code changes, and the PR comment discussion. Such an approach would be a complete waste of time and resources. We want the discussion in terms of an issue to be in the PR itself. Often during OTC meetings additional comments (separate from the consensus viewpoint) are added capturing an relevant point from the OTC discussions (which can be quite free flowing). The email based voting mechanism is a separate topic and one I've expressed views on multiple times - as I do think we should have an online mechanism for voting and tallying and communicating about votes - but that isn't this specific issue Kurt is raising here. Tim.
RE: OTC quick votes [WAS: RE: OTC vote PR #16171: config_diagnostic]
You probably all noticed my mistake: I meant to say 'quorum', not 'quota'. Matthias > -Original Message- > From: openssl-project On Behalf Of Dr. > Matthias St. Pierre > Sent: Tuesday, August 3, 2021 9:26 PM > To: Kurt Roeckx ; Dr Paul Dale > Cc: openssl-project@openssl.org > Subject: OTC quick votes [WAS: RE: OTC vote PR #16171: config_diagnostic] > > > I'm starting to vote -1 on anything has a vote text that looks like that, > > so -1. > > I perfectly understand Kurt's dislike of this kind of votes. The text is not > very informative for OTC members who > weren't able to participate at the weekly video meetings. > > IMHO it proves that the current voting mechanism does not scale well with the > number of decisions that have to be made. > The rate of those decision has increased heavily during the final phase of > the 3.0 development and the weekly video meetings > were an attempt to improve agility and get those decisions made. On the other > side, the voting scheme has remained unchanged, > mailing '+-1' replies to the mailing list within a certain time interval and > recording them arduously in a GitHub repository. > > Maybe we need to overthink the online voting rules and optimize them > slightly. For example, we could require an online > quota in which case the online votes can be held immediately, but they would > need to be documented properly with > a meaningful subject line and ideally also a rationale. We could switch to > publishing meeting protocols which document all > online votes properly, including the rationale. Maybe those online votes > could be excluded from the official participation count > mentioned in the bylaws as indicator for OTC activity. > > These are just some wild thoughts for the moment. I doubt we will have time > to discuss it in detail before the final 3.0 release. > But maybe it would be a good subject for the next OTC face-to-face meeting. > > Matthias > > > > -Original Message- > > From: otc On Behalf Of Kurt Roeckx > > Sent: Tuesday, August 3, 2021 6:36 PM > > To: Dr Paul Dale > > Cc: o...@openssl.org > > Subject: Re: OTC vote PR #16171: config_diagnostic > > > > On Tue, Aug 03, 2021 at 07:03:14PM +1000, Dr Paul Dale wrote: > > > topic: Accept PR 16171 in 3.0 subject to our normal review process. > > > > I'm starting to vote -1 on anything has a vote text that looks > > like that, so -1. > > > > This is also send to the wrong list. > > > > > > Kurt > > > > ___ > > otc mailing list > > o...@openssl.org > > https://mta.openssl.org/mailman/listinfo/otc smime.p7s Description: S/MIME cryptographic signature
