From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1K6ytv-0004iO-Dy for garchives@archives.gentoo.org; Fri, 13 Jun 2008 02:20:27 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 775F1E039D; Fri, 13 Jun 2008 02:20:25 +0000 (UTC) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.244]) by pigeon.gentoo.org (Postfix) with ESMTP id 2F6C2E039D for ; Fri, 13 Jun 2008 02:20:25 +0000 (UTC) Received: by rv-out-0708.google.com with SMTP id b17so3824361rvf.46 for ; Thu, 12 Jun 2008 19:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=PRi1EeM45wYUdEKQVfJ6QR1NNyZSU9V4ixIyEJxKeVU=; b=lh95ilTj/BsocG7wk2Zh7WQQ+FRqhY9deiW52+2ysJ22KIIXzzq3Ot2AfpXqz5p6u0 QcrZdL46LYGhVthcVhg6q9r4/Vpa4RA3VeQdyB2zjoLVL9oQVc/T4kXFYvCLymlI0ovh oIaFby8cZPfd3cMrHL8FxypnMd2nYOtxeiaFM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=tJbncO5XbmEZWrW/GiDI6dS0RQca4X8sHIGxcia6N8fzBYPfI0ulNmjkHojmwcx0ZO 110d8Lh0Gt5h6ctvxpOiAbaRR46zwWXiLFae877+aUj2LYJFcWFA7gwoP5lZkXd0HZuY yHeMj5VlAxocadOfhdcM6xJpqys8QVNR63lPE= Received: by 10.140.147.5 with SMTP id u5mr1471711rvd.274.1213323624689; Thu, 12 Jun 2008 19:20:24 -0700 (PDT) Received: from seldon ( [208.68.109.97]) by mx.google.com with ESMTPS id c20sm2796614rvf.1.2008.06.12.19.20.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 12 Jun 2008 19:20:24 -0700 (PDT) Date: Thu, 12 Jun 2008 19:20:23 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Cc: council@gentoo.org Subject: Re: [gentoo-dev] One-Day Gentoo Council Reminder for June Message-ID: <20080613022023.GC7943@seldon.metaweb.com> References: <20080611070618.54E4066E24@smtp.gentoo.org> <20080611111133.GA6803@seldon.hsd1.ca.comcast.net> <20080612170943.GE9607@comet> 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; protocol="application/pgp-signature"; boundary="LwW0XdcUbUexiWVK" Content-Disposition: inline In-Reply-To: <20080612170943.GE9607@comet> User-Agent: Mutt/1.5.13 (2006-08-11) X-Archives-Salt: a9297a82-b449-43d6-a3de-d87b0bb00baa X-Archives-Hash: 963f90b73e69c23b1fd25dccc2069fc3 --LwW0XdcUbUexiWVK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 12, 2008 at 10:09:43AM -0700, Donnie Berkholz wrote: > On 04:11 Wed 11 Jun , Brian Harring wrote: > > if the running of it satisfys the councils requirements of a *neutral*= =20 > > standard, if the proposed spec actually meets said standards, >=20 > Anyone working on a package manager (and anyone else suitably=20 > knowledgeable) should be able to get commit access to it. The only=20 > person "running" it is doing so by virtue of making the most commits. Person 'running' it is the one w/ commit control; as far as I know,=20 that's ciaran and halcy0n (latter being inactive from what I've seen). > > Effectively, we've watched it essentially progress into a standard=20 > > that effectively only the paludis folk are adherent to (if in doubt,=20 > > ask portage folk, my sending this mail is indicative of the pkgcore=20 > > standpoint)- it's about time the council comment upon it in light of=20 > > the general view. >=20 > I'd like to know what's holding you back from contributing to it,=20 > instead of telling us that someone else is doing things you don't like.= =20 > Is there some kind of technical barrier (like the TeX)? Or what? Are you= =20 > filing bugs against the parts you don't like? What's happening to them? Duncan's recent post, http://archives.gentoo.org/gentoo-dev/msg_3baa8ff0b7d3a65206ddaefa7cc4a346.= xml actually lays out some of the issues fairly succinctly. What he=20 doesn't state outright (and I shall) is that when bound by a standards=20 group actively hostile to your manager/involvement, the 'dog and pony=20 show' duncan refers to becomes far worse, and typically nastier. It becomes far less worth being involved additionally, if it's known=20 up front it's going to be flaming. Meanwhile, couple of technical faults ignored either for paludis=20 benefit, or (best I can figure) because I brought it up. 1) http://bugs.gentoo.org/show_bug.cgi?id=3D171291 metadata/cache (hence labeled flat_list cache format) mtime=20 requirements. This actually is a fairly old issue- I raised it when pms was first=20 finally shown to people. Basically issue is that for flat_list cache=20 format, the cache entries mtime is the ebuilds mtime. This was used=20 to try and detect stale cache entries via comparing ebuild mtime-=20 doesn't handle eclass related invalidation, but that is a seperate=20 issue. Current spec intentionally leaves out mtime, no mention of it. Why=20 this matters- paludis's implementation of flat_list (hence labeled=20 paludis_flat_list) differs- instead of the historical cache mtime =3D=3D=20 ebuild mtime, it's cache mtime =3D=3D max(ebuild mtime, eclasses mtimes). Personally, I don't care about their cache implementation on disk, as=20 long as it doesn't affect me - it's their way of addressing what=20 flat_hash for portage/pkgcore addresses, full eclass staleness=20 detection. Fair enough. What *does* matter is that via this omission in PMS, paludis_flat_list=20 is considered a valid cache for $PORTDIR/metadata/cache. Using=20 paludis_flat_list as $PORTDIR/metadata/cache means that=20 pkgcore/paludis identify the cache as stale, and regenerate it. In=20 other words, flat_list works with portage/pkgcore/paludis,=20 paludis_flat_list works with paludis only (triggering invalid=20 regeneration for the rest). It may seem minor, but think through the response when a=20 portage/pkgcore user hits a repository generated by paludis-=20 "pkgcore/portage are broke, not our fault" due to PMS omission of=20 historical behaviour. Issue is known, and ignored at this point. 2) http://bugs.gentoo.org/show_bug.cgi?id=3D196561; changing (within=20 eapi0) the behaviour of ~ operator. Currently, portage ignores any=20 revision for ~, pkgcore gives the finger if you try combining ~ with a=20 revision (it's not a valid atom), paludis follows the PMS rules; long term behaviour of ~; any revision of this version suffices. PMS/paludis behaviour: revisions greater then, or equal to this=20 revision, equal to this version. Why this matters; portage long term behaviour has been to drop -r*=20 when found. Parsing is/was loose, basically. Due to eapi0's nature,=20 one can't just force in what they think is the one true way, have to=20 force in what works for all and matches history. Issue is known, and ignored at this point. 3) good 'ole mr -r0 and the issues it triggers, http://bugs.gentoo.org/show_bug.cgi?id=3D215403 initial dev thread, http://archives.gentoo.org/gentoo-dev/msg_de84ebd5116546518879e266bf60f32b.= xml relevant flaws ignoring this issue induces: http://archives.gentoo.org/gentoo-dev/msg_f98bab69d67bd4132917be0eb04e8f3e.= xml Spawned by a rather odd commit from rbrown flushing out a user visible=20 breakage for pkgcore users, it also flushed out PM incompatibilities=20 in handling of PVR/PR; specifically since -r0 has *never* been used in=20 ebuild names, all ebuilds have been written assuming PVR lacks -r0. =20 What was the end result of this rather obnoxious (ebuild dev viewable)=20 variance? Accusations that pkgcore devs are trying to legislate away their=20 'bugs' (ignoring that the issue was fixed/released about the same time=20 as the accusation) while ignoring the issue in the spec. This obviously benefits the spec, although I'm not smart enough to see=20 how... Note these are just the issues from memory atm. I say memory since as=20 long as I've audited PMS, pointing out issues has basically been=20 intentionally stepping in front of the firing line. Hell, getting access to the damn thing required a fairly large amount=20 of BS/insults- http://article.gmane.org/gmane.linux.gentoo.devel/46163 Which was ignored (despite council backing it at the time), resulting=20 in http://article.gmane.org/gmane.linux.gentoo.devel/46417 . Essentially, what the last year/half of dealing w/ pms is culminating=20 in, is an ongoing buildup of reasons to *not* deal with the current=20 folk in control, end result being not dealing with pms. Shitty=20 scenario actually; either willingly get kicked in the shins, or ignore=20 it (thus ceding a voice in the format directly influencing your work). If that actually were to change, meaning folks could point out=20 flaws, interact w/ the controllers w/out getting their nuts blown=20 off, generally actually accomplish something other then being=20 taunted, yes, I'd be more then willing to reaudit the bugger and take=20 another stab at it. As it is however, contributing to it is effectively blocked by the=20 folks involved- and actual interaction w/ it serves only as a hammer=20 to beat on pkgcore with. To be clear; while I don't relish interacting w/ ciaran and co., I'm a=20 damned adult and willing to deal w/ folk I don't like. What I'm=20 unwilling to do however is be in the situation where I'm forced to=20 contribute to folk who are after baiting; it's just a waste of time,=20 simple as that, and it in no way benefits gentoo. ~harring --LwW0XdcUbUexiWVK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFIUdlmsiLx3HvNzgcRAqr8AJ9CSvJe3mayq2gkbR5HAeKbJcuq3ACguhKr c7GBKTf9iAABbEgmaf2QNlM= =R8QA -----END PGP SIGNATURE----- --LwW0XdcUbUexiWVK-- -- gentoo-dev@lists.gentoo.org mailing list