From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1M9SoI-0004Kv-8K for garchives@archives.gentoo.org; Wed, 27 May 2009 23:45:26 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id ABB65E047C; Wed, 27 May 2009 23:45:24 +0000 (UTC) Received: from mail-fx0-f219.google.com (mail-fx0-f219.google.com [209.85.220.219]) by pigeon.gentoo.org (Postfix) with ESMTP id 52A20E047C for ; Wed, 27 May 2009 23:45:24 +0000 (UTC) Received: by fxm19 with SMTP id 19so4587664fxm.34 for ; Wed, 27 May 2009 16:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=C7SFwKjMeuansNBCe00KS8rsQWxJ74sH1/D/kNudgUA=; b=DfhdruOymzT3vCeKNtVK3ycRGAn+C1PatkuTxTGyLbhy0yRxSWTQSSDveNZ1jJMi8L 3ZWaMDH0+LWHm0OOext2DwzlqFInG1sZZnhmDBGpw/AEWNc/HOvdf1skGjbIeCGAO6hl j5GBt6v0nxc/6pur4J+4bQERmPwOcHleq8uJg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=xbniXpP6ZH9dlb0fkGeFEXYirYz7FJP3/vIHlm12ZxmrEgleWmfb7MtgOZC0qAbjpK UjLTixFNACC5Rl6yyT85oYcUEv4JVjLyDEHYdJWK86jemuRvdqCiH2O3C0/iQOuv72r9 LCq3dSmVpYVx5arRiW/1GQrs14SaAgNMTVnms= Received: by 10.86.25.10 with SMTP id 10mr814531fgy.79.1243467923526; Wed, 27 May 2009 16:45:23 -0700 (PDT) Received: from snowcone (92-235-187-79.cable.ubr18.sgyl.blueyonder.co.uk [92.235.187.79]) by mx.google.com with ESMTPS id l12sm3897114fgb.16.2009.05.27.16.45.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 May 2009 16:45:23 -0700 (PDT) Date: Thu, 28 May 2009 00:45:18 +0100 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Gentoo Council Reminder for May 28 Message-ID: <20090528004518.5a4f91b5@snowcone> In-Reply-To: References: <20090527210642.6b7b0f21@snowcone> <1243460607.3480.3@NeddySeagoon> <20090527225229.6be38c58@snowcone> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/hqpDr6RDhLWbFFGOPI6BZ1C"; protocol="application/pgp-signature" X-Archives-Salt: 21bfbcf0-bac2-4267-80d8-678f165808da X-Archives-Hash: 42bcb021ec481175ca31d2b8738fd80d --Sig_/hqpDr6RDhLWbFFGOPI6BZ1C Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 27 May 2009 23:26:25 +0000 (UTC) Mark Bateman 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. > > GLEP titles are required to be short. >=20 > 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. > =20 > "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.=20 Doesn't cover the intent of the enhancement. The intent of the enhancement is to use EAPI suffixed ebuilds. > > 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. > >=20 >=20 > 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.=20 >=20 > 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.=20 > 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. > If you have any formal proposal writing experience you would know that >=20 > As a formal paper this is a joke and I would be embarrassed to be > associated with it, luckily I am not.=20 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. > > Uhm. No. With the current rules, the package manager cannot parse > > the ebuild. It has to use a full bash source. >=20 > So ... maybe the rules are wrong and they also need to be changed for > the complete solution to be realised. Congratulations. That is what this whole thing is about, and GLEP 55 presents the best way of doing that changing. > Parse the ebuild, determine the EAPI,=20 > configure PackageManager, source ebuild. Problem solved. QED. >=20 > I wonder what portage does at the moment... 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. > Definition of problem is flawed within GLEP55=20 No, the definition of the problem is entirely accurate and correct. > > 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. >=20 > WHAT! > 1) The title of this GLEP is all about the solution The title describes the desired enhancement, yes. > 2) the Abstraction is all about the solution The abstract describes the desired enhancement in more detail, yes. > THEN finally we get the actual problem=20 The main proposal then expands upon the background and reasoning behind the enhancement, yes. > > It's a simple statement of fact. > if it *fact* provide results, provide details of how the results were=20 > obtained, provide details so others may reproduce independently, if > they want. Such things should be in the paper. It's true by definition. 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. > 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. This is covered by GLEP 55. > Infact it has already been stated:=20 > "Adding metadata to the filename is not required and is bad system=20 > design practice" Stating something doesn't make it true. You could just as easily argue that having PV in the filename is bad. > 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. --=20 Ciaran McCreesh --Sig_/hqpDr6RDhLWbFFGOPI6BZ1C Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkod0JAACgkQ96zL6DUtXhHtkQCgx4588tZpdb/Rk8DI4KE7MFpT 3hIAn1pzewGvQeHwrNs38Q7c+GpJJsYn =ZqQd -----END PGP SIGNATURE----- --Sig_/hqpDr6RDhLWbFFGOPI6BZ1C--