From: Roy Bamford <neddyseagoon@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Enough about GLEP5{4,5}
Date: Mon, 08 Jun 2009 21:20:48 +0100 [thread overview]
Message-ID: <1244492455.3420.0@NeddySeagoon> (raw)
In-Reply-To: <20090608193522.751a66a3@snowcone> (from ciaran.mccreesh@googlemail.com on Mon Jun 8 19:35:22 2009)
-----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-----
next prev parent reply other threads:[~2009-06-08 20:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-07 15:54 [gentoo-dev] Enough about GLEP5{4,5} Rémi Cardona
2009-06-07 16:16 ` Roy Bamford
[not found] ` <2144523.vh3QGIWsHC@news.friendly-coders.info>
2009-06-08 18:35 ` Ciaran McCreesh
2009-06-08 20:20 ` Roy Bamford [this message]
2009-06-08 20:41 ` Patrick Lauer
2009-06-08 21:03 ` Dawid Węgliński
2009-06-08 21:32 ` Ulrich Mueller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1244492455.3420.0@NeddySeagoon \
--to=neddyseagoon@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox