From: Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
To: Patrick Lauer <patrick@gentoo.org>
Cc: gentoo-pms@lists.gentoo.org
Subject: Re: [gentoo-pms] tree-layout.tex small cleanup
Date: Sun, 20 Sep 2009 01:44:37 +0100 [thread overview]
Message-ID: <20090920014437.01510e88@snowmobile> (raw)
In-Reply-To: <200909200237.16176.patrick@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 3758 bytes --]
On Sun, 20 Sep 2009 02:37:16 +0200
Patrick Lauer <patrick@gentoo.org> wrote:
> > The KDE team are more than welcome to re-add it as an EAPI
> > controlled feature, either through EAPI 4 or through EAPI
> > kdebuild-2 as they prefer.
> >
> > There's a huge difference between doing something as a published
> > standard and doing something that violates a published standard.
>
> Now you're being quite inconsistent. If you are in support of what
> the "old" KDE team / genkdesvn did (create their own standard in an
> overlay and experiment with it) then you must also be in support of
> the "new" kde team doing the same.
If they do it as a published standard, yes, I'm entirely in favour of
it and would be happy to provide any assistance they require. If they do
it without proper EAPI markings and as an undocumented extension, then
no, I don't approve.
> So either kdebuild-1 was a bad thing (not approved by council, not
> even supported by any official package manager) or package.mask as a
> directory is a good thing (feature has been there since the Old
> Times, only used in an overlay, well documented, no compatibility
> issues)
package.mask as a directory as an extension that breaks
specification-compliant package managers is bad. As a documented,
standardised extension, it is good.
> Also, kdebuild-1 was used _before_ it was voted on by council (which
> doesn't seem to bother you because it was in an overlay) and never
> became an official standard (published yes, but that's irrelevant).
> So by your own logic using it was A Bad Thing To Do.
Published is entirely relevant. That it was approved by the KDE team
rather than the Council is not relevant, since it has no impact upon
anyone implementing a package manager.
> Or you only attacked funtoo (and their use of package.mask) for
> personal reasons?
I offered to help Funtoo do an EAPI funtoo-2 so they could use
package.mask as a directory. That offer remains open.
> I find this interpretation quite interesting, but I'm not that much
> into postmodern existentialism. You should do a subjective
> interpretation based on dadaism or the school of dancing goats.
>
> That being said I was merely pointing out that the statement in PMS
> ("bash version 3.0") has no base in reality anymore and has been de
> facto obsoleted. De jure the council has not voted against these
> violations, even when they were brought up quite a while ago
> (darkside claims 6-8 months ago).
They also haven't given us permission to change PMS.
> So independent of what you believe in or desire the statement in PMS
> is WRONG. As such it needs to be corrected.
PMS accurately reflects the most recent official decision from the
Council.
> If that happens on the short path by editing it directly or through
> the long path of letting council decide to have it edited doesn't
> matter to me, as long as PMS and reality can agree on basic things.
Then why have you still not followed the process to get the change
made? Why did you instead start blaming the PMS team for refusing to
exceed its authority?
> > > I would say that documenting the current state of things is quite
> > > relevant to the issue at hand. If you are bothered by facts please
> > > don't try to engage in discussions.
> >
> > Then why don't you follow the process we told you about for getting
> > it fixed?
>
> Well, it's on the council's agenda now. I would say that it's
> following process quite well. How about you don't ask questions you
> already know the answer to?
I've still not seen a thread discussing it on gentoo-dev@. Is there a
particular reason you're bypassing the normal process?
--
Ciaran McCreesh
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
prev parent reply other threads:[~2009-09-20 0:44 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-19 20:15 [gentoo-pms] tree-layout.tex small cleanup Patrick Lauer
2009-09-19 20:25 ` Ciaran McCreesh
2009-09-19 20:34 ` Patrick Lauer
2009-09-19 20:45 ` Ciaran McCreesh
2009-09-19 20:56 ` Patrick Lauer
2009-09-19 21:08 ` Ciaran McCreesh
2009-09-19 22:03 ` Ulrich Mueller
2009-09-19 22:11 ` Ciaran McCreesh
2009-09-19 22:31 ` Andrew D Kirch
2009-09-19 22:38 ` Ciaran McCreesh
2009-09-19 23:19 ` Andrew D Kirch
2009-09-19 23:27 ` Ciaran McCreesh
2009-09-19 22:43 ` Ulrich Mueller
2009-09-19 22:54 ` Ciaran McCreesh
2009-09-19 23:07 ` Patrick Lauer
2009-09-19 23:16 ` Ciaran McCreesh
2009-09-19 22:48 ` Patrick Lauer
2009-09-19 23:03 ` Ciaran McCreesh
2009-09-19 23:26 ` Patrick Lauer
2009-09-19 23:35 ` Ciaran McCreesh
2009-09-20 0:37 ` Patrick Lauer
2009-09-20 0:44 ` Ciaran McCreesh [this message]
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=20090920014437.01510e88@snowmobile \
--to=ciaran.mccreesh@googlemail.com \
--cc=gentoo-pms@lists.gentoo.org \
--cc=patrick@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