On Fri, 28 Aug 2009 10:53:25 -0400, James wrote:
Have you been in touch with Will directly on these points?
No. Is all of this talked about only in private mail or behind other curtains? IRC/hallways/meetings only? No public mailing-list? I used to be a subscriber of fedora-qa-list but it has been shut down very early. Recent documents point to fedora-test-list instead.
Hmm, no ... discussion on autoqa has been very public. Come join an upcoming QA meeting (https://fedoraproject.org/wiki/QA/Meetings) if you'd like to take
[IRC] meetings without prior communication often are a waste of time.
https://fedoraproject.org/wiki/QA explicitly points at this list, so that's what I used for my comments.
There are currently repoclosure and conflicts tests running against rawhide (and release repo's). Do these capture the obsoletes issue you hilight?
What I see on https://fedorahosted.org/pipermail/autoqa-results/2009-August/date.html in the "repoclosure" reports is many false positives. Stock repoclosure from yum-utils does not implement anything that evaluates Obsoletes tags.
The "conflicts" reports look much more promising. At least I recognise several of the conflicts. I think I will compare some of them with the output of my old i386 script, http://mschwendt.fedorapeople.org/confcheck-remote-split2.py or take a look at the source code to find out whether we can focus on one implementation.
Sometimes packagers create conflicts deliberately (by pushing a partial set of upgrades) and are annoyed if they receive [semi-]automated bug reports in bugzilla. Several of the found issues have been reported in bugzilla a long time ago. Just finding the conflicts is mostly fruitless as long as packagers need not fix them.
What might you implement in order to capture the obsoletes issue?