[gentoo-dev] Enough about GLEP5{4,5}

[gentoo-dev] Enough about GLEP5{4,5}

[Rémi Cardona]

Seriously, let's stop.

This endless debate has gone on for waaay too long and it is just plain 
spam now.

I'm just too tired of reading those endless discussions that are going 
_nowhere_.

Let's just all agree we've failed to reach a consensus and let's spend 
time on something else.

Surely I must not be the only one who's completely bothered by those 
debilitating threads?

Cheers,

Rémi

Re: [gentoo-dev] Enough about GLEP5{4,5}

[Roy Bamford]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2009.06.07 16:54, Rémi Cardona wrote:
> Seriously, let's stop.
> 
> This endless debate has gone on for waaay too long and it is just
> plain 
> spam now.

[snip]

> Let's just all agree we've failed to reach a consensus and let's 
> spend time on something else.

[snip]

> Cheers,
> 
> Rémi
> 
> 

Rémi,

I think that GLEP55 has failed so far because it has always been 
inadequately documented in the GLEP.

My view is that its worth documenting the problem and potential 
solutions properly and having one more go. Thats why I'm putting my 
time into editing the GLEP now. 

The problem won't be addressed by spending time on something else.
The one big problem needs to be broken down recursively into smaller 
problems that can be addressed individually, rather like a very old 
asteriods game.

If we get a solution, Gentoo can be first into the future again, if 
not, we will always be last out of the past.

Gentoo needs a way to introduce new features without waiting over a 
year to provide backwards compatibility.

- -- 
Regards,

Roy Bamford
(NeddySeagoon) a member of
gentoo-ops
forum-mods
treecleaners
trustees
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkor6AAACgkQTE4/y7nJvavJUACgwgVZHuD1ylcq45DgvGi9SBAd
RGEAoJ5XBmNWNb6H1UHk5aQYC18TeY5g
=rbTU
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Enough about GLEP5{4,5}

[Ciaran McCreesh]

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

On Mon, 08 Jun 2009 19:17:56 +0100
Steven J Long <slong@rathaus.eclipse.co.uk> wrote:
> If the problem had been adequately communicated in the first place
> (which is pretty much required for any proposal ime) instead of people
> being told they "don't understand so go away" we could have agreed
> then, that the issue was simply about knowing the EAPI before
> sourcing.

That is not what the issue is. That is half of what the issue is.

> As it is, we _finally_ have grudging submission that tightening the
> PMS to reflect QA reality works but is not "the best solution."

No, it would not be to reflect reality. We would have to tighten the
rules in such a way that it breaks things people have already done, and
if we were to do so it would either impose performance penalties or not
allow us the full scope of changes, and it would still require us to
wait a year or more before going ahead with any of these changes.

> (Even though the case for changing version format has not been made,

The Council disagrees.

> the argument applies to the other incompatible changes affecting
> global environment.)

No, that's a separate issue, and does not have the same performance
implications.

> Firstly, and most significantly, this only applies when the mangler
> does not have the ebuild metadata in cache.

Not true.

> Bear in mind portage automatically caches overlays
> under /var/cache/edb

You are confusing the dep cache with the metadata cache. They are not
the same thing.

> Secondly, for the mangler to determine the "best-visible", EAPI is
> not the only item under consideration. So again, there is a lie
> implicit: whether from cache or from file, the mangler will ALWAYS
> need some metadata on the ebuilds; CPV + EAPI is insufficient.

It currently, and will still with 55, require metadata from only *some*
ebuilds (usually just one). You're talking about making it require
metadata from all of the ebuilds.

> At very best, all EAPI in filename (wherever it is) does, is limit
> the set of ebuilds to those with a supported EAPI before the cache
> has to be consulted. For Gentoo users (who update as recommended)
> using Gentoo product, that's _every_ ebuild in the tree and overlays.

Er, no. It means we only have to consult any file at all for the best
version, and then go backwards down versions until we find a visible
version.

> So what practically are we accomplishing for our users?

We are letting package manager people make the changes needed so that
developers can write better ebuilds.

> And how much developer time would be wasted to do so, and indeed has
> already been wasted on this?

Thanks to emails like yours, lots.

> (If you don't think it is a problem, please feel free to say
> so /without/ resorting to insult over reason. If you think the
> proposal had merit: how come we've only now got agreement that
> easily-extractable EAPI works?)

Easily-extractable EAPI either has change scope limitations or a
considerable performance impact.

GLEP 55's getting nowhere because a small group of religious fanatics
are doing anything they can to derail it because it came from "the
wrong people". If you want to know the kind of arguments that are being
thrown against GLEP 55 now, just have a look at:

22:54 < ciaranm> it's been established by precedent that gleps propose
an enhancement, and that competing enhancements get their own gleps
22:55 < bonsaikitten> well, we claim precedent on this one
22:55 < bonsaikitten> so there :)
22:55 < ciaranm> point to your precedent please
22:55 < bonsaikitten> it is the precedent
22:56 < ciaranm> bonsaikitten: uh... i don't think you know what that
means..
22:56 < bonsaikitten> ciaranm: you refuse to accept time travel

Yup, the argument of the week against GLEP 55 is that we refuse to
accept time travel.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Enough about GLEP5{4,5}

[Roy Bamford]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2009.06.08 19:35, Ciaran McCreesh wrote:
[snip]

> Easily-extractable EAPI either has change scope limitations or a
> considerable performance impact.
That needs to be quantified. e.g. 20ms to 200ms is a factor of 10x but 
it would not be considered 'considerable'.
ms == 0.001 seconds

> 
> GLEP 55's getting nowhere because a small group of religious fanatics
> are doing anything they can to derail it because it came from "the
> wrong people".
[snip]

I don't accept that. as I said in -council last night. A good technical 
paper presents an impartial, convincing technial argument. Glep 55 
version 1.5 fails, as evidenced by the number of people who are not 
convinced that the problem it addresses exists, never mind the proposed 
solution.

There are several issues. Some with glep55 and some with the glep 
process. Glep 55 (any version) does not cover all the areas in 
http://www.gentoo.org/proj/en/glep/glep-0001.html#what-belongs-in-a-
successful-glep and it needs to.

Glep 55 is a particularly complex glep. its not really suited to the 
current glep process which is written as if you agree everying during 
the process of writing the glep and its a done deal when it gets 
to council.

Glep 55 would benefit from being subject to the full rigours of the 
life cycle process, which has already started to happen. Council have 
agreed the problem is worth addressing. Thats the first step in the 
process.

We have several options to solve the acknowledged problem. Thats the 
next life cycle process step. They need to be presented first for peer 
review, then to council with some metrics on the bottlenecks of each.
That does not mean you need fully working solutions. With that 
information, one solution will be selected for implementaion.

Breaking the problem into small pieces and addressing each piece is the 
way complex problems are solved outside of Gentoo. At the top level its 
called Systems Engineering. 

I'm quite happy to do the editorial work but I need the facts to work 
with and after two years we still only have subjective assessments of 
the alternatives.

Glep55 will be rejected no matter who presents it and where the ideas 
come from if its presented on one piece, its just too much to take in 
in one go. The approvers need to poke at the glep as it develops, not 
be presented with a done deal.

> 
> -- 
> Ciaran McCreesh
> 

- -- 
Regards,

Roy Bamford
(NeddySeagoon) a member of
gentoo-ops
forum-mods
treecleaners
trustees
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkotcqcACgkQTE4/y7nJvatl/QCg3TwEohuKnT1xG8fgTybAs9DU
vq0AoLyui1F3OQ5xChZAXCLQK12GefQA
=PP28
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Enough about GLEP5{4,5}

[Patrick Lauer]

On Monday 08 June 2009 20:35:22 Ciaran McCreesh wrote:
> On Mon, 08 Jun 2009 19:17:56 +0100

> > And how much developer time would be wasted to do so, and indeed has
> > already been wasted on this?
> Thanks to emails like yours, lots.
5-2009, 800 emails
11.75%  ciaran.mccreesh.googlemail.com

4-2009, 287 emails
11.50%  ciaran.mccreesh.googlemail.com

3-2009, 602 emails
9.47%  ciaran.mccreesh.googlemail.com

Congratulations. You managed to consistently hit the top spot for three months 
in a row, outrunning the second by a wide margin. At this rate of increase 
you'll write all emails on this mailing list somewhere near 2012 ...

Source: http://archives.gentoo.org/stats/gentoo-dev-per-month.xml

> > (If you don't think it is a problem, please feel free to say
> > so /without/ resorting to insult over reason. If you think the
> > proposal had merit: how come we've only now got agreement that
> > easily-extractable EAPI works?)
>
> Easily-extractable EAPI either has change scope limitations or a
> considerable performance impact.

I thought the performance impact was still up for debate (and if I'm not 
mistaken the parsing approach would still be _much_ faster than the current 
sourcing approach, negating your argument quite nicely ...)
>
> GLEP 55's getting nowhere because a small group of religious fanatics
> are doing anything they can to derail it because it came from "the
> wrong people".
No, you are ignoring what people say again. It's a bad idea, has nothing to do 
with your abrasive demeanor, your attempts to deflect the discussion etc.
Amazingly people don't care that much about you.

> If you want to know the kind of arguments that are being
> thrown against GLEP 55 now, just have a look at:
>
> 22:54 < ciaranm> it's been established by precedent that gleps propose
> an enhancement, and that competing enhancements get their own gleps
> 22:55 < bonsaikitten> well, we claim precedent on this one
> 22:55 < bonsaikitten> so there :)
> 22:55 < ciaranm> point to your precedent please
> 22:55 < bonsaikitten> it is the precedent
> 22:56 < ciaranm> bonsaikitten: uh... i don't think you know what that
> means..
> 22:56 < bonsaikitten> ciaranm: you refuse to accept time travel
>
> Yup, the argument of the week against GLEP 55 is that we refuse to
> accept time travel.

Oh, you took that little joke seriously. I thought you were joking there, 
precedent is such a funny and obsolete legal concept. Plus you had been 
baiting NeddySeagoon for almost an hour at that point, driving the discussion 
in circles without contributing any constructive comments or fact-based chains 
of reasoning.
And you didn't quote the much better joke:

<bonsaikitten> time flies like an arrow, and fruit flies like banana

That you now take a joke as a serious argument to show that "the others" are 
wrong is quite hilarious. I do wonder though why you feel the need to diffuse 
a technical discussion with humoristic things like this ...

Still leaves open why you religiously deny any input from me, even if it could 
solve the problem, and why you try to remove the discussion of alternatives 
from GLEP55 when NeddySeagoon spent lots of time refining it after multiple 
people stated the simple problem that it is missing the discussion of 
alternatives and is not fit for discussion. So maybe you should just let go of 
this one and let people with experience in documentation, standardization and 
other similar things fight out this one? Might make it easier to get 
somewhere. 

Re: [gentoo-dev] Enough about GLEP5{4,5}

[Dawid Węgliński]

On Monday 08 of June 2009 22:41:12 Patrick Lauer wrote:
>[snip]

Thanks for your useless statistics.

-- 
Cheers
Dawid

Re: [gentoo-dev] Enough about GLEP5{4,5}

[Ulrich Mueller]

[Answering to a random posting in this thread.]

Please, stop this now, or continue your discussion in private.

Thanks
Ulrich