#227: Document SOP for acceptance test event
--------------------+-------------------------------------------------------
Reporter: rhe | Owner: wutao85
Type: task | Status: new
Priority: major | Milestone: Fedora 16
Component: Wiki | Version:
Resolution: | Keywords:
--------------------+-------------------------------------------------------
Comment (by adamwill):
so, to enlarge, my concern is that by limiting the time scale and
frequency of RATs runs while simultaneously enlarging the scope, we've
made them almost indistinguishable in practical terms from TCs. I'd
propose we re-balance things a bit:
we could be doing the fully automated RATs stuff *daily*, right? Every
time there's a Rawhide compose? Is there anything preventing this?
Couldn't it just be part of AutoQA that fires, posts a result, and
everyone's happy?
we could then strictly define TC and RC: a TC is a published compose of
whatever subset of images we decide on, which happens before a freeze so
has no chance of being blessed as the release. An RC is the same thing,
but after a freeze, so it may be blessed as the release. We then re-align
the TC periods for each phase a little earlier, since we've noticed when
we slip, it tends to be because we were late getting workable TCs.
effectively, we turn the early RATs runs into TCs. We'd wind up with maybe
3-4 TCs per release, the first one or two of which may hit bugs very early
in testing.
thoughts?
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/227#comment:15>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
