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

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

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

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

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

[gentoo-council] 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-council] Re: [gentoo-pms] kdebuild-1 conditionales

[Mike Frysinger]

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

On Friday 11 December 2009 12:43:39 Ciaran McCreesh wrote:
> On Fri, 11 Dec 2009 18:34:09 +0100 Ulrich Mueller 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.

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.

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

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

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

[Petteri Räty]

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

On 12/11/2009 08:14 PM, Ulrich Mueller wrote:
> 
>> * 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.
> 

There's been threads on gentoo-dev that it will become hard for
developers to know the differences between all EAPIs when the number of
EAPIs increases. In order to help day to day development it's easiest
usually use the latest EAPI but I don't think we have a written down
policy in our documentation on what EAPI to use. If this is an issue, we
can put it on the agenda for the next council meeting.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 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

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 13-12-2009 18:30, Ciaran McCreesh wrote:
> On Sat, 12 Dec 2009 22:45:48 -0500
> Mike Frysinger <vapier@gentoo.org> wrote:
>> 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,

as you know the only people that used kdebuild-1 were the ones using the
KDE overlay to track live ebuilds. Even though Wulf has recently showed
that some people are still trying to sync from his box (even though the
git repo was removed more than 2 weeks ago), the vast majority has
either switched to one of the methods currently supported by the KDE
team or has decided to move to exheres (and thus exherbo). In any case,
it was used in an overlay, following an unapproved spec that was only
supported by a single PM - which is not the official Gentoo PM.
It's surprising that people wanting to follow live ebuilds are still
trying to sync from a repo that stopped actively following upstream
quite some time ago - long before the repo was deleted. It would be
useful to have an idea of many users we're talking about, but given the
former, I have a hard time believing the number of users is large.


- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkslS40ACgkQcAWygvVEyAIqmwCfRCKoSX+5moJ8JvvgniGqDWOt
LFkAmwbSwxN0B9QD4z7j1GMOvnG4yt0+
=dU+V
-----END PGP SIGNATURE-----

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

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 13 Dec 2009 19:16:14 -0100
"Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org> wrote:
> as you know the only people that used kdebuild-1 were the ones using
> the KDE overlay to track live ebuilds. Even though Wulf has recently
> showed that some people are still trying to sync from his box (even
> though the git repo was removed more than 2 weeks ago), the vast
> majority has either switched to one of the methods currently
> supported by the KDE team or has decided to move to exheres (and thus
> exherbo). In any case, it was used in an overlay, following an
> unapproved spec that was only supported by a single PM - which is not
> the official Gentoo PM. It's surprising that people wanting to follow
> live ebuilds are still trying to sync from a repo that stopped
> actively following upstream quite some time ago - long before the
> repo was deleted. It would be useful to have an idea of many users
> we're talking about, but given the former, I have a hard time
> believing the number of users is large.

We know that the number of users with things installed is not zero. We
also know that by following a simple migration path, that number can
become zero in a way that doesn't result in any nasty surprises for
anyone. That's all that the Council is being asked to agree on here --
that rather than nuking things without warning, we should warn affected
users that they need to take action, and give them a reasonable about
of time to do so before we go around deleting anything.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkslTKUACgkQ96zL6DUtXhFUvQCfTnPxSBE4VlyModvGk/PcHU7o
iHAAnAgfmtLzPbFPncQ1DI2SCsntZ4ZI
=q/A4
-----END PGP SIGNATURE-----

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

[Mike Frysinger]

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

On Sunday 13 December 2009 14:30:44 Ciaran McCreesh wrote:
> On Sat, 12 Dec 2009 22:45:48 -0500 Mike Frysinger 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.

i'm talking about when this crap was added originally, not any recent 
conversations

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

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 ... it is after all your own 
fault.  nothing you said here is relevant to PMS in any way.

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, 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 doesnt 
belong there, it never has, so delete it/branch it already.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 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

[Mike Frysinger]

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

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

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 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

[Ned Ludd]

On Fri, 2009-12-11 at 17:18 +0000, Ciaran McCreesh wrote:
> 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)."


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.

If you continue to mail bomb the council list, it will be considered
abuse.

-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

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

[Nirbheek Chauhan]

On Tue, Dec 15, 2009 at 12:30 AM, Ned Ludd <solar@gentoo.org> wrote:
> On Fri, 2009-12-11 at 17:18 +0000, Ciaran McCreesh wrote:
>> 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)."
>
>
> 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.
>
> If you continue to mail bomb the council list, it will be considered
> abuse.
>

Thank you so much for this mail. I would have been very disappointed
if this discussion had continued wasting everyone's time, bandwidth
and inbox space. From where I'm sitting, Ciaran's tirades have been a
complete waste from every angle. I know I represent the feelings of
the entire Gentoo community when I say this.

I hope he takes a hint from this email, but somehow I know he won't.


Regards,

~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

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

[David Leverton]

On Monday 14 December 2009 19:15:19 Nirbheek Chauhan wrote:
> From where I'm sitting, Ciaran's tirades have been a
> complete waste from every angle. I know I represent the feelings of
> the entire Gentoo community when I say this.

You most certainly do not.  But of course you already knew that, you're just 
trolling as usual.

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-council] Re: [gentoo-pms] kdebuild-1 conditionales

[Mike Frysinger]

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

On Monday 14 December 2009 13:21:29 Ciaran McCreesh wrote:
> On Mon, 14 Dec 2009 12:01:03 -0500 Mike Frysinger wrote:
> > > 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.

that is purely your own decision.  having it in PMS has 0 bearing on it.  
kdebuild behavior isnt going to magically change semantics with 
pkg_{pre,post}rm and if it does, it isnt going to because someone changes it 
behind your back.  i'm sure you're more than capable of watching the changes 
going into 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.
> 
> I highly doubt that, since if that were the case we'd be receiving
> reports from users about it.

i guess i'm not a user and my multislot bug doesnt exist.  and my 
CBUILD/CTARGET reports were discarded.  prepstrip i dont think i bothered 
pushing because of your insistence on ignoring prep* functions.  having broken 
PM (where PM != portage) behavior is what you get then; no sweat off my back.

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

funny how you use a logic statement in defense of your PM, but then at the 
same exact time use it to block other PMs.  how you manage this constant 
circular logic is beyond me.

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

i dont recall anyone going over a replacement for prepstrip.  the toolchain 
packages have been using this interface for quite a while and rely on it 
working correctly.  current git master doesnt seem to mention anything wrt 
stripping behavior.

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

i never said the code/design was clean.  i did however say that we have 
defacto spec that people are relying on and it isnt in PMS and you block it, 
yet specs that was explicitly never approved and never in the tree you had no 
problem adding.

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

i told you about it in the very first draft review of PMS and you told me it 
had no business in the PMS and it was a portage-specific feature.  i had to 
bitch and moan to even get mentioned as reserved so it wouldnt be arbitrarily 
hijacked by stupid people.

here's the notes from my initial review i gave you oh-so-long ago and you 
responded on irc at the time (no, i dont have irc logs because i dont log 
anything):
http://dev.gentoo.org/~vapier/PMS-notes

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

not much point when you have no justification for why it needs to be kept
-mike

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

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

[Mike Frysinger]

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

On Monday 14 December 2009 14:24:05 Ciaran McCreesh wrote:
> 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.

thank you
-mike

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