Re: CVS commit: pkgsrc

[Aleksej Saushev <asau%inbox.ru@localhost>]

John Marino <netbsd%marino.st@localhost> writes:

> On 4/11/2013 19:43, Aleksej Saushev wrote:
>>> Having the ability to scroll doesn't justify the existence
>>> unnecessarily verbose descriptions.
>>
>> If you want concise description, you use "pkg_info -c".
>
> You are not listening.  It is more common to read descriptions
> on package that are not installed -- packages that you might
> build.  So pkg_info doesn't help.  Secondly, a one-line
> description is not the same thing as a concise description.
> Obviously.
>
>
>> You can use "less DESCR" with better success. Thus what you're arguing for
>> is your personal preference to continue using broken way to view textual 
>> files.
>
>
> No, you are arguing that people should not be using the console
> with pkgsrc.  You have no justification for considering browsing
> pkgsrc on a command line as broken.

Even in this crippled textual mode you can and should use "less" to view files.
Doing otherwise is bad habit coming from pre-Internet times where you had
complete control on file names. For a long time using "cat" to view files
is dangerous since it may be bad for your terminal settings. Even in Xterm.


>> I think that you don't actually have any idea of what you're talking about.
>> How long has it been since you got good summary from a teenager?
>> How many teenagers have you worked with?
>
>
> Believe me, I have plenty of experience with literate teenagers
> that can compose circles around university students and adults.

On what ground should I believe you? My experience with teenagers is
that even the best of those (aiming at prestigious universities) cannot
produce abstracts that you can read _without_ prior knowledge of a novel,
book, article, and get sense what it is about. The only way you can come
to conclusions like yours is by heavy selection bias. Most students don't
make usable summaries as well.


>> The fundamental difference between us is that I have seen those commits.
>> I reviewed changes and found that in some cases they caused loss of
>> important information.
>> In fact, after this acknowledgment that you have not actually looked
>> at changes you should stop further discussion. You have no idea what
>> reduction of "verbosity" you're talking about now, and it doesn't make
>> any good impression of you.
>
> I know the definition of "arbitrary" and you're misusing it.
> Doing a poor job of editing is doesn't make it arbitrary, just
> poor.

This is an attempt to shift discussion from dropping arbitrary words, phrases,
or complete sentences and introduction of arbitrary abbreviations of one words
but not others to discussion of whether I use the word "arbitrary" properly.


>> Some modern LED displays as well as punch cards have only one line.
>>
>> If you use "more" or "less" then you don't have any of issues you're
>> talking about. Thus your wish to truncate information at any price
>> to make it fit screen size is not justified by practical need actually.
>
>
> I didn't ask for one line, I asked not to see verbal diarrhea.
> Greg Troxel already said he's never seen a 50-line description
> that justified it's length.

Are we talking about 50 lines limit now?
Or is it here just to add weight to your argument?
If the latter, then how is it related?
You can apply this fallacy repeatedly and arrive to the point where
you can use just single line comment.

> Since you clearly disagree with
> that, I challenge you to find a description that long that
> absolutely can not adequately be recomposed by a literate person
> into 20 lines or less without losing its function as package
> description (aka abstract).

That's trivial. postgresql91-datatypes. 8 modules with 2-3 lines
describing each module make it 1+8+8*3 = 33 lines minimal.
Because it takes more than 2 lines per module (and I tried hard
to keep it within 4 lines), its actual length is 44 lines.
This is within the limit Greg talks about but not within yours,
which demonstrates that your appeal to Greg above to obscure
the discussion rather than to support your claim.

Again, since you haven't seen changes actually you don't have idea
of what you're talking about.


>> It is not me who is defending obsolete "standards" and
>> not-actually-standards here.
>>
>> What is more important is that I don't use false analogies,
>> don't build straw man, and don't appeal to past time here.
>
>
> Actually, that's not a false analogies, that's EXACTLY what you
> do. It's EXACTLY what you've posted repeatedly and recently.
> "OMG, $$XYZ is *totally* not the same as $${XYZ} and now the
> whole makefile is ruined!!! it has to reverted immediately!!"
> (eyes roll).
>
> Why even deny it?  Surely you read what you write?

Sure, I read what I write. There is even more that, not only I have read
changes to packages I touched, I have read everything I reverted.
During that review I did exclude several changes that were indeed
whitespace-only changes. This makes me different from you who entered
the discussion without actually looking at changes you're talking about.


-- 
BECHA...
   CKOPO CE3OH...