svn commit: r284198 - head/bin/ls

[Garrett Cooper]

On Jun 13, 2015, at 23:09, Steve Kargl <sgk at 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 <
>> sgk at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20150614/030afb5c/attachment.sig>