Re: [gentoo-dev] How not to discuss

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 6248 bytes --]

On Thu, 28 May 2009 08:28:12 +0200
Patrick Lauer <patrick@gentoo.org> wrote:
> - 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

You mean like "EAPI in the filename feels bad"? I agree, that has no
place in a technical discussion.

> > Not once has there been an equally good alternative proposed.
> 
> That's subjective, and let me be the first one to disagree.

No, it's entirely objective. GLEP 55 clearly shows how the filename
based options are objectively better than anything else.

> > > > 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.

The title describes the proposed enhancement.

> > 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.

No, the intent of the enhancement is to switch to EAPI in the filename.

> This is an important point - define the problem first, then discuss
> solutions.

The problem is defined as the first part of the main body of the GLEP.

> > 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.

...and it is the proposed enhancement.

> > 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).

Please re-read the GLEP. All the things you claim aren't there are.

> 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 ...

Uhm. No. It's needed as soon as you need metadata if there's no cache.
Biiiiig difference. If we were sourcing for metadata regardless, it'd
be unusably slow.

> > 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 ...

kdebuild-1 demonstrated the viability of the technique.

> > > 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 ?

Did you read GLEP 55?

> > The title describes the desired enhancement, yes.
> ... which completely ignores stating the problem.

... because there's a length limit. The title is not a substitute for
reading the GLEP.

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

The abstract is not a substitute for reading the GLEP.

> > > 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!

You read the introductory material, then if you want details you read
the rest. Simple.

> > 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)?

I shall explain it to you in simple terms: there can be two reasons for
"x is slower". Either the implementation of x is bad, in which case it
can be improved, or the definition of what x has to do requires
slowness, in which case you can't fix it. For example, an
implementation might be slow because it doesn't carefully avoid doing
more disk work than necessary, in which case it can be fixed, or it
might be slow because the specification of what it does requires it to
do lots of disk work, in which case it can't.

> > > 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?

Please go back to your "nothing subjective" comment.

> > > 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.

We've already established that a fix is necessary. Now we're just
discussing which fix is best, and GLEP 55 conclusively provides the
answer.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]