[gentoo-dev] 'stricter' FEATURE and "poor programming practices" notice

[gentoo-dev] 'stricter' FEATURE and "poor programming practices" notice

[Hans de Graaff]

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

Hi,

I've had the 'stricter' FEATURE turned on for some time and found that
many packages failed due to the QA notice regarding poor programming
practices. I filed a few bugs for this but have not gotten a lot of
response, or the suggestion to talk to upstream. Obviously the latter is
always a good option, but I'm wondering what the intend behind this QA
notice is.

My view is that if this is a QA notice then, if a package doesn't emerge
because of it, it is a Gentoo QA bug and package maintainers should be
responsible for fixing it. 

If the notice is only informational, then the emerge process should not
be stopped because of it (and this would mean that it is nice to fix
these issues but not mandatory).

Kind regards,

Hans

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

Re: [gentoo-dev] 'stricter' FEATURE and "poor programming practices" notice

[Ciaran McCreesh]

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

On Thu, 17 May 2007 13:12:01 +0200
Hans de Graaff <graaff@gentoo.org> wrote:
> My view is that if this is a QA notice then, if a package doesn't
> emerge because of it, it is a Gentoo QA bug and package maintainers
> should be responsible for fixing it. 

Gentoo should not be applying patches simply to fix what certain people
consider to be 'poor programming practises', since such practices are
not in themselves bugs. Under certain circumstances it's appropriate to
notify upstream about such issues, but be aware that upstream may not
take kindly to external attempts to impose arbitrary coding standards
if there is no actual problem.

In cases where those QA checks reveal a genuine bug, upstream should of
course be notified and the bug should be fixed. When notifying
upstream, avoid terms like 'poor programming' and stick to explaining
the actual bug.

-- 
Ciaran McCreesh


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

[gentoo-dev] Re: 'stricter' FEATURE and "poor programming practices" notice

[Ryan Hill]

Ciaran McCreesh wrote:
> Hans de Graaff <graaff@gentoo.org> wrote:

>> My view is that if this is a QA notice then, if a package doesn't
>> emerge because of it, it is a Gentoo QA bug and package maintainers
>> should be responsible for fixing it. 

> Gentoo should not be applying patches simply to fix what certain people
> consider to be 'poor programming practises', since such practices are
> not in themselves bugs. Under certain circumstances it's appropriate to
> notify upstream about such issues, but be aware that upstream may not
> take kindly to external attempts to impose arbitrary coding standards
> if there is no actual problem.

Especially considering the large number of false positives certain -W
options generate.  Compiler warnings should be for upstream and
developers doing debugging to worry about, not downstream QA or our users.


-- 
                                where to now? if i had to guess
dirtyepic gentoo org        i'm afraid to say antarctica's next
9B81 6C9F E791 83BB 3AB3  5B2D E625 A073 8379 37E8 (0x837937E8)

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 'stricter' FEATURE and "poor programming practices" notice

[Zac Medico]

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

Hans de Graaff wrote:
> If the notice is only informational, then the emerge process should not
> be stopped because of it (and this would mean that it is nice to fix
> these issues but not mandatory).

If you disable stricter in FEATURES, you'll still get the same
informational message, but the install will continue.  The messages
will be logged if you add qa to PORTAGE_ELOG_CLASSES (see
make.conf.example).  If you only want to exempt specific packages
from the stricter behavior, you can put something like this in
/etc/portage/bashrc:

[ "${CATEGORY}/${PN}" == "app-foo/bar" ] && \
	export FEATURES=${FEATURES/stricter/}

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (GNU/Linux)

iD8DBQFGTLH9/ejvha5XGaMRAu/OAJ9AiTgbY6elQrYxlymy1TL1cLzc+wCgw12T
9uxK1MTeBOqmPtZBwyqOVms=
=ax5j
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 'stricter' FEATURE and "poor programming practices" notice

[Kevin F. Quinn]

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

On Thu, 17 May 2007 13:12:01 +0200
Hans de Graaff <graaff@gentoo.org> wrote:

> I've had the 'stricter' FEATURE turned on for some time and found that
> many packages failed due to the QA notice regarding poor programming
> practices. I filed a few bugs for this but have not gotten a lot of
> response, or the suggestion to talk to upstream. Obviously the latter
> is always a good option, but I'm wondering what the intend behind
> this QA notice is.
> 
> My view is that if this is a QA notice then, if a package doesn't
> emerge because of it, it is a Gentoo QA bug and package maintainers
> should be responsible for fixing it. 
> 
> If the notice is only informational, then the emerge process should
> not be stopped because of it (and this would mean that it is nice to
> fix these issues but not mandatory).

Yeah; it's a bit of a pain, especially if you have '-Wall' in CFLAGS
(a large proportion of packages fail if you do).

I've ended up removing stricter from FEATURES, which is far from ideal
as it means all the other checks are no longer fatal, some of which I
really want to know about at emerge time (well, to be honest, I've
ended up patching portage locally to make the "bad code" thing
non-fatal).

In a broader scope, we could do with a "QA check control" file or
something to provide finer-grained control of these QA checks.  However
the QA checks themselves seem to be a bit ad-hoc at the moment.

-- 
Kevin F. Quinn

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