[gentoo-pms] kdebuild-1 conditionales

[gentoo-pms] kdebuild-1 conditionales

[Christian Faulhammer]

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

Hi,

in commit 6a281c0bc6b951c0885c8787fa5c353a4f4e3d0d I disabled
kdebuild-1 by default.  My proposal now is to drop the KDEBUILD
conditionals as a whole as the overlay has gone anyway, where it was
used.  We can add a sentence in the introduction or wherever which says
something along the lines like "kdebuild-1 was the first EAPI like
format that supported extended features added to official EAPIs later
on and was heavily tested in the official Gentoo KDE overlay".  This
would ease maintenance a bit.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

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

Re: [gentoo-pms] kdebuild-1 conditionales

[Ciaran McCreesh]

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

On Thu, 10 Dec 2009 21:48:48 +0100
Christian Faulhammer <fauli@gentoo.org> wrote:
> in commit 6a281c0bc6b951c0885c8787fa5c353a4f4e3d0d I disabled
> kdebuild-1 by default.  My proposal now is to drop the KDEBUILD
> conditionals as a whole as the overlay has gone anyway, where it was
> used.  We can add a sentence in the introduction or wherever which
> says something along the lines like "kdebuild-1 was the first EAPI
> like format that supported extended features added to official EAPIs
> later on and was heavily tested in the official Gentoo KDE overlay".
> This would ease maintenance a bit.

As we've already discussed:

* Stop committing things that aren't typo fixes without posting them to
  this list for review.

* Don't commit the EAPI 3 / 4 changes until the Council are done
  changing things, and until we have a patch for the new definition of
  EAPI 3. We don't have a definition for the new EAPI 3 yet. We also
  don't have approved summaries of any of the meetings where these
  things happened. Any changes done now are wasted effort.

* Don't mess with kdebuild until you're sure that no-one has any
  kdebuild packages installed.

And as we've not already discussed:

* When the heck did "use the highest EAPI" become policy?

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] kdebuild-1 conditionales

[Ulrich Mueller]

>>>>> On Thu, 10 Dec 2009, Ciaran McCreesh wrote:

> * Don't commit the EAPI 3 / 4 changes until the Council are done
>   changing things,

From the summary of the December Council meeting [1]:

| EAPI-3 status
| =============
| [...]
| Because prefix support will be EAPI-3 (see below), the EAPI items
| referenced here will be referred to as EAPI-4 in the future.

Official Council decision, therefore nothing to discuss. (And no, we
won't rename it back.)

>   We also don't have approved summaries of any of the meetings where
>   these things happened.

And what is [1] then?

Ulrich

[1] <http://www.gentoo.org/proj/en/council/meeting-logs/20091207-summary.txt>

Re: [gentoo-pms] kdebuild-1 conditionales

[Brian Harring]

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

On Thu, Dec 10, 2009 at 10:27:30PM +0000, Ciaran McCreesh wrote:
> * Don't mess with kdebuild until you're sure that no-one has any
>   kdebuild packages installed.

I'm not looking to start a fight, and frankly after a year or so I've 
learned to just subconsciously/automatically ignore kdebuild, but why 
exactly must this be in pms?

It's experimental w/ low user acceptance, and was fundamentally 
outside the gentoo mainstream.  If long term maintenance of it is 
desired for anyone who hasn't yet punted those ebuilds from their 
vdb, maintain it in a branch rather then the effective head (don't 
make the mainline suffer maintenance for something that was outside 
mainline).

My two cents mind you- at this point, flipping through the source, the 
kdebuild bits disrupt the flow from my view (and more importantly the 
resultant read of it due to folks trying to structure the text to be 
agnostic to non-kdebuild), more importantly doing so w/ minimal gain 
for the mainstream.

Either way, take it as a +1 for punting it from mainstream and making 
the kdebuild specific folk maintain their own branch rather then 
general eapi (gentoo specific) having to maintain it.  Branching of 
this sort is presumably one of the reasons pms uses a dvcs after all.

And to head off one angle of argument, I fully expect if I ever get 
ambitious enough to derive an eapi extension that I'll have to 
maintain it outside of pms mainline- being nonstandard, I'd expect 
nothing less (hence the +1 for punting kdebuild).

My two cents either way, and well aware it's probably not something 
everyone wants to hear.

Not a hard +1 since I've zero interest in a fight also, but a +1 
either way.

Sorry, but tis my views.
~harring

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

Re: [gentoo-pms] kdebuild-1 conditionales

[Maciej Mrozowski]

[-- Attachment #1: Type: Text/Plain, Size: 3243 bytes --]

On Friday 11 of December 2009 09:17:54 Brian Harring wrote:
> On Thu, Dec 10, 2009 at 10:27:30PM +0000, Ciaran McCreesh wrote:
> > * Don't mess with kdebuild until you're sure that no-one has any
> >   kdebuild packages installed.
> 
> I'm not looking to start a fight, and frankly after a year or so I've
> learned to just subconsciously/automatically ignore kdebuild, but why
> exactly must this be in pms?
> 
> It's experimental w/ low user acceptance, and was fundamentally
> outside the gentoo mainstream.  If long term maintenance of it is
> desired for anyone who hasn't yet punted those ebuilds from their
> vdb, maintain it in a branch rather then the effective head (don't
> make the mainline suffer maintenance for something that was outside
> mainline).
> 
> My two cents mind you- at this point, flipping through the source, the
> kdebuild bits disrupt the flow from my view (and more importantly the
> resultant read of it due to folks trying to structure the text to be
> agnostic to non-kdebuild), more importantly doing so w/ minimal gain
> for the mainstream.
> 
> Either way, take it as a +1 for punting it from mainstream and making
> the kdebuild specific folk maintain their own branch rather then
> general eapi (gentoo specific) having to maintain it.  Branching of
> this sort is presumably one of the reasons pms uses a dvcs after all.
> 
> And to head off one angle of argument, I fully expect if I ever get
> ambitious enough to derive an eapi extension that I'll have to
> maintain it outside of pms mainline- being nonstandard, I'd expect
> nothing less (hence the +1 for punting kdebuild).
> 
> My two cents either way, and well aware it's probably not something
> everyone wants to hear.
> 
> Not a hard +1 since I've zero interest in a fight also, but a +1
> either way.
> 
> Sorry, but tis my views.
> ~harring

PMS document is meant to provide information that can be relied upon. 
kdebuild-1 was used only during short period of time two years ago and only 
supported by one package manager. Gentoo KDE team has already expressed no 
interest in kdebuild-1 long time ago as well[1].
That being said kdebuild-1 can no longer be relied upon as a effective 
specification - it does not have implementation in official package manager 
and no new kdebuild-1 is going to be created ever by any Gentoo project - it's 
effectively dead besides all known .
Also, what's the most important - any official packages in kdebuild-1 format 
has already been replaced (with no loss of functionality, we're talking about 
KDE 4 ebuilds here) by official packages in EAPI-2 format - format supported 
by three most popular package managers and users as advised to migrate (if 
they haven't already) to those packages.
Otherwise they're unsupported anyway - and PMS needs to document things that 
are supported and can be relied upon.

There's anything more to add - kdebuild-1 PMS specification should be 
maintained by those interested in separate git branch, and completely removed 
from PMS trunk as it only serves as LaTeX code obfuscator.

http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg33146.html

On behalf of Gentoo KDE

-- 
regards
MM

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-pms] kdebuild-1 conditionales

[Ciaran McCreesh]

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

On Fri, 11 Dec 2009 07:08:32 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:
> > * Don't commit the EAPI 3 / 4 changes until the Council are done
> >   changing things,
> 
> From the summary of the December Council meeting [1]:
> 
> | EAPI-3 status
> | =============
> | [...]
> | Because prefix support will be EAPI-3 (see below), the EAPI items
> | referenced here will be referred to as EAPI-4 in the future.
> 
> Official Council decision, therefore nothing to discuss. (And no, we
> won't rename it back.)

Sure. But we don't have a spec of what EAPI 3 is, so we can't do
anything with it. We also don't know when we'll have a spec of what
EAPI 3 is, so there's no point in tinkering with PMS until we do. We've
tried to avoid having huge chunks of "todo" on the main branch since we
started viewing PMS as being more or less correct, and adding them back
in again is a huge step backwards.

We did all the original EAPI 3 work on a branch and didn't merge it
until it was done for a very good reason.

> >   We also don't have approved summaries of any of the meetings where
> >   these things happened.
> 
> And what is [1] then?

Something that wasn't there when I sent the original email, as you
know very well.

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] kdebuild-1 conditionales

[Ciaran McCreesh]

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

On Fri, 11 Dec 2009 00:17:54 -0800
Brian Harring <ferringb@gmail.com> wrote:
> On Thu, Dec 10, 2009 at 10:27:30PM +0000, Ciaran McCreesh wrote:
> > * Don't mess with kdebuild until you're sure that no-one has any
> >   kdebuild packages installed.
> 
> I'm not looking to start a fight, and frankly after a year or so I've 
> learned to just subconsciously/automatically ignore kdebuild, but why 
> exactly must this be in pms?

Because we have not yet established that no users have kdebuild things
installed. Thus, package managers that support it have to go on
supporting it.

Once kdebuild can be safely removed from package managers that have
supported it, it can then be removed from PMS.

> It's experimental w/ low user acceptance, and was fundamentally 
> outside the gentoo mainstream.  If long term maintenance of it is 
> desired for anyone who hasn't yet punted those ebuilds from their 
> vdb, maintain it in a branch rather then the effective head (don't 
> make the mainline suffer maintenance for something that was outside 
> mainline).

Branches are for use when you can't use better mechanisms. We have
better mechanisms.

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] kdebuild-1 conditionales

[Ciaran McCreesh]

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

On Fri, 11 Dec 2009 11:45:53 +0100
Maciej Mrozowski <reavertm@gmail.com> wrote:
> Also, what's the most important - any official packages in kdebuild-1
> format has already been replaced (with no loss of functionality,
> we're talking about KDE 4 ebuilds here) by official packages in
> EAPI-2 format - format supported by three most popular package
> managers and users as advised to migrate (if they haven't already) to
> those packages. Otherwise they're unsupported anyway - and PMS needs
> to document things that are supported and can be relied upon.

You haven't taken steps to verify that there aren't users with kdebuild
things still installed. Once you've taken those steps, then and only
then is it reasonable to remove kdebuild from PMS and package managers.
Until those steps are taken, what you're doing is purely political.

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] kdebuild-1 conditionales

[Christian Faulhammer]

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

Hi,

Ciaran McCreesh <ciaran.mccreesh@googlemail.com>:
> You haven't taken steps to verify that there aren't users with
> kdebuild things still installed. Once you've taken those steps, then
> and only then is it reasonable to remove kdebuild from PMS and
> package managers. Until those steps are taken, what you're doing is
> purely political.

 I will come to answer the other emails next week, but I want to reply
to that: You haven't taken steps to verify that there aren't users with
an EAPI-unaware package manager still installed.
 kdebuild-1 is not actively used since even the GenKDEsvn overlay has
been abandoned.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

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

Re: [gentoo-pms] kdebuild-1 conditionales

[Ulrich Mueller]

>>>>> On Fri, 11 Dec 2009, Ciaran McCreesh wrote:

>> I'm not looking to start a fight, and frankly after a year or so
>> I've learned to just subconsciously/automatically ignore kdebuild,
>> but why exactly must this be in pms?

> Because we have not yet established that no users have kdebuild
> things installed.

This is not a fact that could ever be verified, therefore your
argument is nonsensical.

> Thus, package managers that support it have to go on supporting it.
> Once kdebuild can be safely removed from package managers that have
> supported it, it can then be removed from PMS.

Last mention of kdebuild was removed from the KDE overlay at
2008-09-23, which was more than one year ago. Generally we don't
support upgrades of outdated systems for more than one year.

But it's irrelevant anyway, since it was never an approved EAPI.
Therefore, we can remove it any time.

And as was already pointed out several times, there was a council
decision about the issue in the 2008-04-10 meeting:

| The council voted that kdebuild-1 and other unapproved EAPIs could 
| not be in an approved PMS document. The spec isn't a place for 
| proposals or things that will never be submitted for approval by the 
| council. It's a specification, a reference of what is allowed in the 
| main tree.

Ulrich

Re: [gentoo-pms] kdebuild-1 conditionales

[Ulrich Mueller]

>>>>> On Fri, 11 Dec 2009, Ciaran McCreesh wrote:

> We also don't know when we'll have a spec of what EAPI 3 is, so
> there's no point in tinkering with PMS until we do.

Come on. Renaming from 3 to 4 is trivial.

>> >   We also don't have approved summaries of any of the meetings where
>> >   these things happened.
>> 
>> And what is [1] then?

> Something that wasn't there when I sent the original email, as you
> know very well.

It was on the council page when I read your mail. And is this in any
way relevant? We have a summary now.

Ulrich

Re: [gentoo-pms] kdebuild-1 conditionales

[David Leverton]

On Friday 11 December 2009 06:08:32 Ulrich Mueller wrote:
> Official Council decision, therefore nothing to discuss.

Same as when the previous EAPI 3 was approved back in May?

> (And no, we won't rename it back.)

Scout's Honour?

Re: [gentoo-pms] kdebuild-1 conditionales

[Ciaran McCreesh]

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

On Fri, 11 Dec 2009 15:44:12 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:
> >> I'm not looking to start a fight, and frankly after a year or so
> >> I've learned to just subconsciously/automatically ignore kdebuild,
> >> but why exactly must this be in pms?
> 
> > Because we have not yet established that no users have kdebuild
> > things installed.
> 
> This is not a fact that could ever be verified, therefore your
> argument is nonsensical.

Yes it is. All you have to do is send an email to a mailing list that
gets read by everyone who could be using kdebuild-1, and give them a
reasonable time to reply. Alternatively, you could target a news item
at those users, informing them of the removal. Either is entirely
doable and a totally reasonable measure to take.

> > Thus, package managers that support it have to go on supporting it.
> > Once kdebuild can be safely removed from package managers that have
> > supported it, it can then be removed from PMS.
> 
> Last mention of kdebuild was removed from the KDE overlay at
> 2008-09-23, which was more than one year ago. Generally we don't
> support upgrades of outdated systems for more than one year.

The genkdesvn overlay was around for considerably longer than that.
Also, we're talking *installed* packages here, not installable ones.
Users have installed packages going back a very very long time.

> But it's irrelevant anyway, since it was never an approved EAPI.
> Therefore, we can remove it any time.
> 
> And as was already pointed out several times, there was a council
> decision about the issue in the 2008-04-10 meeting:
> 
> | The council voted that kdebuild-1 and other unapproved EAPIs could 
> | not be in an approved PMS document. The spec isn't a place for 
> | proposals or things that will never be submitted for approval by
> the | council. It's a specification, a reference of what is allowed
> in the | main tree.

And there is a way of getting PMS built without kdebuild-1, for
approval. In the mean time, PMS is there to be useful to package
manager developers, and so kdebuild-1 needs to remain so long as
package managers support it.

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] kdebuild-1 conditionales

[Ciaran McCreesh]

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

On Fri, 11 Dec 2009 16:02:41 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>> On Fri, 11 Dec 2009, Ciaran McCreesh wrote:
> > We also don't know when we'll have a spec of what EAPI 3 is, so
> > there's no point in tinkering with PMS until we do.
> 
> Come on. Renaming from 3 to 4 is trivial.

But dumping in a bunch of "we don't know" sections into the main branch
for 3 is completely against existing practice. We very deliberately
didn't do that for works in progress for previous EAPIs. Why change now?

> >> >   We also don't have approved summaries of any of the meetings
> >> > where these things happened.
> >> 
> >> And what is [1] then?
> 
> > Something that wasn't there when I sent the original email, as you
> > know very well.
> 
> It was on the council page when I read your mail. And is this in any
> way relevant? We have a summary now.

Because your sarcastic reply suggests some kind of inaccuracy on my
part, whereas in fact you're trying to pull a fast one. A correct and
appropriate response would be "This has now been fixed [1]". For
someone who complains about a lack of goodwill when people point out
problems with your patches, you're certainly not going out of the way
to set a better example.

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] kdebuild-1 conditionales

[Ciaran McCreesh]

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

On Fri, 11 Dec 2009 15:23:01 +0100
Christian Faulhammer <fauli@gentoo.org> wrote:
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com>:
> > You haven't taken steps to verify that there aren't users with
> > kdebuild things still installed. Once you've taken those steps, then
> > and only then is it reasonable to remove kdebuild from PMS and
> > package managers. Until those steps are taken, what you're doing is
> > purely political.
> 
>  I will come to answer the other emails next week

In the mean time, please revert all your changes that didn't follow the
standard review procedure.

>, but I want to reply
> to that: You haven't taken steps to verify that there aren't users
> with an EAPI-unaware package manager still installed.
>  kdebuild-1 is not actively used since even the GenKDEsvn overlay has
> been abandoned.

So? I said *still installed*. We can't drop EAPI support until users
don't have packages *installed* using that EAPI.

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] kdebuild-1 conditionales

[Ulrich Mueller]

>>>>> On Fri, 11 Dec 2009, Ciaran McCreesh wrote:

> [...] kdebuild-1 needs to remain so long as package managers support it.

We can considerably shorten this discussion, because it boils down to
the following: PMS is an official Gentoo document, and therefore it's
not upon you to make this decision.

Ulrich

Re: [gentoo-pms] kdebuild-1 conditionales

[Ciaran McCreesh]

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

On Fri, 11 Dec 2009 18:11:19 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>> On Fri, 11 Dec 2009, Ciaran McCreesh wrote:
> > [...] kdebuild-1 needs to remain so long as package managers
> > support it.
> 
> We can considerably shorten this discussion, because it boils down to
> the following: PMS is an official Gentoo document, and therefore it's
> not upon you to make this decision.

Alright. We'll escalate this to the Council then.

Council: please vote on the following at the next meeting:

"kdebuild-1 to be kept in PMS as-is until we're reasonably sure that no
users have installed packages that use kdebuild-1. Since kdebuild-1 is
no longer actively used for installable packages, when time permits, and
to fit in with the normal release cycle, the Paludis team shall take
steps to notify users who do have installed kdebuild-1 packages that
they should uninstall those packages. This shall be done by having a
deprecation check for at least one major version (x.y) series of
releases before removal in the subsequent major version (x.z)."

In the mean time, I'll give Christian a day or two to revert every
patch he's applied recently that didn't follow the Council-mandated
review process, or I can do the revert for him if he doesn't have time
himself.

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] kdebuild-1 conditionales

[Ulrich Mueller]

>>>>> On Fri, 11 Dec 2009, Ciaran McCreesh wrote:

>> It was on the council page when I read your mail. And is this in
>> any way relevant? We have a summary now.

> Because your sarcastic reply suggests some kind of inaccuracy on my
> part,

Yes, sorry, I didn't double check the commit time of the summary when
I found that it's on the council's page. Also leio had sent the final
version to the council ml two days before.

> whereas in fact you're trying to pull a fast one.

Not true.

> A correct and appropriate response would be "This has now been fixed
> [1]".

Right. This has now been fixed. So can we end this useless discussion
now?

Ulrich

Re: [gentoo-pms] kdebuild-1 conditionales

[Ulrich Mueller]

>>>>> On Fri, 11 Dec 2009, Ciaran McCreesh wrote:

>> We can considerably shorten this discussion, because it boils down
>> to the following: PMS is an official Gentoo document, and therefore
>> it's not upon you to make this decision.

> Alright. We'll escalate this to the Council then.

No need for that, as it has already been voted on in the 2008-04-10
council meeting (repeating it, as you've added gentoo-council to CC):

| The council voted that kdebuild-1 and other unapproved EAPIs could
| not be in an approved PMS document. The spec isn't a place for
| proposals or things that will never be submitted for approval by the
| council. It's a specification, a reference of what is allowed in the
| main tree.

> In the mean time, I'll give Christian a day or two to revert every
> patch he's applied recently that didn't follow the Council-mandated
> review process, or I can do the revert for him if he doesn't have
> time himself.

Don't.

Ulrich

Re: [gentoo-pms] kdebuild-1 conditionales

[Ciaran McCreesh]

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

On Fri, 11 Dec 2009 18:34:09 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>> On Fri, 11 Dec 2009, Ciaran McCreesh wrote:
> >> We can considerably shorten this discussion, because it boils down
> >> to the following: PMS is an official Gentoo document, and therefore
> >> it's not upon you to make this decision.
> 
> > Alright. We'll escalate this to the Council then.
> 
> No need for that, as it has already been voted on in the 2008-04-10
> council meeting (repeating it, as you've added gentoo-council to CC):
> 
> | The council voted that kdebuild-1 and other unapproved EAPIs could
> | not be in an approved PMS document. The spec isn't a place for
> | proposals or things that will never be submitted for approval by the
> | council. It's a specification, a reference of what is allowed in the
> | main tree.

And the resolution for that was to make it possible to disable
kdebuild-1. That is not the same as deleting it while there are still
users who have kdebuild-1 packages installed.

I shall remind you, the Council-approved process for PMS changes is to
send them to this list, and if unanimous agreement can't be reached,
then to escalate the issue to the Council.

> > In the mean time, I'll give Christian a day or two to revert every
> > patch he's applied recently that didn't follow the Council-mandated
> > review process, or I can do the revert for him if he doesn't have
> > time himself.
> 
> Don't.

Sorry, but the Council-approved procedure is that patches get sent to
this list and don't get committed until there aren't objections. We
don't commit things until everyone's happy with them.

I have objections to several of those patches, and they haven't been
addressed. If you'd like to address them now, please do so:

* When did it become policy to use the newest EAPI for ebuilds? I
  must've missed that becoming policy -- last I heard, policy was to
  use the oldest EAPI that provides everything you need to write a good
  ebuild.

* Since PMS became 'suitable for use', we've never committed works in
  progress to master. We've always used branches for EAPI definitions
  that aren't complete, and we've never committed EAPIs that haven't
  had their wording approved by the Council to master. Why are we
  changing this policy? Where was this policy change discussed?

* Why is disabling kdebuild-1 by default helpful? Why not take the
  reasonable steps already mentioned first, to ensure that the change
  does not have adverse impact?

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] kdebuild-1 conditionales

[Ulrich Mueller]

>>>>> On Fri, 11 Dec 2009, Ciaran McCreesh wrote:

> I shall remind you, the Council-approved process for PMS changes is
> to send them to this list, and if unanimous agreement can't be
> reached, then to escalate the issue to the Council.

> [...]

> Sorry, but the Council-approved procedure is that patches get sent
> to this list and don't get committed until there aren't objections.
> We don't commit things until everyone's happy with them.

Can you provide a reference for the above please?

> * When did it become policy to use the newest EAPI for ebuilds? I
>   must've missed that becoming policy -- last I heard, policy was to
>   use the oldest EAPI that provides everything you need to write a
>   good ebuild.

I agree on this one.

> * Since PMS became 'suitable for use', we've never committed works
>   in progress to master. We've always used branches for EAPI
>   definitions that aren't complete, and we've never committed EAPIs
>   that haven't had their wording approved by the Council to master.
>   Why are we changing this policy? Where was this policy change
>   discussed?

It's not very helpful to generalise. Let's look at the details, namely
Christian's commits instead:

- "Change minimum required Bash version from 3.0 to 3.2"
   This is a patch prepared by tanderson, and fauli only fixed a
   technical problem (footnotes) with LaTeX. I happen to have a log of
   the discussion in #-dev. Also from your comments in bug 292646 I
   got the impression that you had no objections to the change?

> * Why is disabling kdebuild-1 by default helpful? Why not take the
>   reasonable steps already mentioned first, to ensure that the change
>   does not have adverse impact?

- "Disable kdebuild-1 by default"
   This just changes a binary flag from true to false, namely it
   disables inclusion of kdebuild in the output document. How can this
   change have any adverse impact?

Ulrich

Re: [gentoo-pms] kdebuild-1 conditionales

[Ciaran McCreesh]

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

On Fri, 11 Dec 2009 19:14:39 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:
> > I shall remind you, the Council-approved process for PMS changes is
> > to send them to this list, and if unanimous agreement can't be
> > reached, then to escalate the issue to the Council.
> 
> > [...]
> 
> > Sorry, but the Council-approved procedure is that patches get sent
> > to this list and don't get committed until there aren't objections.
> > We don't commit things until everyone's happy with them.
> 
> Can you provide a reference for the above please?

Meetings on 20080911 and 20080828, which lead to the "Reporting Issues"
section of PMS.

> > * Since PMS became 'suitable for use', we've never committed works
> >   in progress to master. We've always used branches for EAPI
> >   definitions that aren't complete, and we've never committed EAPIs
> >   that haven't had their wording approved by the Council to master.
> >   Why are we changing this policy? Where was this policy change
> >   discussed?
> 
> It's not very helpful to generalise. Let's look at the details, namely
> Christian's commits instead:

Yes, let's. We agree that the "most recent EAPI" patch was wrong and
shouldn't have been committed, so that's one...

> - "Change minimum required Bash version from 3.0 to 3.2"
>    This is a patch prepared by tanderson, and fauli only fixed a
>    technical problem (footnotes) with LaTeX. I happen to have a log of
>    the discussion in #-dev. Also from your comments in bug 292646 I
>    got the impression that you had no objections to the change?

I have no objections to the change, although I would have suggested a
slightly cleaner wording had I seen the patch before it was applied.

> > * Why is disabling kdebuild-1 by default helpful? Why not take the
> >   reasonable steps already mentioned first, to ensure that the
> > change does not have adverse impact?
> 
> - "Disable kdebuild-1 by default"
>    This just changes a binary flag from true to false, namely it
>    disables inclusion of kdebuild in the output document. How can this
>    change have any adverse impact?

The impact is that those of us using PMS for developing a package
manager have to go back and change it.

It's not a typo or formatting fix, so it should have gone to the list
for review. It doesn't take long to do a quick git send-email, and it
does provide a much better degree of quality control. If nothing
else, it's also a basic courtesy to other developers on the project.

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] kdebuild-1 conditionales

[Brian Harring]

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

On Fri, Dec 11, 2009 at 06:27:39PM +0000, Ciaran McCreesh wrote:
> On Fri, 11 Dec 2009 19:14:39 +0100
> The impact is that those of us using PMS for developing a package
> manager have to go back and change it.

Not really.

Paludis is, and was, the only one that supported kdebuild.  Meaning 
any user of kdebuild is *already* bound to paludis- again, bluntly, 
this is a paludis specific mess.  If I ever write anything kdebuild 
specific, it would be a converter- this is something the paludis folk 
should be doing if they're really concerned about users still running 
kdebuild (since you'd just have to focus on *rm phases, it's pretty 
straightforward).

Bluntly, you would be pissed if you got stuck having long term support 
for an experimental eapi I split w/out consult- why do you think that 
the reverse wouldn't hold?  My point here is that pkgcore won't be 
implementing kdebuild anytime soon, nor would I expect portage ever to 
do so.  At best, a converter might be written, but that's it- I'm not 
going to put time into a dead format for a mess that isn't mine, 
essentially.

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.  
If the user goes and installs something experimental/unsupported, 
that's their issue- the folks they can yell at are their upstream 
(the manager in this case, and gentoo kde).

If we did as you asked, we would have to document every pre eapi 
portage has had (at least 8 off the top of my head), the previous 
iterations of prefix, and realistically, the exherbo format should 
some user manage to install an exheres-0 build into a gentoo box.  
This *is* the case- it's applying the same logic you're using for 
trying to keep kdebuild-1 in.

What I find pointless about this discussion is this notion that 
because you jammed kdebuild into the official eapi doc, the pms team 
in it's current incarnation is responsible for keeping kdebuild 
around and cleaning up that mess.


The proper cleanup if you really wanted this done is the following:
1) add warnings into paludis if kdebuild is detected installed, 
telling them to upgrade/remove whatever, and/or-
2) write a converter.  As said, since it's only *rm phases you really 
have to care about for allowing it to be removed by other managers, 
this isn't incredibly hard- further, full metadata rewrite is probably 
possible w/ eapi2 bits.
3) send out notifications via paludis lists, channels, whatever- 
basically since this is paludis specific, use those mediums to contact 
people and let them know the experiment is dead (they should be 
listening on those mediums anyways).

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.

Additional thing- note the compromise I mentioned, adding into PMS 
urls directing users where to go for experimental format information, 
or to get at old/dead official eapis.  If they can't catch a 
paragraph upfront telling them where to look, it's their problem.

Meanwhile, you can maintain the ifdef'd bits in your own branch- hell, 
just a copy of the existing pms pdf would suffice since kdebuild is a 
locked/dead format anyways.

Finally, and I admit this is a bit barbed- any user who install this 
eapi should've known it was experimental and that they could get 
support for it for paludis only.  If the user thought it was someday 
going to become an official eapi, that's the user/managers problem, 
not ours.

Our problem, and our sole area of responsibility , is the latex 
obfuscation mess- via git, shifting of maintenance of the kdebuild 
spec to paludis is easy.

More importantly, pms's responsibility/purpose for gentoo is 
presenting users with documentation on the *official* eapis- forcing 
kdebuild bits into that doc misleads users into thinking kdebuild is 
official, thus supported.  User confusion there is, and has been, 
rather annoying.

~harring

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

Re: [gentoo-pms] kdebuild-1 conditionales

[Ciaran McCreesh]

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

On Fri, 11 Dec 2009 11:42:41 -0800
Brian Harring <ferringb@gmail.com> wrote:
> Bluntly, you would be pissed if you got stuck having long term
> support for an experimental eapi I split w/out consult- why do you
> think that the reverse wouldn't hold?

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.

> 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.

> If we did as you asked, we would have to document every pre eapi 
> portage has had (at least 8 off the top of my head), the previous 
> iterations of prefix, and realistically, the exherbo format should 
> some user manage to install an exheres-0 build into a gentoo box.  
> This *is* the case- it's applying the same logic you're using for 
> trying to keep kdebuild-1 in.

Er, no. None of those have ever been published, documented standards.

> What I find pointless about this discussion is this notion that 
> because you jammed kdebuild into the official eapi doc, the pms team 
> in it's current incarnation is responsible for keeping kdebuild 
> around and cleaning up that mess.

No no no. Because the Gentoo PMS project, at the request of the Gentoo
KDE project, included support for one of their published EAPIs, the
Gentoo PMS project would be irresponsible to just remove it without
ensuring that it won't affect users.

> 2) write a converter.  As said, since it's only *rm phases you really 
> have to care about for allowing it to be removed by other managers, 
> this isn't incredibly hard- further, full metadata rewrite is
> probably possible w/ eapi2 bits.

Writing a converter is 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.

> Additional thing- note the compromise I mentioned, adding into PMS 
> urls directing users where to go for experimental format information, 
> or to get at old/dead official eapis.  If they can't catch a 
> paragraph upfront telling them where to look, it's their problem.

More work than just doing it properly.

> Finally, and I admit this is a bit barbed- any user who install this 
> eapi should've known it was experimental and that they could get 
> support for it for paludis only.  If the user thought it was someday 
> going to become an official eapi, that's the user/managers problem, 
> not ours.

kdebuild-1 was not experimental. It was an official Gentoo KDE project
EAPI.

> More importantly, pms's responsibility/purpose for gentoo is 
> presenting users with documentation on the *official* eapis- forcing 
> kdebuild bits into that doc misleads users into thinking kdebuild is 
> official, thus supported.  User confusion there is, and has been, 
> rather annoying.

And at the time, the Gentoo KDE project considered kdebuild-1 to be an
official EAPI.

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] kdebuild-1 conditionales

[Brian Harring]

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

On Fri, Dec 11, 2009 at 07:53:32PM +0000, Ciaran McCreesh wrote:
> On Fri, 11 Dec 2009 11:42:41 -0800
> Brian Harring <ferringb@gmail.com> wrote:
> > Bluntly, you would be pissed if you got stuck having long term
> > support for an experimental eapi I split w/out consult- why do you
> > think that the reverse wouldn't hold?
> 
> 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?


> > 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.


> > What I find pointless about this discussion is this notion that 
> > because you jammed kdebuild into the official eapi doc, the pms team 
> > in it's current incarnation is responsible for keeping kdebuild 
> > around and cleaning up that mess.
> 
> No no no. Because the Gentoo PMS project, at the request of the Gentoo
> KDE project, included support for one of their published EAPIs, the
> Gentoo PMS project would be irresponsible to just remove it without
> ensuring that it won't affect users.

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.

Frankly, it's irresponsible of PMS right now to leave it in the docs- 
I've seen too much confusion from users about what is supported/not 
because of it.  That *is* irresponsible to leave in place.


> > 2) write a converter.  As said, since it's only *rm phases you really 
> > have to care about for allowing it to be removed by other managers, 
> > this isn't incredibly hard- further, full metadata rewrite is
> > probably possible w/ eapi2 bits.
> 
> 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.


> > 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.


> > Additional thing- note the compromise I mentioned, adding into PMS 
> > urls directing users where to go for experimental format information, 
> > or to get at old/dead official eapis.  If they can't catch a 
> > paragraph upfront telling them where to look, it's their problem.
> 
> 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.

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).

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.


> > Finally, and I admit this is a bit barbed- any user who install this 
> > eapi should've known it was experimental and that they could get 
> > support for it for paludis only.  If the user thought it was someday 
> > going to become an official eapi, that's the user/managers problem, 
> > not ours.
> 
> 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".

Then they can maintain it w/ paludis, rather then the current PMS 
incarnation being stuck with it.


> > More importantly, pms's responsibility/purpose for gentoo is 
> > presenting users with documentation on the *official* eapis- forcing 
> > kdebuild bits into that doc misleads users into thinking kdebuild is 
> > official, thus supported.  User confusion there is, and has been, 
> > rather annoying.
> 
> 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.

As I said, are we on the hook if gnome decides they want their own 
format?  No.

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.

That's the proper way to have an official eapi.  Someone 
misunderstanding reality, or misrepresenting reality and claiming an 
experimental eapi is 'official' is not our problem, and not even 
remotely something we should be bound by.

I'll note finally that when gentoo-kde went and had their brief liason 
w/ kdebuild, the issues of long term support of the format were known- 
further it was made abundantly clear to them that from portage/pkgcore 
standpoint it was an experimental eapi and there wasn't a gurantee 
we'd ever implement it (in my case I'm reasonably sure the phrase 
"when hell freezes over" was uttered more then once).

I'm sorry if this causes folks any issue, but both paludis and 
gentoo-kde knew what they were getting into when they went down this 
path.  Frankly I really don't think any users are going to be affected 
by punting this out of PMS- paludis still carries the support (and is 
the users only option from day one for removing those packages)

You're arguing this must remain in PMS so that folks implementing 
managers can see it.  Nobody is going to implement kdebuild- at best I 
may write a converter just to bail those users out, but that's likely 
the extent of effort people will extend on cleaning it up.

Beyond that, a compromise was offered so that experimental eapis, and 
dead/old eapis can be retired from the document.

Gentoo doesn't really even need to do that- that's just an attempt to 
be nice and compromise.  If that's not good enough, frankly, tough 
cookies from where I'm sitting.

~harring

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

Re: [gentoo-pms] kdebuild-1 conditionales

[Ciaran McCreesh]

[-- 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 --]

Re: [gentoo-pms] kdebuild-1 conditionales

[Ciaran McCreesh]

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

On Fri, 11 Dec 2009 16:02:41 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:
> > We also don't know when we'll have a spec of what EAPI 3 is, so
> > there's no point in tinkering with PMS until we do.
> 
> Come on. Renaming from 3 to 4 is trivial.

...and, from the looks of things, completely wrong. Zac has started
putting some of the things that that patch moved from 3 to 4 in the
3_pre series. Now we're going to have to play a fun game of bouncing
things backwards and forward between EAPIs to match Zac's whims, which
don't seem to agree with the most recent Council vote on the subject.

As I said when Christian first asked, waiting until all this had been
settled before doing anything is the much better solution.

-- 
Ciaran McCreesh

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

Re: [gentoo-council] Re: [gentoo-pms] kdebuild-1 conditionales

[Ciaran McCreesh]

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

On Sat, 12 Dec 2009 22:45:48 -0500
Mike Frysinger <vapier@gentoo.org> wrote:
> > And the resolution for that was to make it possible to disable
> > kdebuild-1.
> 
> you were told multiple times that it doesnt belong in the master
> branch and that it should be deleted.  if you actually wanted to
> retain it, you could easily create a kdebuild-1 branch.

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.

22:22 < dberkholz@> ciaranm: you've got your answer. gotta keep the
conditionals, it seems

> > That is not the same as deleting it while there are still
> > users who have kdebuild-1 packages installed.
> 
> the only people who have such packages installed were using an
> unapproved spec with unofficial package managers.  as such, it is
> their problem to continue to support the crap and  this argument is
> bunk.

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?

-- 
Ciaran McCreesh

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

Re: [gentoo-council] Re: [gentoo-pms] kdebuild-1 conditionales

[Ciaran McCreesh]

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

On Sun, 13 Dec 2009 21:31:11 -0500
Mike Frysinger <vapier@gentoo.org> 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.

> > 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
removal.

> 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.

> 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.

> 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.

> 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.

-- 
Ciaran McCreesh

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

Re: [gentoo-council] Re: [gentoo-pms] kdebuild-1 conditionales

[Ciaran McCreesh]

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

On Mon, 14 Dec 2009 12:01:03 -0500
Mike Frysinger <vapier@gentoo.org> wrote:
> > > 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.

Not what the Council said. Your personal opinion wasn't what was voted.

> > 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 removal.
> 
> 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.

As has already been explained, keeping the spec around is a necessary
part of keeping the implementation around.

> > > 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.

No, I worked with developers who asked me for help, and I gave them
what they asked for, after insisting that it was done as a public,
documented standard precisely to avoid it by necessity being restricted
to a single package manager. That you don't like a decision made by a
Gentoo project is your problem.

> 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.

I highly doubt that, since if that were the case we'd be receiving
reports from users about it.

> 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).

Er, no. If that were the case, users wouldn't be able to use Paludis.

> > 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*,

prep* can't go in since what it does has yet to be locked down or
guaranteed. We can't spec it as "does something arbitrary", yet that's
all prep* is guaranteed to do. And, as you know, EAPI 4 has had
features added to it to give you what you were after, except done in a
well defined manner.

> FEATURES

There is no legitimate use for FEATURES in the tree, since something
being in FEATURES only indicates that the user asked for it, not that
it is enabled. For example, ebuilds that do has userpriv $FEATURES are
broken, because userpriv in features does not mean that userpriv has
actually been enabled by Portage.

> and CBUILD/CTARGET in econf to mention a few.

Could you point me to the bug for that one please? I think I can see
what PMS might be missing on that one, but I don't recall ever seeing a
bug about it, or what the conclusion was. I also can't find the bug by
searching for comments containing all of the words "pms ctarget", or
"pms cbuild".

> > > 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.

If you want FEATURES to be able to be used reliably by ebuilds, you'll
have to get the Portage people to implement that in a new EAPI first.

If you want prep*, you'll have to ask the Portage people to guarantee
that they'll stop changing what it does so we can spec it in in a new
EAPI. However, since EAPI 4 includes a well defined alternative to
prep* abuse, there's probably no need.

I'll give you an answer for CHOST / CTARGET when you point me to the
bug for it, since I can't find it myself and I can't recall what the
conclusion was.

> > > 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 i care.

Uh. See earlier emails in the thread.

-- 
Ciaran McCreesh

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

Re: [gentoo-council] Re: [gentoo-pms] kdebuild-1 conditionales

[Ciaran McCreesh]

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

On Mon, 14 Dec 2009 11:00:56 -0800
Ned Ludd <solar@gentoo.org> wrote:
> As pointed out many times to you. kdebuild has nothing with do with
> Gentoo proper. I see no reason that it should concern the council at
> all. I do not intend to vote on this item and consider the matter EOF.

Ok. You're ignoring every previous Council decision on the matter, and
you're ignoring the Council decision on how the PMS project is supposed
to handle disagreement.

In that case, I'll withdraw my request, and shall just nuke kdebuild-1
support straight away with a simple news item for Paludis users.

-- 
Ciaran McCreesh

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

Re: [gentoo-council] Re: [gentoo-pms] kdebuild-1 conditionales

[Brian Harring]

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

Pulling the thread back since the next chunk of is is going 
completely cyclical/misdirection if left as is..


On Mon, Dec 14, 2009 at 12:01:03PM -0500, Mike Frysinger wrote:
> On Monday 14 December 2009 10:14:37 Ciaran McCreesh wrote:
> > On Sun, 13 Dec 2009 21:31:11 -0500 Mike Frysinger wrote:
> > > 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 
> i care.

The fact Ciaran is explicitly ducking is that pulling KDEBUILD out of 
PMS in no shape or form actually screws those users.  Paludis created 
the eapi extension for them to use, it's their responsibility for 
maintaining the env or giving the uesrs a migration path away from it.  
The responsibility is at the PM level.

PMS is irrelevant to that.  I seriously doubt any user of KDEBUILD 
Ciaran is worried about will go looking in PMS for a description of 
how to get out of that mess... further, I seriously doubt anyone of 
those users ever looked at KDEBUILD in PMS in the first place- they 
were consumers at best.  Gentoo kde devs may've, but they're not the 
ones involved in the "oh think of the children!" claims of why the 
spec must stay in official docs.

I already suggested a workable compromise- punt it out of PMS, add a 
section to PMS of unofficial/experimental eapis w/ urls to those 
docs/versions of PMS.  We get the doc back to official EAPIs and a 
fair bit easier to edit, Ciaran gets his little hook to quiet him 
down.

Via this, if a dev *really* wanted to track down KDEBUILD and was 
completely incompetent in their googling skills, they still would find 
the spec.

As for users... no user is going to look at PMS for information on 
what's going on w/ paludis/KDEBUILD/the gentoo kde overlay.  Kindly 
drop the "think of the children/user" cry- it's not relevant to PMS, 
only to how paludis maintaing KDEBUILD support.

If that's not enough, just leave it to a fricking council vote.  
Already had a week of this stonewalling, it's wasting folks time (and 
nerves) dealing w/ it any further.

~harring

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

Re: [gentoo-pms] kdebuild-1 conditionales

[Christian Faulhammer]

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

Hi,

after a week of real-life work, I was able to catch up with the whole
mail mess, thus doing a dump of thoughts here.

Ciaran McCreesh <ciaran.mccreesh@googlemail.com>:
> On Thu, 10 Dec 2009 21:48:48 +0100
> Christian Faulhammer <fauli@gentoo.org> wrote:
> > in commit 6a281c0bc6b951c0885c8787fa5c353a4f4e3d0d I disabled
> > kdebuild-1 by default.  My proposal now is to drop the KDEBUILD
> > conditionals as a whole as the overlay has gone anyway, where it was
> > used.  We can add a sentence in the introduction or wherever which
> > says something along the lines like "kdebuild-1 was the first EAPI
> > like format that supported extended features added to official EAPIs
> > later on and was heavily tested in the official Gentoo KDE overlay".
> > This would ease maintenance a bit.
> 
> As we've already discussed:
> 
> * Stop committing things that aren't typo fixes without posting them
> to this list for review.

 They are still administrative things reflecting a council decision and
setting the repo to official document generation by default.
 The whole "get rid of detailled kdebuild-1 description" has nothing to
do with denying that kdebuild-1 was one of the first steps towards
EAPI in Gentoo, but it eases the maintenance burden. LaTeX code is not
easier to read when a lot of conditionals are applied.  Put a warning
in Paludis when an kdebuild-1 is detected and I also support your news
item here.

> * Don't commit the EAPI 3 / 4 changes until the Council are done
>   changing things, and until we have a patch for the new definition of
>   EAPI 3. We don't have a definition for the new EAPI 3 yet. We also
>   don't have approved summaries of any of the meetings where these
>   things happened. Any changes done now are wasted effort.

 As I spoke with council members and people attending it before doing
the commits, I think I know about the intentions.  What Zac or anyone
else is doing is not to be intermixed with my actions as we acted
independently from each other.  So let's stick to one topic and I will
justify my commits now:

Disable kdebuild-1 by default: We had the discussion several times and
your only argument now is that there might be consumers of an
never-approved EAPI out there.
Update bash version: This reflects a council decision and two people
had input from you and others about the patch.  I discussed it with
Thomas Anderson on #-dev and we agreed on a wording which I committed.
3 to 4 move: Purely administrative and has been worked on by two people
(ulm and myself).
Cheat note: The commit comment is wrong and is not what I intended to
say in the blob itself.  So I will revert that piece of code as it was
a shoot from the hip and not thought through.

Anyway, yes, reviewing is necessary, but if essential changes from my
point of view are blocked or stonewalled through that means, I may
choose to take action.eas

> * Don't mess with kdebuild until you're sure that no-one has any
>   kdebuild packages installed.

 Don't be too academic.  To be sure is not possible.  And please don't
speak about bridge construction and failure possibilites when you don't
know about how an engineering process works.

> * When the heck did "use the highest EAPI" become policy?

 Maybe I mixed up some discussion in -dev with some policy agreement.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

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

Re: [gentoo-pms] kdebuild-1 conditionales

[Ciaran McCreesh]

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

On Wed, 16 Dec 2009 23:50:50 +0100
Christian Faulhammer <fauli@gentoo.org> wrote:
> > * Stop committing things that aren't typo fixes without posting them
> > to this list for review.
> 
>  They are still administrative things reflecting a council decision
> and setting the repo to official document generation by default.

So? If it's not a typo or trivial formatting fix, you send it out for
review. Administrative or not, you got it wrong, and you went ahead and
committed it even after I'd told you to wait until things had settled
down.

Admit that you screwed up, and make sure it doesn't happen again. Stop
trying to defend the indefensible.

> Disable kdebuild-1 by default: We had the discussion several times and
> your only argument now is that there might be consumers of an
> never-approved EAPI out there.

And, as per procedure, there was not consensus on it so you should not
have committed it.

> 3 to 4 move: Purely administrative and has been worked on by two
> people (ulm and myself).

Not purely administrative at all. For starters, you introduced a whole
load of todo notes into the main document, which we've deliberately not
been doing. Second, I'd already told you not to commit it until the
whole "what exactly is in EAPI 3" thing had been sorted out, which
still hasn't happened -- Portage and the Council are in disagreement,
and past experience strongly suggests that it isn't necessarily the
Council that's going to come out on top here...

> Anyway, yes, reviewing is necessary, but if essential changes from my
> point of view are blocked or stonewalled through that means, I may
> choose to take action.eas

Your point of view isn't relevant when it's wrong. You're supposed to
be working with other people here, not committing first and then
tidying up the mess later.

> > * Don't mess with kdebuild until you're sure that no-one has any
> >   kdebuild packages installed.
> 
>  Don't be too academic.  To be sure is not possible.  And please don't
> speak about bridge construction and failure possibilites when you
> don't know about how an engineering process works.

You could have achieved a high degree of confidence with very little
difficulty. Instead, this whole mess is spilling over and affecting
users, and wasting far too much of a lot of people's time for something
that should have been done without any mess or user impact.

-- 
Ciaran McCreesh

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