[Fedora QA] #141: proventester for pcfe?

[Fedora QA]

#141: proventester for pcfe?
------------------------------------------+---------------------------------
  Reporter:  pcfe                         |       Owner:  jlaska
      Type:  proventester request         |      Status:  closed
  Priority:  major                        |   Milestone:        
 Component:  Proventester Mentor Request  |     Version:        
Resolution:  fixed                        |    Keywords:        
------------------------------------------+---------------------------------
Changes (by jlaska):

  * status:  assigned => closed
  * resolution:  => fixed

Comment:

 Replying to [comment:2 pcfe]:
 > Hi James,
 >
 > Replying to [comment:1 jlaska]:
 > [...]
 > > Once you have read the instructions, please confirm that you ...
 >
 > Yupp, read them before requesting the proventester flag and figured most
 of it applies to what I do anyway ;-)

 Indeed, thanks!

 > >  1. have read and understand the instructions, and intend to follow
 the instructions when testing Fedora critical path updates
 >
 > Not to the letter, my testmachines sit in a disconnected segment of the
 lab here. Their software source is an internal server that mirrors it's
 Fedora trees from funet (I get well over 10MB/s from that mirror, viva
 Finland's modern infrastructure) once a day. So in general I lag by a day
 or two. On single packages I can pull manually, but most of my testing
 will have the 2 day lag until I have the packages. Is that OK?

 I don't have issue with that.  Most of the more popular, well
 known+understood packages receive test feedback fairly quick.  I could see
 you (and your test setup) providing feedback on perhaps more involved or
 less high-profile packages/subsystems.

 > Secondly, 'you should perform a full system update from this repository
 at least once a day.' does not apply to my situation, all my test machines
 get frequently re-installed (while I have a few tens of test boxes at my
 disposal, I have many more test cases than machines, so all my tests are
 kickstart based. Meaning, if a package needs testing, I'll happily
 kickstart the Fedora version required and hoover in updates-testing from
 the local mirror, but said test machine may be running a completely
 different distro later in the day and is almost guaranteed to have been
 re-installed after a couple days). Again, if this does not fit the
 proventester requirement, no hard feelings if you turn my application
 down. The aim is to help Fedora and RHEL, not to brag about the
 proventester flag ;-)

 The use case described above does not conflict with the test procedures
 for proventesters.  One reason for suggesting an update is so that
 proventesters can identify and report conflicts and dependency failures
 reported during upgrade.  I believe those errors will be reported when
 installing while including ''updates'' and ''updates-testing'' as well, so
 there shouldn't be any issues.

 > >  2. understand how to enable the update-testing repository
 >
 > yeah, my kickstart files drop in repofiles in %post, dropping one with
 updates-testing enabled is no issue.
 >
 > >  3. are familiar with providing test feedback using either the Bodhi
 web interface, or the fedora-easy-karma utility
 >
 > Yeah, I used Bodhi in the past when feedback was requested in a BZ.
 Can't use the easy-karma tool from the lab (the test boxes can only
 connect to the install server to hoover ks and RPMs from there)

 Using only the bodhi webui is still a valid option.  With the new bodhi
 release, there are feeds available for critpath updates in updates-
 testing.  Take a look at
 https://admin.fedoraproject.org/updates/critpath?untested=True for
 details.  You may find that handy for staying on top of testing requests,
 and identifying updates where you might have more experience in providing
 meaningful feedback.


 In the meantime, I have added you to the ''proventesters'' FAS group.  Go
 forth and happy testing! :)

-- 
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/141#comment:3>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance