2010-09-24 - AutoQA depcheck meeting recap

James Laska jlaska at redhat.com
Fri Sep 24 16:15:40 UTC 2010


# AutoQA 'Depcheck'-in
# Date: 2010-09-24
# Time: 14:00 UTC (10:00 EDT, 16:00 CEST)
# Attendees: jlaska, jskladan, kparal, mkrizek, wwoods

Depcheck - 'next steps' -
https://fedorahosted.org/pipermail/autoqa-devel/2010-August/001010.html 

= Agenda =

1) Review current state of depcheck
  * autoqa/tests/depcheck/depcheck available
    > inputs:
      + a list of local packages, 
      + name of a repo you want to move these packages to
    > outputs:
      + list of the packages that could be successfully added to the
requested repo
  * autoqa/tests/depcheck/depcheck unittests
    > TODO - a few remaining unittests (fileconflicts?)
  * mash script to create proper multilib setup available
  * post-bodhi-update working now to submit upgradepath tests

2) Next steps

 * ticket#201 Add mash support to depcheck
   > next - integrate mash script into depcheck test
 * ticket#202 testcases for depcheck
   > next - close out (remaining conflicts test will be part of a new
ticket)
 * ticket#204 add depcheck to post-bodhi-update hook
   > includes autoqa integration (control and control.autoqa files
etc...)
   > next - not too difficult to enable, this is likely the last ticket
 * ticket#205 make depcheck submit karma/comments to bodhi
   > will monitor depcheck results to determine correctness
   > next - ideal solution, submit 1 karma for N tests
   > next - if unable to determine karma submission for multiple tests,
will consider karma for depcheck
 * Revise post-bodhi-update watcher to use new -pending koji tags (more
robust than current watcher implementation)
   > not a must have for current milestone, but will be an issue in the
future
 * new rpmguard test - updates don't drop architecture
   > FIXME - unclear how to proceed
 * documentation - Purpose, Basic depcheck use cases
    > For example, see
https://fedoraproject.org/wiki/Updates_Lessons#2010-05-27_-_nss-softokn_update_problems
    > document the purpose for each of the unittests

= Questions =

Q. Can depcheck test be run stand-alone?
A. Yeah, it's possible to run ./depcheck stand-alone

Q. When should we enable depcheck enforcing?
A. Ideally, after resultsdb is completed and all package update tests
are reporting into resultsdb.  However, as a fallback, if timing becomes
an issue we will consider enabling karma submission for just depcheck

Q. What's the future of Conflicts and Reposanity tests in PUATP as
Mandatory tests?
A. Reposanity will be replaced by Depcheck and Conflicts will be
replaced by a new 'fileconflicts' test.

Q. What happens if a new update request comes in after depcheck has been
scheduled?
A. New updates will be tested when the watcher fires next.

= Action items =

      * [kparal] - Documentation - Merge/create
        https://fedoraproject.org/wiki/QA:Depcheck_Test_Case
      * [wwoods] - Documentation - make sure there's some documentation
        what depcheck is good for and how to use it generally (bullets
        with stuff that depcheck exactly checks) README
      * [future] - Add a new fileconflicts test that operates over a
        list of packages, and a desired repo
      * [wwoods] - ticket#201 - integrate jskladan's mash script into
        depcheck
      * [jlaska] - Move ticket#205 - move into "Package Update
        Acceptance Test Plan"
      * [jlaska] - Create ticket - revised post-bodhi-update that uses
        -pending koji tags instead
      * [jskladan] - summarize current state of resultsdb
      * [jskladan] - review resultdb roadmap and submitting karma for
        PUATP
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : https://fedorahosted.org/pipermail/autoqa-devel/attachments/20100924/cbc7fe98/attachment.bin 


More information about the autoqa-devel mailing list