[Fedora QA] #227: Document SOP for acceptance test event

[Fedora QA]

#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