FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 12-28-2009, 01:43 AM
Richard Freeman
 
Default QA Documentation

Started new subject since this is only tangentially related to the election.

On 12/27/2009 06:16 PM, Tomáš Chvátal wrote:

Anyway, i wont write huge manifesto but these things i would like spent
my time:

QA propagation (motivating people, explaining why we are doing stuff and
so on)



Could this include documenting QA policies a bit better? Some are
documented in scattered docs, some are in the ebuild quiz answers (which
of course no two developers have the exact same answers to, and they
aren't anywhere you can point to for reference), and many are learned
when QA files a bug on a package one maintains.


It would be really nice to just have a list somewhere that we could
periodically look at and refresh our memories against. Plus, some
policies aren't always obvious or can be misinterpreted.


Don't get me wrong - the QA team is doing a great job and I love Diego's
work on the tinderbox. I've had a bug or two filed by them, and I've
found that they've only been helpful when somebody actually bothers to
try to resolve them.
 
Old 12-28-2009, 10:23 AM
Tomáš Chvátal
 
Default QA Documentation

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

Dne 28.12.2009 03:43, Richard Freeman napsal(a):
>
> Could this include documenting QA policies a bit better? Some are
> documented in scattered docs, some are in the ebuild quiz answers (which
> of course no two developers have the exact same answers to, and they
> aren't anywhere you can point to for reference), and many are learned
> when QA files a bug on a package one maintains.
>
> It would be really nice to just have a list somewhere that we could
> periodically look at and refresh our memories against. Plus, some
> policies aren't always obvious or can be misinterpreted.
>
> Don't get me wrong - the QA team is doing a great job and I love Diego's
> work on the tinderbox. I've had a bug or two filed by them, and I've
> found that they've only been helpful when somebody actually bothers to
> try to resolve them.
>

Yeah that is the weak point. We need to write for each policy what it
does and why we enforce it (probably also common approach to fix). And
we should ENFORCE it, not just fill bugs about it, because mostly people
tend to ignore that things.

Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAks4lT4ACgkQHB6c3gNBRYfS+QCfdw7ler6i8x GPufZnNsQjNV9m
bBYAoKLKekHRe6SShSNcU7jHIEZiYrCw
=9y3A
-----END PGP SIGNATURE-----
 
Old 12-28-2009, 10:38 AM
Fabio Erculiani
 
Default QA Documentation

On Mon, Dec 28, 2009 at 3:43 AM, Richard Freeman <rich0@gentoo.org> wrote:
> [..]
>
> Don't get me wrong - the QA team is doing a great job and I love Diego's
> work on the tinderbox. *I've had a bug or two filed by them, and I've found
> that they've only been helpful when somebody actually bothers to try to
> resolve them.
>
>

Just to let you all know,
we have two build servers since 2007 in where we compile Portage ~arch
(x86, amd64) and produce binary packages through Entropy for Sabayon
(http://sabayon.org/packages). In 2010 we plan, with some students
from the University of Milano-Bicocca to add some static analysis bits
into the workflow. Maybe, there are some commonalities between the two
ideas (tinderbox vs what Sabayon is doing already).

--
Fabio Erculiani
http://www.sabayon.org
http://www.gentoo.org
 
Old 12-28-2009, 01:46 PM
Richard Freeman
 
Default QA Documentation

On 12/28/2009 06:23 AM, Tomáš Chvátal wrote:

we should ENFORCE it, not just fill bugs about it, because mostly people
tend to ignore that things.



Agreed, although some presumption of innocence should be assumed. If a
dev is ignoring repoman output that is a fairly big violation, but if a
dev missed that compiling under some strange set of circumstances or
combination of use flags causes a problem, well, that's a bug that needs
to be fixed. There were some --as-needed issues detected by the
tinderbox that only show up when you use a modified gcc profile, for
example. That doesn't mean they're not worth fixing, but we shouldn't
punish people for that stuff.


I don't think the QA team has an issue with mistakes (not that I can
really speak for them) - their main frustration is probably when bugs
get filed and then get ignored. Expecting people to resolve bugs in a
week for minor issues is probably asking a bit much, but if a dev has 14
packages with 25 open bugs each that are six months old that is probably
a cause for concern that should be escalated to devrel.


On the other hand, some allowance for brain-dead upstream tactics should
be made. I'd consider embedded libraries a QA issue, but if we made
that a stern policy we'd never see chromium in the tree for quite a long
time. I'm sure the guys maintaining that would love to try to patch out
as much of the embedded stuff as they can, but they've got a LOT of work
to do due to the way it was written. I'm not sure that simply banning
chromium from the tree is the right approach either as long as upstream
deals with the inevitable security issues when they come up.
 

Thread Tools




All times are GMT. The time now is 09:29 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org