Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc <jakub@gentoo.org>]

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


28.2.2006, 15:39:40, Ciaran McCreesh wrote:

> On Tue, 28 Feb 2006 10:49:13 +0100 Jakub Moc <jakub@gentoo.org> wrote:
> | No, that's not a policy document, ebuild policy is documented here:
> |
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printable&part=3&chap=1

> No, the whole thing is policy.

No, it isn't. And silently sticking parts of unofficial gentoo devmanual
into official Gentoo docs, and then silently turning them into a "policy"
enforced under QA disguise is a bad very practice, and pretending that this
has been in the mentioned _howto_ (not policy) for a long time as just plain
silly. Since you haven't answered the question in one of my previous emails
at all, let me ask again:

When and where has been the following change discussed and who approved
that?

http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?r1=1.25&r2=1.26&root=gentoo


> | Moreover, the cited howto is wrong, since it will break built_with_use
> | checks

> No, that's a separate issue.

No, it isn't. If you want something to have as a policy, it needs to be
error-free, reasonably applicable and not doing more harm than if it isn't
applied at all. And implementing such stuff requires a proper discussion,
considering the consequences and some sort of consent among affected
developers. (Also, that howto example is less than fortunate/clear,
like some user noted in Bug 124401).

> | The howto also doesn't apply to cases like
> | recode vs. mysql, because that's a completely different
> | functionality, you can't exactly choose which one is better on behalf
> | of the user.

> No, it does apply.

No, it doesn't, you can't reasonably favour one of two completely different
functionalities based on some automagic assumption/developer discretion.
That doesn't benefit users in any way and just produces unexpected results
(hey, I explicitely enabled "recode" use flag and php compiled without, the
ebuild is broken, fix0r it!)

> | So, to sum it up - you can't make up for portage's lack of features by
> | inventing a policy that doesn't work. Once again - until portage can
> | handle USE-based dependencies and until portage can handle
> | conflicting use flags, there's nothing that could be done here.

> Until Portage can handle conflicting USE flags, one should take the
> policy-mandated solution that has been sufficient for everyone else for
> four years or more. Sure, it's not perfect, but it's a hell of a lot
> better than repeatedly exploding in the user's face midway through an
> install.

No, noone should enforce a policy that

- doesn't exist (see above)
- hasn't been discussed properly and approved (see above)
- it's consequences haven't been considered wrt whether its benefits
overweight the negatives and whether is useful at all.


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

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