List Archive: gentoo-council
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Monday 14 December 2009 10:14:37 Ciaran McCreesh wrote:
> On Sun, 13 Dec 2009 21:31:11 -0500 Mike Frysinger wrote:
> > > Uh. No. As per the Council's request, we turned off kdebuild-1 for
> > > the approved generated versions of the spec, and we made it
> > > possible to show kdebuild-1-specific things in a different colour.
> > i'm talking about when this crap was added originally, not any recent
> > conversations
> That was when it was added.
and ? it should have been deleted then and it should be deleted now.
> > > So you're telling users who did what the Gentoo KDE project told
> > > them to do that you don't care about them enough to handle the
> > > removal in a carefully controlled manner?
> > no one here said you had to change your PM. i could care less about
> > your PM. feel free to keep that crap in your PM forever ...
> Keeping it around without a specification is a bad idea. And no, the
> plan is not to keep it anywhere forever. The plan is to keep it around
> until we can ensure that users aren't going to be affected by the
which is irrelevant to the PMS. fact is, only your PM supports it and no one
is telling you what to do with your PM. correctly removing it from PMS wont
affect any user whatsoever. absolutely no users would be affected by cleaning
up the PMS git tree.
> > it is after all your own fault.
> For helping the Gentoo KDE team out? I'll bear that in mind next time
> Gentoo developers want help with something.
what wonderful slant you have. you didnt work with the KDE team out of the
kindness of your heart, you worked with developers who were on your side and
controlled significant stack of Gentoo ebuilds that users relied on. their
only option to use the bleeding edge was to switch to your PM.
as for "it's what the official KDE docs said", that too is complete bs. there
are teams with more important ebuilds that have instructions that only work
with portage. if anyone tried to add these to the PMS, you'll fully bitch and
moan and block it from ever making it into the PMS. some of these rely on
portage behavior with the environment and some of these rely on behavior
portage has had for years (and before the PMS).
> > it's actually kind of sad how you can sit there and block any PMS
> > additions that have been used in the tree for years because you didnt
> > feel like implementing it in your PM
> Uh. Riiiiight. I'm just drowning in bug reports from users who're using
> ebuilds that break with Paludis because we haven't implemented things
> that've been used in the tree for years. Perhaps you'd care to back up
> your mud-slinging with some examples.
stop with your misdirection bullshit. you know plenty of examples. then
again, your style is to keep whining that you arent aware of anything until
someone explicitly mentions them, so there's prep*, FEATURES, and
CBUILD/CTARGET in econf to mention a few.
> > yet crap that was explicitly never official or in used in the tree
> > you feel you have a right to keep in the PMS.
> It was added at the request of the Gentoo KDE team. It wasn't added
> because I wanted it; it was added because Gentoo developers asked for
> it. I realise you like to pretend that the people who asked for it
> never existed, but the fact is they did, and it would be irresponsible
> of Gentoo to make users suffer because of internal politicking.
great ! so when are you going to add these features that have existed for
years in portage to the PMS ? your logic is complete crap.
> > it doesnt belong there, it never has, so delete it/branch it already.
> You still haven't explained why it's better to delete it now than to do
> a controlled removal that won't affect users.
and you have yet to show how your PM behavior is relevant one bit to the PMS
here. removing unofficial crap from the PMS has no bearing whatsoever on
ebuilds that require unofficial PMs. keep the crap in your PM forever for all
signature.asc (This is a digitally signed message part.)