Re: [gentoo-pms] kdebuild-1 conditionales

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 5136 bytes --]

On Fri, 11 Dec 2009 12:30:22 -0800
Brian Harring <ferringb@gmail.com> wrote:
> > No, if a large project such as, say, the Gentoo KDE project, had
> > asked you for support for a well documented EAPI and you had
> > provided it, I would have also implemented that EAPI in Paludis.
> > 
> > kdebuild-1 was not done without consultation. It was the result of a
> > considerable amount of work from an official Gentoo project, and it
> > was a well defined, published standard. It was in no way an
> > experiment.
> 
> And if gnome decides they want their own format, is PMS/eapi stuck w/ 
> the bill?

If the Gentoo Gnome project produces their own documented format, then
yes, I'd expect the Gentoo PMS project to do everything it can to help
them with that if that was their desire. I would not expect the Gentoo
PMS project to say to the Gentoo Gnome project "no, go away, we're not
helping you".

> > > Regardless, if you didn't plan for phasing out an experimental
> > > eapi, it's not the mainstream eapi's problem- it's your mess to
> > > clean up.
> > 
> > kdebuild-1 was not experimental.
> 
> It wasn't official, thus *you* can view it was non-experimental w/in 
> the paludis realm, but it's experimental to gentoo as a whole- the 
> primary pkg manager, the official manager specifically, didn't even 
> support it.
> 
> It was experimental.

No, it was a published standard.

> PMS was irresponsible for allowing it into the official eapis in the 
> first place.  If KDE intended it to be supported long term (which I 
> strongly doubt, it was an overlay of unstable ebuilds after all),
> then they too were irresponsible.

It is not the place of the Gentoo PMS project to tell Gentoo developers
to sod off when they ask for help.

> > Writing a converter is more work than a simple phased removal.
> 
> I didn't imply a full format converter.  I implied a converter that 
> tweak it enough the thing could be uninstalled by *any* package 
> manager supporting eapi2.  I'd expect that would cover a significant 
> majority of any remaining (if even there are remaining) installed 
> pkgs.

Again, more work than a simple phased removal.

> > > That solves it technically, rather then just ignoring it and 
> > > pretending we won't have this exact discussion a year later w/
> > > the same claims as to why it can't be removed.
> > 
> > A year later, we can easily have had kdebuild-1 removed in a
> > responsible manner.
> 
> You have zero stats now to backup that statement- basically your 
> prediction of when it'll be fine to remove it is based on opinion.
> 
> Via the same rules, my opinion is that it's fine to remove it now.  1 
> -1 = 0.
> 
> Back this up w/ stats please in the future.

My proposed phasing out will take two Paludis major releases. That's
considerably less than a year.

> > More work than just doing it properly.
> 
> Depends on your definition of 'properly'.  I presume what you mean is 
> that it requires you to maintain a kdebuild pms pdf somewhere- more 
> work for you.

No, it requires just not removing anything for a bit longer.

> My stance, it's more work for the rest of us coding around the ifdef 
> mess (most recent bitchfest from it was grobian doing the prefix 
> patch).

Then ask the Council to let us just leave it in without ifdefs until
the phased removal is complete. Simple.

> Properly to me means using the dvcs's capabilities, and making it 
> easier for folks to do *official* eapi work w/out having to maintain 
> dross someone shoved into it.  Move the effort of maintaining
> kdebuild bits to those who are responsible for it, effectively.

Using git's capabilities is something you do if and only if you can't
use native capabilities. You don't see a million different versions of
the Linux kernel, each containing different configuration settings with
all the #ifdefs removed...

> > kdebuild-1 was not experimental. It was an official Gentoo KDE
> > project EAPI.
> 
> Goodie on them.  Note that it's "official gentoo kde project", not 
> "official eapi".

Are you saying that the Gentoo PMS project should tell other Gentoo
developers to go away when they ask for help?

> > And at the time, the Gentoo KDE project considered kdebuild-1 to be
> > an official EAPI.
> 
> And they have zero ability to define what is an official EAPI.  
> Misunderstanding reality bluntly, is their problem.

Are you saying that the Gentoo PMS project should overrule GLEP 39?

> Further, note prefix- that is a far more widespread deployment of an 
> experimental eapi, longer lived (and still living even).  PMS ain't
> on the hook for their experimental work- they went and got it
> approved as an EAPI, for the new EAPI pms is *now* on the hook.

Prefix never had an official, stable specification, which was all that
kept it out of PMS.

Again, you still haven't said what's wrong with doing a clean, phased
withdrawal. This looks a lot like you're jumping on the "let's try to
cause trouble and disrupt things" bandwagon here.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]