Re: [gentoo-dev] How not to discuss

[Patrick Lauer]

This is becoming a rather lengthy email ping pong, but as people seem to be 
unable to discuss things I had to highlight a few issues there. 

Short version:

- Try to avoid subjective statements. Statements like "C++ feels better" don't 
add anything to the discussion and are objectively wrong for me, so they have 
no place in a technical discussion

- Repeating things doesn't make them more true. If someone disagrees use 
technical arguments, microbenchmarks or whatever else is needed to show that 
the argument is wrong (or at least severely flawed) instead of ignoring it.

- Start with the problem, not the solution. If you cannot define the problem 
then there's a good chance your solution isn't. Don't ignore facts if they'd 
show that your solution is a sad puppy that should get euthanised.

- Keep your cool. If you are right there's no need to immediately fire back an 
email. Take your time, disassemble the arguments (or lack thereof) the other 
side provides instead of playing semantic game or trying to use logical 
fallacies to make you sound more better.

Posting on this mailinglist is a privilege, not a right. Be careful not to 
lose it.




On Thursday 28 May 2009 01:45:18 Ciaran McCreesh wrote:
> On Wed, 27 May 2009 23:26:25 +0000 (UTC)
>
> Mark Bateman <couldbe@××××.com> wrote:
> > NOT once within GLEP55 or in all the ml posts over all the *MONTHS*
> > has there been unequivocal proof that encoding metadata into the
> > filename of an ebuild is a necessity, so please stop playing that
> > tune it is getting boring
>
> Not once has there been an equally good alternative proposed.

That's subjective, and let me be the first one to disagree. GLEP55 in its 
current form (rev. 1.5 at the moment, we need to state the revision so we know 
what we are actually talking about because it mutates ...) is definitely not 
the best solution if you  (even momentarily) allow other solutions to exist.


> > > GLEP titles are required to be short.
Yes, that is a reasonable demand. It is completely independent of the demand 
that the title describes the _problem_ and not your solution. Please try to 
improve your reading comprehension to the point where we can discuss instead 
of having several independent monologues.

> > Even with title length restrictions the title can easily be improved.
> > At present it tells the skim reader NOTHING except it is todo with
> > encoding EAPI into the filename.
> >
> > "Means to determine EAPI of ebuild"
> > 7 less characters AND actually provides some description of what this
> > GLEP is going to cover not some BS "WTF" title.
>
> Doesn't cover the intent of the enhancement. The intent of the
> enhancement is to use EAPI suffixed ebuilds.

No, the intent is to find a better way to determine the EAPI. One proposed 
solution is the use of a suffix. Please stop trying to distract people in 
semantic games, it is dishonest.

>
> > > Because that's down in the 'Problem' section. Your argument appears
> > > to be that no individual paragraph covers every last bit of
> > > material in the GLEP.
> >
> > No it is not. That is not an abstract, that is jumping straight in
> > with the proposed solution. That is not what an abstraction/summary
> > is for. There is no (formal) length restriction on the abstraction
> > section so it should be taken advantage of.

This is an important point - define the problem first, then discuss solutions. 
Otherwise you end up in circular reasoning that we need to do something so 
that something is done (which is quite fun and maybe even a tautology, but has 
no information content and can thus be classified as "white noise")
> >
> > The abstract/summary is to allow those that have a quick look into
> > the paper (after looking at a relevant title...) to tell if it
> > relevant to their interest and whether they should read any further.
> > OR in a big discussion, where a paper is referred to as a logging
> > number, people can quickly ascertain what it is discussing - very
> > important ifmany papers are referenced in a discussion
>
> Yes, and the quick summary of the GLEP is that EAPI suffixed file
> extensions should be used for ebuilds.

No, that is the solution favoured by one group of people. All other solutions 
are ignored by rephrasing the problem to be the solution and the solution to 
be the obvious solution to itself.

> You're being overly harsh on Piotr there. GLEPs aren't supposed to be
> written to peer review journal standards -- they're supposed to be
> technical material that can be understood by the appropriate audience
> and used to propose an enhancement, not something that has to stand in
> archives for a thousand years.
And still one would expect a minimal coherence - stating the problem (not 
there), discussing alternatives (incomplete and phrased in a way to make them 
look extra bad) and maybe a comparison (mostly missing).

Maybe even the impact of the solution, possible issues etc. 
You know, what we have been discussing on this mailinglist ... 

> > > Uhm. No. With the current rules, the package manager cannot parse
> > > the ebuild. It has to use a full bash source.
> >
> > So ... maybe the rules are wrong and they also need to be changed for
> > the complete solution to be realised.

Which points at a simple solution that gets mostly ignored: Since we already 
state EAPI explicitly we can restrict ourselves to parsing it (with a regexp, 
maybe) instead of having to source the ebuild. Which has to happen anyway as 
soon as you need metadata ...

> Congratulations. That is what this whole thing is about, and GLEP 55
> presents the best way of doing that changing.

No, GLEP55 is the hackish way of sweeping it under the rug. Feel free to 
implement it in an experimental overlay and report back what your experiences 
are in, say, 3 months ...

> > Parse the ebuild, determine the EAPI,
> > configure PackageManager, source ebuild. Problem solved.  QED.
> >
> > I wonder what portage does at the moment...
Mostly look at the metadata cache, but for this discussion we have to pretend 
that caching can't work instead of improving it.

> It uses bash to do the sourcing, as it has to. And the GLEP covers why
> the file extension method is better than parsing to get EAPI.

Subjective. See above. Repetition is repetitious.

> > Definition of problem is flawed within GLEP55
>
> No, the definition of the problem is entirely accurate and correct.

... wait, you defined the problem now? I thought GLEP55 was all about the 
solution. Or are you deliberately trying a switch-and-bate ?

>
> > > Have you ever read a technical paper? They start off with a brief
> > > introduction that doesn't contain details, then move on to the
> > > details later on.
> >
> > WHAT!
> > 1) The title of this GLEP is all about the solution
>
> The title describes the desired enhancement, yes.
... which completely ignores stating the problem.

> > 2) the Abstraction is all about the solution
>
> The abstract describes the desired enhancement in more detail, yes.
... enhancing what to achieve what why?

> > THEN finally we get the actual problem
>
> The main proposal then expands upon the background and reasoning behind
> the enhancement, yes.
Oh, you gotta read it backwards. That's awesome. No wait, the other thing. 
Stupid!

> > > It's a simple statement of fact.
> >
> > if it *fact* provide results, provide details of how the results were
> > obtained, provide details so others may reproduce independently, if
> > they want. Such things should be in the paper.
>
> It's true by definition.
Tautologies are fun, but irrelevant to discussing technical issues. 

> It's not something that's only true as a
> result of an implementation; implementations can be improved, but
> penalties from definition can't be fixed.
Hmm. I'm not quite sure how to parse that. Does that mean that we need to 
abstractly discuss various options (which would go against your interpretation 
of the process), or does that mean that the idea of glep55 is flawed (which 
would be a rather interesting concession coming from you)?

>
> > encoding the EAPI into the filename does not provide any additional
> > benefits over encoding it in a pre-defined position within the files
> > data + one-off extension change.
I think we'd need to discuss the advantages and disadvantages of both 
approaches to be sure about that.

> This is covered by GLEP 55.
No, not at all.

> > Infact it has already been stated:
> > "Adding metadata to the filename is not required and is bad system
> > design practice"
>
> Stating something doesn't make it true. You could just as easily argue
> that having PV in the filename is bad.
Ignoring it doesn't make it go away. Reasonable discussion would be the best 
thing to do now ... are you willing to do that instead of running in circles 
and barking the same dog-matic statements?

>
> > Now if there is an actual technical reason, a reason that isn't
> > present in GLEP55, then it is further proof that GLEPP55 is not
> > suitable for the task and needs to be rejected in its present form
>
> The reason is that there is no equally good alternative.

The reason is that GLEP55 is no reasonable alternative to the rest.

See, stating things is easy. Now let's get this iceberg back on collision 
course with the titanic and resume a technical discussion please ...