Re: [gentoo-dev] 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+QCfdw7ler6i8xGPufZnNsQjNV9m bBYAoKLKekHRe6SShSNcU7jHIEZiYrCw =9y3A -END PGP SIGNATURE-
Re: [gentoo-dev] QA Documentation
On Mon, Dec 28, 2009 at 3:43 AM, Richard Freeman ri...@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
Re: [gentoo-dev] 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.
[gentoo-dev] 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.
