Skip to content

Conversation

@levitte
Copy link
Member

@levitte levitte commented Oct 2, 2019

The checks for our uses of B< and I< for options, and possibly
function names, was over-reaching quite a bit.

So we fine-tune it a bit:

  • by only checking for options in man1 pages, and only in SYNOPSIS
    and *OPTIONS sections.
  • by only checking for function names in man3 pages.

The man1 option checker has the additional check that options found in
*OPTIONS are also found in SYNOPSIS and vice versa.

In all cases, this also handles options and function names with
additional markup, such as B<-I<cipher>> and B<sk_I<TYPE>_push>.

The checks for our uses of 'B<' and 'I<' for options, and possibly
function names, was over-reaching quite a bit.

So we fine-tune it a bit:

- by only checking for options in man1 pages, and only in SYNOPSIS
  and *OPTIONS sections.
- by only checking for function names in man3 pages.

The man1 option checker has the additional check that options found in
*OPTIONS are also found in SYNOPSIS andd vice versa.

In all cases, this also handles options and function names with
additional markup, such as 'B<-I<cipher>>' and 'B<sk_I<TYPE>_push>'.
@levitte levitte added the branch: master Applies to master branch label Oct 2, 2019
@levitte
Copy link
Member Author

levitte commented Oct 2, 2019

Note that Travis will fail, because there is plenty of incomplete option documentation. That's actually a good thing, it shows that this script does its job right.

Copy link
Contributor

@richsalz richsalz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hey, i even still understood my script after these changes :)

@richsalz
Copy link
Contributor

richsalz commented Oct 2, 2019

And it would be good to see this merged soon, since all builds are currently broken.

@richsalz
Copy link
Contributor

richsalz commented Oct 2, 2019

Note that Travis will fail, because there is plenty of incomplete option documentation. That's actually a good thing, it shows that this script does its job right.

do we want to do that? there are a LOT of undocumented flags. breaking all travis jobs until they're fixed doesn't seem quite right.

And BTW, look at the "-c" flag to find-doc-nits. Either remove that, or disable the reporting you do, we should only do it once.

@mattcaswell
Copy link
Member

do we want to do that? there are a LOT of undocumented flags. breaking all travis jobs until they're fixed doesn't seem quite right.

I agree - we should get travis fixed asap.

@levitte
Copy link
Member Author

levitte commented Oct 2, 2019

[sigh] I have a separate PR where I'm fixing up doc/man1. I'm sure you've noticed.

@richsalz
Copy link
Contributor

richsalz commented Oct 2, 2019

please don't lose the last line of my #10073 (comment)

@levitte
Copy link
Member Author

levitte commented Oct 2, 2019

Note that Travis will fail, because there is plenty of incomplete option documentation. That's actually a good thing, it shows that this script does its job right.

do we want to do that? there are a LOT of undocumented flags. breaking all travis jobs until they're fixed doesn't seem quite right.

My check does something different, it detects inconsistencies between SYNOPSIS and OPTIONS, i.e. if an option is given in one of them but not the other. So this has absolutely nothing to do with options not being documented at all.

@richsalz
Copy link
Contributor

richsalz commented Oct 2, 2019

My check does something different

Got it, thanks. I still think that it is very wrong to check in code that knowingly breaks CI builds. OpenSSL has enough instances of doing it by mistake.

@mattcaswell
Copy link
Member

I still think that it is very wrong to check in code that knowingly breaks CI builds.

I agree - we should avoid doing that.

Does #10065 address the new issues that this PR finds?

@richsalz
Copy link
Contributor

richsalz commented Oct 2, 2019

No. They were broken by #10041, which broke find-doc-nits handling some new syntax. This PR fixes that issue, but then continues to break the build by adding a new type of error, the synopsis/options inconsistency mentioned above.

@levitte
Copy link
Member Author

levitte commented Oct 2, 2019

I have no idea what @richsalz is saying "No" to here. #10065 is indeed intended to fix what is found by this version of the script. I do not want to have discussions about the script and discussions about the manual pages mixed in the same PR, hence this separate one for the script.

@richsalz
Copy link
Contributor

richsalz commented Oct 2, 2019

Does merging this PR leave doc-nits builds still broken? Yes, because of the new check you added which you are planning on fixing in another PR.

@mattcaswell
Copy link
Member

mattcaswell commented Oct 2, 2019

So, IIUC this means that this PR is dependent on #10065. Only when both this PR and #10065 are merged will we have a clean travis again.

@richsalz
Copy link
Contributor

richsalz commented Oct 2, 2019

What I have done in other PR's, and what I think should be done here, is that the errors at lines 318 and 323 should be commented out and enabled in #10065.

Fix the bugs/nits, and enhance find-doc-nits to report issues so it doesn't happen again, in the same PR.

@mattcaswell
Copy link
Member

What I have done in other PR's, and what I think should be done here, is that the errors at lines 318 and 323 should be commented out and enabled in #10065.

That seems like a sensible approach.

@levitte
Copy link
Member Author

levitte commented Oct 2, 2019

I find it incredibly interesting that y'all don't want a script that is designed to show where our documentation is wrong, to actually show where the documentation is wrong (or at the very least, inconsistent).

A major reason to have it in a separate PR is for demonstration purposes, i.e. demonstrate that it actually does the work it purports to do. If I would put it in #10065, you would have no way to see that without doing extra work.

But tell you what, when the changes in this script look acceptable, I can always rebase #10065 on top of this, and we can all see the effect it will have there. Deal?

@richsalz
Copy link
Contributor

richsalz commented Oct 2, 2019

What I described is what I have always done for doc nits before. We have never needed "proof" that it works" You can get that by making one commit enable the doc-nits changes, and then a separate commit include the fixes. You can put "if $debug" tests around the errors here, and then enable them for production in the other PR.

I am only a contributor, but I find it horrible to knowingly check in code that breaks the build.

@mattcaswell
Copy link
Member

I find it incredibly interesting that y'all don't want a script that is designed to show where our documentation is wrong, to actually show where the documentation is wrong (or at the very least, inconsistent).

We want a fixed travis build more. Only then do we want to see more errors.

@levitte
Copy link
Member Author

levitte commented Oct 2, 2019

That way, we only get to see that it can approve of what's there, but not that it can find faults that are there, at least in the PR that changes it.

But like I said, when you have no more issues with the changes here, I will rebase #10065 on top if it, and final approval can happen there.

@mattcaswell
Copy link
Member

But like I said, when you have no more issues with the changes here, I will rebase #10065 on top if it, and final approval can happen there.

I would much rather get this in asap, and not have it wait on #10065. This is breaking travis now and we need to get it fixed.

@levitte
Copy link
Member Author

levitte commented Oct 2, 2019

There were still some malformed options, even thought I removed the SYNOPSIS<->OPTIONS inconsistency check (I'll add it back in another PR), so there are a few affected man-pages.

@mattcaswell
Copy link
Member

Why the inclusion of version.sh?

@levitte
Copy link
Member Author

levitte commented Oct 2, 2019

Why the inclusion of version.sh?

Mistake. I have no idea how it ended up in here. Fixed.

@levitte
Copy link
Member Author

levitte commented Oct 2, 2019

I think I've answered all outstanding issues

@levitte
Copy link
Member Author

levitte commented Oct 2, 2019

CIs are happy. Are you?

@richsalz
Copy link
Contributor

richsalz commented Oct 2, 2019

I am happy. :) Thanks for listening.

@levitte
Copy link
Member Author

levitte commented Oct 2, 2019

I'm glad you are ;-). I hope someone with approval power is as well ...

Copy link
Member

@mattcaswell mattcaswell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mattcaswell mattcaswell added the approval: done This pull request has the required number of approvals label Oct 2, 2019
@levitte
Copy link
Member Author

levitte commented Oct 2, 2019

Merged.

705128b util/find-doc-nits: more precise option and function name checker
8dc57d7 doc/man1: fix malformed options

@levitte levitte closed this Oct 2, 2019
levitte added a commit that referenced this pull request Oct 2, 2019
The checks for our uses of 'B<' and 'I<' for options, and possibly
function names, was over-reaching quite a bit.

So we fine-tune it a bit:

- by only checking for options in man1 pages, and only in SYNOPSIS
  and *OPTIONS sections.
- by only checking for function names in man3 pages.

The man1 option checker has the additional check that options found in
*OPTIONS are also found in SYNOPSIS andd vice versa.

In all cases, this also handles options and function names with
additional markup, such as 'B<-I<cipher>>' and 'B<sk_I<TYPE>_push>'.

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from #10073)
levitte added a commit that referenced this pull request Oct 2, 2019
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from #10073)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approval: done This pull request has the required number of approvals branch: master Applies to master branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants