Differential D50410
style.mdoc: Ask for maintainable wrapping Authored by ziaee on Sun, May 18, 5:10 PM.
Details Add a maintainability subsection explaining line wrapping considerations It burns people out to be wrong for wanting to use freebsd to work on MFC after: 2 weeks
Diff Detail
Event TimelineComment Actions A very senior member of the project once told me "it's not holding it down that burns you out, it's constantly justifying why it should be held down". Comment Actions Oh spare me your wounded pride and perceived victimhood. You were given feedback, within it an important lesson that I, as your mentor, want to impress upon you. Not only have you ignored the lesson, but because the feedback wasn't to your liking, now you react by pouting, and escalating the situation in an attempt to garner support for your hurt feelings. Such theatrics will not work on me. Your appeal to technical precedent and authority is hollow when you show such disrespect to the authority right in front of you. You are entrusted to my care, and care for you I do! Yet here you accuse me of causing you burnout and unnecessary headaches. Who do you think you are talking to? Despite what you may believe, you do not know it all, and your mentorship is not over. So quit your whining and heed my lesson! Anyone can construct a sound argument on technical matters, why a change should be made this way or that. Yet there are deeper principles which we must adhere to. Your "trespass" (your word) is that you wasted reviewer time on inane details, when we both could have been working on something of greater consequence. At all times, there is what is essential, and what is of secondary importance. A true engineer will learn to distinguish between these in the matter at hand. You are not blind; I know you see the great mountain of work to be done in this project, and how few capable hands there are doing it. This is especially true in docs. So what will you spend your limited time on? There are a dozen solutions to your self-inflicted choice of editor that don't involve a policy change and its enforcement. The human portion of the FreeBSD project is the most precious, valuable beyond any technical change or innovation. You would do well to remember this. Are you here to learn or to show off? For your countless informed opinions you are showing very little wisdom. Know when to be silent and listen. And if you can't do this then try asking "why?" before you react. I take no pleasure in doing this publicly, but it is the consequence of your choices. I've already gone to bat for you several times. Why do you bite the hand that feeds? Comment Actions Sir, let me be very clear about one thing, the only thing I am taking personally is the effort you and others are making to help and teach me that we can all build an operating system together. I tagged you as a reviewer, who is welcome to NAK, and emaste who on a different review discussed changing the style because we had a similar discussion. Edit{ therefore I do not see it as an appeal to authority } I should not have tried to touch those lines outside the scope of what the patch was about. This is why I reverted them. Edit2{ if we make style honor 72 it will still be incorrect for me to have tried to touch those lines in the other patch outside the scope of the actual issue the patch was addressing }. Separately, I feel what I said is true, that it is trivial for us to write FreeBSD doc in a way that is nice to work on from FreeBSD base. Comment Actions I'm not mad about you helping me or being honest with me, this is about our culture problem writing our own doc in a way that's pleasant on our default tooling is known to be not what you want to do and described with words "self inflicted". Comment Actions Sorry if I've missed all the drama and thus being out of context, but is this about wrapping lines before 80 chars (72 to account for reasonable amount of slack)? Then I don't see what's wrong with this suggestion, we already [try to] adhere to it in src and ports, and I certainly welcome a polite nudge to do so elsewhere (also, I don't see how it's being enforced with current wording). Comment Actions 72 is needlessly restrictive. There's no reason for that number. 80 might make sense (its how I wrap my man pages). But you also want one sentence per line and this might be good located there. And i think this likely belongs elsewhere. The language needs a lot of work. It sounds very angry and lectury, whole a style guide should just state the rules or advice as simply as possible and avoid editorializing like this. Mostly because it's the opposite of the views on style(9) where there is a growing acceptance of longer lines, at least is a large subset of the tree.
Comment Actions What's usually implied is that 72 should be the lower bound and 78 be the upper. I usually play with values in that range and select the one which yields the most appealing look (less ragged right edge). Wrapping strictly at 80 doesn't look very neat and is ambiguous, which may cause mouse copy-pasting issues on some buggy terminal emulators, e.g. I've seen eating a letter at the border or copying two adjacent words as one. Comment Actions Attempt to improve what I'm trying to say. I just want to be not be wrong for using the defaults. Most terminals Comment Actions How do we make line wrapping not an issue? When we can't move forward with fixes because I wrapped my lines so they look good on the defaults, I think that's a problem and I'm not wrong and it should not be an issue. Comment Actions
I guess I reacted brashly and did lie here. In https://reviews.freebsd.org/D48401 I interpreted we can't move forward with real improvements because the line wrapping is infinitely bikesheddable as that really nothing is valuable. That is bigger than personal and I did take that personally and I should not have lied to my self and subsequently everyone else about that. | |||||||||||||||||