Re: [gentoo-dev] Enough about GLEP5{4,5}
On Mon, 08 Jun 2009 19:17:56 +0100 Steven J Long sl...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Enough about GLEP5{4,5}
-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}
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}
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}
[Answering to a random posting in this thread.] Please, stop this now, or continue your discussion in private. Thanks Ulrich
Re: [gentoo-dev] Enough about GLEP5{4,5}
-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-
