On Jun 13, 2015, at 23:09, Steve Kargl <s...@troutmask.apl.washington.edu> wrote:
> On Sat, Jun 13, 2015 at 06:45:57PM -0700, Craig Rodrigues wrote: >> On Sat, Jun 13, 2015 at 6:29 PM, Steve Kargl < >> s...@troutmask.apl.washington.edu> wrote: >> >>>> >>>> Are you talking about this comment you made? >>>> >>> https://lists.freebsd.org/pipermail/freebsd-current/2015-March/054899.html >>>> >>>> I can't make heads or tails of what you wrote, other than you seemed very >>>> angry. >>>> >>> >>> I wasn't very angry. >> >> It's hard for me to tell, really, since you submitted patches >> with FUBAR in them, so you seemed pretty angry in that e-mail. >> > > FUBAR is as good as what is already there. Simply drawing > attention to the people responsible for libxo's inclusion > in FreeBSD that they need to fix it. I see the benefit in libxo, but I see the argument in it being unnecessary bloat as well. >>> Do you really believe that the Nd entries for these manpages are >>> correct? >>> >> >> I'm not an expert on the mdoc format, so I couldn't tell you. >> If you can think of some patches to fix things, in the man pages, >> would you be able to submit the patches to Phil, and have them incorporated >> into the software to make it better? > > There isn't a public mailing list or other mechanism to > submit a patch. One needs to sign up for an account. > I have way too many accounts on way too many systems > to sign up for a new account to send in a single patch. Github is rather straightforward, but yes.. the workflow’s a bit different: 1. Fork project. 2. Create a branch for a “topic” (i.e. fix/enhance X). 3. Open a pull request (which will open an issue). >> libxo is maintained at https://github.com/Juniper/libxo . >> >> I don't know if you are willing/able to submit patches to the libxo project >> on Github, >> to help fix things. That would be great if you could do that and help out. > > It seems that libxo developers have no interest in FreeBSD documentation. Not entirely true. They’re willing to work on the versioning problem I noted in the above issue. > https://github.com/Juniper/libxo/issues/13 > > Those that imported/maintain libxo within FreeBSD should fix the > documentation. The problem was with the manpage to github link referencing -- which can change. FWIW I’m happy they have documentation, unlike our current defacto toolchain in FreeBSD (man clang makes me sad… I keep gcc installed just so I can refer to something halfway decent): -O0 Means "no optimization": this level compiles the fastest and generates the most debuggable code. -O1 Somewhere between -O0 and -O2. -O2 Moderate level of optimization which enables most optimizations. Really clang? I didn’t realize that 1 was between 0 and 2... Thanks.
signature.asc
Description: Message signed with OpenPGP using GPGMail
