QA/Meetings/20080507

From FedoraProject

Jump to: navigation, search
-!- wwoods changed the topic of #fedora-meeting to: Fedora QA Meeting | init<a href="#t11:02" class="time">11:02</a>
wwoodsqa meeting time!<a href="#t11:03" class="time">11:03</a>
* jds2001 <a href="#t11:03" class="time">11:03</a>
f13blaaaat<a href="#t11:04" class="time">11:04</a>
wwoodsf13, mether, viking-ice_, comphappy, notting, DemonJester: ping<a href="#t11:04" class="time">11:04</a>
* viking-ice_ pong on laptop<a href="#t11:05" class="time">11:05</a>
* viking-ice pong.. on workstation<a href="#t11:05" class="time">11:05</a>
wwoodsa random note. sometime after F9 is out I'm gonna actually go through with my mumblings about having a proper QA board and FAS group<a href="#t11:05" class="time">11:05</a>
wwoodsI mention it because.. it'll make the roll call easier<a href="#t11:05" class="time">11:05</a>
wwoodsheh<a href="#t11:05" class="time">11:05</a>
* viking-ice second that..<a href="#t11:05" class="time">11:05</a>
jds2001lol<a href="#t11:05" class="time">11:05</a>
wwoodsjds2001, poelcat: ping<a href="#t11:06" class="time">11:06</a>
wwoodssee? I forget people.<a href="#t11:06" class="time">11:06</a>
wwoodsmy apologies for that.<a href="#t11:06" class="time">11:06</a>
* poelcat here<a href="#t11:06" class="time">11:06</a>
poelcatjlaska: ping<a href="#t11:06" class="time">11:06</a>
* jds2001 is easily forgettable :)<a href="#t11:06" class="time">11:06</a>
wwoodsI think he has a scheduling conflict with this meeting<a href="#t11:07" class="time">11:07</a>
wwoodsbut sometimes lurks<a href="#t11:07" class="time">11:07</a>
wwoodsI need to bug him about doing some pseries testing<a href="#t11:07" class="time">11:07</a>
wwoodsanyway:<a href="#t11:07" class="time">11:07</a>
rdieterjds2001: all the best ninjas are. :)<a href="#t11:07" class="time">11:07</a>
* jlaska lurks<a href="#t11:08" class="time">11:08</a>
-!- wwoods changed the topic of #fedora-meeting to: Fedora QA Meeting | F9 RC1 and test status: <a href="http://fedoraproject.org/wiki/QA/TestResults/Fedora9Install/FinalRelease">http://fedoraproject.org/wiki/QA/TestResults/Fedora9Install/FinalRelease</a><a href="#t11:08" class="time">11:08</a>
jlaskafighting some 5.2 issues right now ... but present<a href="#t11:08" class="time">11:08</a>
wwoodsso! unless I've confused myself, today's rawhide is the offically official RC1 (f13, confirm?)<a href="#t11:08" class="time">11:08</a>
* jds2001 just finished rsync'ing it.<a href="#t11:08" class="time">11:08</a>
f13wwoods: sadly there are 2 packages that are going to be bumped, due to file corruption on the koji store<a href="#t11:09" class="time">11:09</a>
poelcatjds2001: tell me if it installs... i've got a mismatch somewhere<a href="#t11:09" class="time">11:09</a>
wwoodsf13: ooh. ouch.<a href="#t11:09" class="time">11:09</a>
f13however those are fringe packages, and it's only one ppc rpm and one ppc-debuginfo rpm<a href="#t11:09" class="time">11:09</a>
wwoodsah yes. yeah, low-impact. so we're just dropping 'em from the repos, or rebuilding?<a href="#t11:09" class="time">11:09</a>
f13rebuilding<a href="#t11:10" class="time">11:10</a>
f13unfortunately one is a 3 hour rebuild.<a href="#t11:10" class="time">11:10</a>
wwoodsgross.<a href="#t11:10" class="time">11:10</a>
f13very<a href="#t11:10" class="time">11:10</a>
wwoodswell, the impact on the required testing for final is basically 0<a href="#t11:10" class="time">11:10</a>
wwoodsbut one of us with ppc machines should be sure to check it tomorrow<a href="#t11:11" class="time">11:11</a>
wwoodsthe installation test results are going nicely<a href="#t11:11" class="time">11:11</a>
f13yeah, getting lots of results, I'm very happy<a href="#t11:11" class="time">11:11</a>
f13just need to verify some stuff like the hd iso and nfs iso and the other bugs that anaconda supposedly fixed like ftp password<a href="#t11:11" class="time">11:11</a>
wwoodsI want to thank everyone for their help, especially comphappy and DemonJester<a href="#t11:11" class="time">11:11</a>
f13I'm still putting the final touches on the tree, like the jigdo files, gpg signing, etc...<a href="#t11:12" class="time">11:12</a>
wwoodsright, I was going to ask - we needed to invalidate the hdiso/nfsiso results because of the new anaconda build<a href="#t11:12" class="time">11:12</a>
f13I've been able to concentrate more on that then on the tree testing, which is a good thing.<a href="#t11:12" class="time">11:12</a>
wwoodsI take that to mean you haven't retested?<a href="#t11:12" class="time">11:12</a>
DemonJesteryou are welcome! glad to help where I can ;)<a href="#t11:12" class="time">11:12</a>
f13wwoods: not with today's compose<a href="#t11:12" class="time">11:12</a>
* jds2001 can test nfsiso soon.<a href="#t11:12" class="time">11:12</a>
wwoodsDemonJester: it is very much appreciated!<a href="#t11:12" class="time">11:12</a>
f13we're also pretty well pre-synced to PHX for the Fedora/Everything stuff<a href="#t11:13" class="time">11:13</a>
wwoodslike f13 says, it frees us up to do further testing and release prep stuff<a href="#t11:13" class="time">11:13</a>
f13Live images will go later, and those I need to do a bunch of testing on.  Hopefully today is live testing day<a href="#t11:13" class="time">11:13</a>
f13jeremy: ping?<a href="#t11:13" class="time">11:13</a>
wwoodswith your help I can honestly say this has been one of the least stressful final release cycles I've ever been involved with<a href="#t11:13" class="time">11:13</a>
wwoods(not to say it's been all milk and honey, but still, much easier than any previous one)<a href="#t11:13" class="time">11:13</a>
wwoodsyeah, live testing would be excellent. I don't think we have a specific test plan for that<a href="#t11:14" class="time">11:14</a>
-!- wwoods changed the topic of #fedora-meeting to: Fedora QA Meeting | Live testing<a href="#t11:14" class="time">11:14</a>
wwoodssince we don't have a specific test plan we fall back to the ReleaseCriteria: <a href="http://fedoraproject.org/wiki/QA/ReleaseCriteria">http://fedoraproject.org/wiki/QA/ReleaseCriteria</a><a href="#t11:14" class="time">11:14</a>
jlaskawwoods: so a rawhide compose is being re-purposed as an RC<a href="#t11:14" class="time">11:14</a>
jlaska?<a href="#t11:14" class="time">11:14</a>
wwoodsjlaska: re-purposed?<a href="#t11:15" class="time">11:15</a>
wwoodsthere's no difference in content between today's rawhide<a href="#t11:15" class="time">11:15</a>
wwoodsand anything we'd build as an RC right now<a href="#t11:15" class="time">11:15</a>
wwoodstherefore: today's rawhide can be considered RC1<a href="#t11:15" class="time">11:15</a>
jlaskain terms of included packaging as appropriately tagged in koji ... you are correct<a href="#t11:15" class="time">11:15</a>
f13yeah, the only package changes I'm expecting live outside the Fedora spin.<a href="#t11:16" class="time">11:16</a>
jlaskathis may be my unfamiliarity with the process ... but my naive thought would be a rawhide compose wouldn't produce the same signed results as a official RC comopse<a href="#t11:16" class="time">11:16</a>
jlaskaf13: is that not the case for Fedora?<a href="#t11:16" class="time">11:16</a>
wwoodsjlaska: why would it?<a href="#t11:16" class="time">11:16</a>
f13jlaska: not the case.  rawhide has signed packages in it<a href="#t11:17" class="time">11:17</a>
f13the only difference is a re-run of the compose tools<a href="#t11:17" class="time">11:17</a>
jlaskaso the RC .treeinfo will say "version = development" ?<a href="#t11:17" class="time">11:17</a>
wwoodsah, signatures. yeah, in this case we have had signed packages in rawhide for a couple weeks now<a href="#t11:17" class="time">11:17</a>
f13which is getting some validation.<a href="#t11:17" class="time">11:17</a>
* f13 thinks we're all talking past eachother<a href="#t11:17" class="time">11:17</a>
f13my life for a whiteboard.<a href="#t11:17" class="time">11:17</a>
wwoodsyes rawhide .treeinfo still says "development" but that's irrelevant to testing<a href="#t11:17" class="time">11:17</a>
f13jlaska: we take the rawhide tree, we point pungi at it, and let pungi create the Fedora tree from the bits in rawhide<a href="#t11:18" class="time">11:18</a>
* viking-ice bling an idea online whiteboard..<a href="#t11:18" class="time">11:18</a>
jlaskawwoods: yes and no<a href="#t11:18" class="time">11:18</a>
f13jlaska: the packages are the same.  Some of the data bits, like the .treeinfo and the repodata and whatnot will be slightly different<a href="#t11:18" class="time">11:18</a>
jlaskaexactly<a href="#t11:18" class="time">11:18</a>
jlaskathere is definitely some overlap in terms of testing rawhide packages<a href="#t11:19" class="time">11:19</a>
wwoodsI think "some" understates it<a href="#t11:19" class="time">11:19</a>
f13jlaska: since (mostly) the same tool is used to create rawhide and the RC spin, mostly we're looking at the rc bits to make sure the compose process didn't fall over<a href="#t11:19" class="time">11:19</a>
f13jlaska: otherwise rawhide works perfectly fine to test installability, functionality, etc...<a href="#t11:20" class="time">11:20</a>
wwoodsFor purposes of Fedora QA, the set of things that are RC-specific is tiny. Furthermore that stuff can't get tested outside the RH firewall<a href="#t11:20" class="time">11:20</a>
f13jlaska: and others use pungi locally to produce local iso sets to test things like iso installs<a href="#t11:20" class="time">11:20</a>
jlaskaf13: so the stage2.img and ramdisk's between rawhide and the final RC will be the same?<a href="#t11:20" class="time">11:20</a>
f13jlaska: no, they are recreated<a href="#t11:20" class="time">11:20</a>
jlaskaor will those change during the pungi-ficcation process?<a href="#t11:20" class="time">11:20</a>
f13jlaska: rather have been recreated.<a href="#t11:20" class="time">11:20</a>
wwoodsbut we're not going to redo the entire test process because we've changed a handful of metadata<a href="#t11:21" class="time">11:21</a>
jlaskawwoods: I haven't suggested that<a href="#t11:21" class="time">11:21</a>
jlaskawwoods: I'm just trying to understand the current process ... and reconcile the differences with a more formal QA process<a href="#t11:21" class="time">11:21</a>
jlaskawe can make recommendations from there ... I certainly don't want to suggest anything disruptive at this point :)<a href="#t11:22" class="time">11:22</a>
wwoodsgotcha<a href="#t11:23" class="time">11:23</a>
wwoodswell, we can discuss the differences between our process and a more formal QA process at a later time<a href="#t11:23" class="time">11:23</a>
wwoodsI'd be happy to give you a detailed walkthrough of the current Fedora process<a href="#t11:23" class="time">11:23</a>
f13jlaska: basically we put trust in the tools to produce consistant output<a href="#t11:23" class="time">11:23</a>
f13jlaska: and test that trust by reproducing the output in many places and testing said output<a href="#t11:24" class="time">11:24</a>
jlaskaf13: so what has worked really well in "other areas" is when the RC is basically read-only from that point out ... meaning, all things being equal, it's what would get rsync'd and written to media for customers<a href="#t11:24" class="time">11:24</a>
jlaskaf13: hehe ... I'm in QA, I don't have that trust ;)<a href="#t11:24" class="time">11:24</a>
wwoodsbut! at the moment we're hip-deep in the process already and less than a week from GA<a href="#t11:24" class="time">11:24</a>
viking-icehas anyone done some testing on more "complex" partition layout in anaconda than the default.. I have been faced with weird behavior of the "ask for encrypted password" box in anaconda with multiple encrypted ( ext3, ext4 ) and none encrypted partition layout.<a href="#t11:24" class="time">11:24</a>
wwoodswe need to focus on getting through the process first<a href="#t11:24" class="time">11:24</a>
f13so that we can have confidence in what we produce as "RC" on a compose machine is supposed to be the same thing that was produced for rawhide which is mirrored and public.<a href="#t11:24" class="time">11:24</a>
jds2001viking-ice: i have kickstarts in snake for some of that stuff.<a href="#t11:25" class="time">11:25</a>
jlaskajds2001: ooh ... any chance you could share ... maybe we can package some of these with snake?<a href="#t11:25" class="time">11:25</a>
f13jlaska: basically it's working around the fact that getting the bits from the compose machine to the world is expensive in time, money, and effort.<a href="#t11:25" class="time">11:25</a>
wwoodsjlaska: should we schedule a meeting sometime so we can give an overview of the evolved Fedora QA process to RHEL QE folks?<a href="#t11:25" class="time">11:25</a>
f13jlaska: something that RHEL doesn't necessarily have to worry about.<a href="#t11:26" class="time">11:26</a>
* poelcat thinks this would be a good fudcon session as this disagreement seems to comes up from time and seems rooted in each person's definition of "how formal of a QA process" fedora requires<a href="#t11:26" class="time">11:26</a>
wwoodsf13: not to mention the difference in what our "customers" expect<a href="#t11:26" class="time">11:26</a>
jds2001jlaska: not a problem :)<a href="#t11:26" class="time">11:26</a>
f13that and the fact that we don't have an automated testing lab to throw the compose output at.<a href="#t11:26" class="time">11:26</a>
poelcatf13: we do, it hasn't been used<a href="#t11:26" class="time">11:26</a>
f13poelcat: or it's unusable.<a href="#t11:26" class="time">11:26</a>
f13and not open source thus can't be a part of the official Fedora infrastructure<a href="#t11:27" class="time">11:27</a>
wwoodsthis conversation's been had a few times and now isn't really the time<a href="#t11:27" class="time">11:27</a>
poelcatit could still provide value, but we don't have to argue about that here and now<a href="#t11:27" class="time">11:27</a>
f13wwoods: I agree<a href="#t11:28" class="time">11:28</a>
wwoodsf13: when do we need to start synching the presumed-final bits?<a href="#t11:28" class="time">11:28</a>
f13wwoods: you mean the bits that are already synced?<a href="#t11:28" class="time">11:28</a>
wwoodser, okay. when's the last minute we can hit the Big Red Button Of Doom?<a href="#t11:28" class="time">11:28</a>
f13wwoods: the minute before I chmod the 9 directory to allow mirrors access to it<a href="#t11:29" class="time">11:29</a>
f13which I'd like to do today or tomorrow.<a href="#t11:29" class="time">11:29</a>
wwoodsokay. so at the outside we have ~36 hours to make sure there are no showstoppers remaining<a href="#t11:29" class="time">11:29</a>
wwoodsand that's if we really want to test f13's patience<a href="#t11:30" class="time">11:30</a>
wwoodsany larger discussions of general QA strategy and philosophy will have to wait until after then<a href="#t11:30" class="time">11:30</a>
f13yeah, the longer we delay the fewer mirrors we'll have ready to go come GA.<a href="#t11:30" class="time">11:30</a>
jlaskaf13: you raise a good point about the "getting the bits out" difference between fedora composition and RHEL ... I'll churn the brain a bit and perhaps we all can discuss further @ FUDCON<a href="#t11:31" class="time">11:31</a>
f13also, anything found after this afternoon will likely mean a slip in the release date.<a href="#t11:31" class="time">11:31</a>
wwoodsif you really think the tree ought to be QA'd by running it through some automated system, be my guest, let me know how it goes<a href="#t11:31" class="time">11:31</a>
wwoodsbut we do not have the time to discuss or develop such an architecture right now.<a href="#t11:31" class="time">11:31</a>
wwoodsgetting back to testing Live<a href="#t11:32" class="time">11:32</a>
wwoodsjeremy's in class at the moment, I believe, but we should be getting Live images sometime later today<a href="#t11:32" class="time">11:32</a>
f13I've got 3 machines for which I can use to test live, an i386 mac mini, an x86_64 imac, and an x86_64 amd system<a href="#t11:32" class="time">11:32</a>
jlaskaf13: wwoods: sorry for the tangeant, my QA spidey sense was tingling from past "gotchas" (not in a good way) ... we'll revisit post RC<a href="#t11:32" class="time">11:32</a>
f13only one can be used with usb live images<a href="#t11:33" class="time">11:33</a>
f13(the amd)<a href="#t11:33" class="time">11:33</a>
f13jlaska: sure thing, more than happy to have the conversation<a href="#t11:33" class="time">11:33</a>
wwoodsjlaska: It's definitely worth discussing. Later.<a href="#t11:33" class="time">11:33</a>
wwoodsAFAIK this is the same process we used for Alpha and Beta and the PR so we're fairly sure it's OK<a href="#t11:34" class="time">11:34</a>
f13wwoods: so I'll hit actual media for those two arches plus usb, and do installs from both<a href="#t11:34" class="time">11:34</a>
f13and I can do testing in kvm of the same<a href="#t11:34" class="time">11:34</a>
wwoodsright, I've got an x86 mini and two x86_64 dells. oh, and that G5 power mac<a href="#t11:34" class="time">11:34</a>
wwoodsare we getting ppc live images this time around?<a href="#t11:34" class="time">11:34</a>
wwoodsjwb: ping? are you the ppc keymaster?<a href="#t11:34" class="time">11:34</a>
jwbi am, we aren't<a href="#t11:35" class="time">11:35</a>
jwbat least not in time for release<a href="#t11:35" class="time">11:35</a>
f13I'll hook up with jeremy and get the Live/ dir populated on reducto with the release candidate live images<a href="#t11:36" class="time">11:36</a>
jlaskawwoods: are there certain areas of the installation matrix you're looking for community test feedback on?<a href="#t11:36" class="time">11:36</a>
jlaskawwoods: or is there a "yet to be created" matrix whose results you need?<a href="#t11:36" class="time">11:36</a>
jwbwwoods, have you heard of many requests for PPC live cd/dvds?<a href="#t11:36" class="time">11:36</a>
wwoodsjwb: not really, although I enjoy having them<a href="#t11:37" class="time">11:37</a>
jwbwwoods, i've not done any for a couple reasons.  1, there are some interesting "which kernel" issues, and 2, no demand<a href="#t11:38" class="time">11:38</a>
wwoodsthere's currently no matrix specifically for live images, so we have to fall back on the ReleaseCriterie and common sense<a href="#t11:38" class="time">11:38</a>
f13jlaska: we have no matrix for live image testing<a href="#t11:38" class="time">11:38</a>
jwbbut we can look at that again if we want<a href="#t11:38" class="time">11:38</a>
jlaskaf13: we stubbed out a one-the-fly matrix for swfdec and PackageKit a few weeks back and got some great community feedback<a href="#t11:39" class="time">11:39</a>
wwoodsjwb: yeah, no, it's tricky to get right and people aren't really clamoring for it<a href="#t11:39" class="time">11:39</a>
* wwoods brb sigwife<a href="#t11:39" class="time">11:39</a>
viking-ice /me for the record common sense ain't that common... :)<a href="#t11:39" class="time">11:39</a>
viking-icefumble..<a href="#t11:39" class="time">11:39</a>
wwoodsheh<a href="#t11:39" class="time">11:39</a>
jlaskawe can certainly rinse-and-repeat for some "basic" community assistance on the Live CD part<a href="#t11:39" class="time">11:39</a>
f13jlaska: yeah, that was successful, but the bits were also publically available.<a href="#t11:39" class="time">11:39</a>
wwoodsyeah, that's why we like to have a well-defined test plan with well-defined test cases<a href="#t11:40" class="time">11:40</a>
f13live cd ones aren't, and slightly more difficult to produce on ones own.<a href="#t11:40" class="time">11:40</a>
jlaskaf13: ah ... so we've have to post the ISO images somewhere first for this?<a href="#t11:40" class="time">11:40</a>
jds2001well, anyone can *make* these bits.<a href="#t11:40" class="time">11:40</a>
f13jlaska: to get external testing, yes.<a href="#t11:40" class="time">11:40</a>
wwoodsbut yeah, check the simple stuff: burn the image, boot the image, make sure all the boot menu items work as expected<a href="#t11:40" class="time">11:40</a>
f13jds2001: yes, but it's more trixy since you can't use mock.<a href="#t11:40" class="time">11:40</a>
wwoodswhen it boots, make sure everything comes up right. make sure all the apps in the menus start up.<a href="#t11:40" class="time">11:40</a>
jds2001right....<a href="#t11:40" class="time">11:40</a>
jlaskaf13: is that a possibility?<a href="#t11:40" class="time">11:40</a>
jlaskaf13: e.g. posting those iso images?<a href="#t11:41" class="time">11:41</a>
f13jlaska: posting yes, posting and having any reasonable amount of time to see them get downloaded, testing, and reported upon not really<a href="#t11:41" class="time">11:41</a>
f13jlaska: as stated before, any needed changes would have to be noticed by COB today or else we'd slip the release.<a href="#t11:41" class="time">11:41</a>
f13and I'm not one to pre-slip the release just to give time to potentially find problems<a href="#t11:42" class="time">11:42</a>
jlaskaf13: ah okay ... so the best we could hope for community feedback would be proposing some LiveCD sanity tests?<a href="#t11:42" class="time">11:42</a>
f13probably, if you ignore the fact that there is an office here and in RDU full of Fedora community members<a href="#t11:42" class="time">11:42</a>
f13they just also happen to be RH employees<a href="#t11:42" class="time">11:42</a>
jlaskaindeed<a href="#t11:42" class="time">11:42</a>
wwoodsposting the isos is a waste of time and bandwidth<a href="#t11:43" class="time">11:43</a>
f13we usually burn a stack of CDs and USB keys then go wander about the office asking people to boot stuff.<a href="#t11:43" class="time">11:43</a>
jds2001sounds like a plan :)<a href="#t11:43" class="time">11:43</a>
wwoodsat least with our current schedule<a href="#t11:43" class="time">11:43</a>
wwoodserr - posting the *install* isos<a href="#t11:44" class="time">11:44</a>
jlaskaf13: wwoods: indeed, given the current time restrictions, the return on investment of publicly mirroring the Live CD iso's may be too low<a href="#t11:45" class="time">11:45</a>
wwoodssorry<a href="#t11:45" class="time">11:45</a>
jds2001that's not an issue, they are triviaal to produce.<a href="#t11:45" class="time">11:45</a>
jds2001the install iso's, that is.<a href="#t11:45" class="time">11:45</a>
wwoodshopefully we can make it easier to bake your own semi-official live images at home<a href="#t11:45" class="time">11:45</a>
wwoodsfor F10<a href="#t11:45" class="time">11:45</a>
f13jds2001: right, until you consider the reluctance of QA to make assumptions that what you produce and what jeremy produced are 'the same' enough for testing (:<a href="#t11:45" class="time">11:45</a>
wwoodsI'm comfortable with that assumption<a href="#t11:46" class="time">11:46</a>
* jds2001 was just going to say that.<a href="#t11:46" class="time">11:46</a>
wwoodsbecause our "customers" seem comfortable with it and they accept the results of that testing<a href="#t11:46" class="time">11:46</a>
jds2001and it is the only practical way to get community testing.<a href="#t11:46" class="time">11:46</a>
wwoodsThere is a fundamental difference in expectations between RHEL consumers and Fedora consumers<a href="#t11:46" class="time">11:46</a>
jds2001+1000<a href="#t11:47" class="time">11:47</a>
* jds2001 being both :)<a href="#t11:47" class="time">11:47</a>
wwoodsexactly - and you don't apply the same standards to both because you don't have the same expectations of both<a href="#t11:47" class="time">11:47</a>
wwoodsanyway, again, tangent<a href="#t11:47" class="time">11:47</a>
viking-icetrue<a href="#t11:47" class="time">11:47</a>
f13heee<a href="#t11:48" class="time">11:48</a>
jlaskaf13: my reluctance comes from experience ... but I'm definitely open to new ways of doing things ;)<a href="#t11:48" class="time">11:48</a>
wwoodsit makes sense to spend a month testing frozen bits, if those bits need to be supported for 7 years<a href="#t11:48" class="time">11:48</a>
f13jlaska: I have reluctance too, which is why I trust, but verify<a href="#t11:48" class="time">11:48</a>
jlaskaf13: well spoken<a href="#t11:48" class="time">11:48</a>
f13I just verify a smaller set of things than we have on our public matrix<a href="#t11:48" class="time">11:48</a>
jlaskaf13: I think what I'm struggling with is giving the community a chance to join in the "verify" part<a href="#t11:48" class="time">11:48</a>
jlaskabut that's the future discussion<a href="#t11:48" class="time">11:48</a>
wwoodsindeed<a href="#t11:49" class="time">11:49</a>
f13what will change that dynamic a lot is when we move to doing the composes in PHX on "public" hardware/directories<a href="#t11:49" class="time">11:49</a>
jds2001this sounds like an excellent fudcon discussion :)<a href="#t11:49" class="time">11:49</a>
wwoodsanyway, so the take-away here is.. we're *not* going to be able to make the LiveCD images public?<a href="#t11:49" class="time">11:49</a>
jlaskaf13: oh yeah ... that's a good point<a href="#t11:49" class="time">11:49</a>
jlaskawwoods: yeah I think so<a href="#t11:49" class="time">11:49</a>
DemonJestercouldnt you simply provide "official" build kickstarts for the community to build the live cd's themselves?<a href="#t11:50" class="time">11:50</a>
f13wwoods: yes, that is my estimation.<a href="#t11:50" class="time">11:50</a>
jlaskajds2001: +++ :))<a href="#t11:50" class="time">11:50</a>
wwoodsDemonJester: yes, like we do with the pungi stuff<a href="#t11:50" class="time">11:50</a>
f13DemonJester: we do that already, but the problem is that tools sometimes fail, and compose environments can differ.<a href="#t11:50" class="time">11:50</a>
wwoodsexcept the livecd tools aren't quite as robust or mature<a href="#t11:50" class="time">11:50</a>
wwoodsso, yeah, the results are not as reliable<a href="#t11:50" class="time">11:50</a>
jlaskawwoods: so perhaps as f13 suggested ... we put a call out for folks inside the office ... and provide a matrix?  DOes this seem reasonable ... or is that too much ofa sledgehammer approach for the feedback you're looking for?<a href="#t11:51" class="time">11:51</a>
wwoodsthat's definitely a goal, though<a href="#t11:51" class="time">11:51</a>
DemonJestergotcha<a href="#t11:51" class="time">11:51</a>
wwoodsjlaska: no, that's pretty much what I had in mind, but I'm not sure about throwing together a matrix in a few minutes<a href="#t11:51" class="time">11:51</a>
wwoodsstill, better than nothin'<a href="#t11:51" class="time">11:51</a>
jlaskawwoods: definitly ... and we can have non-rht community help in generating the matrix<a href="#t11:52" class="time">11:52</a>
f13jlaska: that would work, but yeah, we have maybe an hour or two to put up a matrix<a href="#t11:52" class="time">11:52</a>
jlaskaI think we can pull something together in 30mins<a href="#t11:52" class="time">11:52</a>
f13(counting the 30 minutes for me to bolt down some food)<a href="#t11:52" class="time">11:52</a>
jlaskaif folks want ... we can toss ideas out here now<a href="#t11:52" class="time">11:52</a>
wwoodsright<a href="#t11:53" class="time">11:53</a>
wwoodsso we're brainstorming a list of Live test cases?<a href="#t11:53" class="time">11:53</a>
jlaskayeah .. .what the heck ... I'll jot 'em down and post them<a href="#t11:53" class="time">11:53</a>
wwoodsokay. obvious stuff:<a href="#t11:53" class="time">11:53</a>
jds2001it boots, autologin works, screensaver not activated, persistence works if applicable, installation works.<a href="#t11:54" class="time">11:54</a>
wwoods* application startup for everything in the menu<a href="#t11:54" class="time">11:54</a>
jlaskainstallation ... using defaults?<a href="#t11:54" class="time">11:54</a>
wwoodsyou can't configure liveCD installation<a href="#t11:54" class="time">11:54</a>
jds2001jlaska: i think that's all you can do<a href="#t11:54" class="time">11:54</a>
wwoodsit just writes itself to the hard drive<a href="#t11:54" class="time">11:54</a>
jlaskajds2001: cool, makes sense<a href="#t11:54" class="time">11:54</a>
* DemonJester agrees<a href="#t11:54" class="time">11:54</a>
jlaskawwoods: you mean going through the gnome menus and starting all apps?<a href="#t11:55" class="time">11:55</a>
wwoodsjlaska: yep<a href="#t11:55" class="time">11:55</a>
wwoodsthere are't that many<a href="#t11:55" class="time">11:55</a>
jlaskagotcha ... that's bold ;)<a href="#t11:55" class="time">11:55</a>
wwoodsit's a ReleaseRequirement<a href="#t11:55" class="time">11:55</a>
* jlaska knows there is some dogtail online for that somewhere<a href="#t11:55" class="time">11:55</a>
jds2001shouldnt take too long<a href="#t11:55" class="time">11:55</a>
wwoodserr ReleaseCriteria<a href="#t11:55" class="time">11:55</a>
wwoodsgotta do it for KDE too, though<a href="#t11:55" class="time">11:55</a>
jlaskawwoods: good point ... so what are all the images we'll need ot test?<a href="#t11:55" class="time">11:55</a>
wwoodsdo we do PK stuff differently for RO/RW?<a href="#t11:55" class="time">11:55</a>
f13if we're headed into matrix discussion, I'm going to step away for a few minutes.<a href="#t11:56" class="time">11:56</a>
jlaskaf13: take the blue pill!<a href="#t11:56" class="time">11:56</a>
wwoodsjlaska: x86_64/i386 * KDE/GNOME<a href="#t11:56" class="time">11:56</a>
jlaskaso 4 iso's?<a href="#t11:56" class="time">11:56</a>
viking-iceyea that's one thing i've been wondering about are most of you just doing default installs with anaconda cause I think anaconda is in good shape for defaults but on the grey area for non default installs..<a href="#t11:57" class="time">11:57</a>
jlaskado we care about the medium used to boot them (e.g. cdrom vs usb key)?<a href="#t11:57" class="time">11:57</a>
jds2001just hand them out via person 1 gets gnome i386, person 2 gets gnome x86_64, etc.<a href="#t11:57" class="time">11:57</a>
wwoodsviking-ice: default what? partition layout, package selection?<a href="#t11:57" class="time">11:57</a>
viking-icewwoods yep..<a href="#t11:57" class="time">11:57</a>
jds2001jlaska: we care if persistence matters<a href="#t11:57" class="time">11:57</a>
wwoodsviking-ice: check the test matrix (<a href="http://fedoraproject.org/wiki/QA/TestResults/Fedora9Install/FinalRelease">http://fedoraproject.org/wiki/QA/TestResults/Fedora9Install/FinalRelease</a>)<a href="#t11:57" class="time">11:57</a>
wwoodsit details the different partitioning schemes etc we have tested<a href="#t11:57" class="time">11:57</a>
wwoodsnote that there are *not* test cases for encryption yet! I've been testing it kind of scattershot<a href="#t11:58" class="time">11:58</a>
* jds2001 tested encryption in ks.<a href="#t11:58" class="time">11:58</a>
jds2001it worked awhile back, not sure about now.<a href="#t11:58" class="time">11:58</a>
jlaskawwoods: there are a few ...<a href="http://fedoraproject.org/wiki/Anaconda/Features/EncryptedBlockDevices#head-3754cffc4686ac4c76bebcc9605e3f82f0b066b0">http://fedoraproject.org/wiki/Anaconda/Features/EncryptedBlockDevices#head-3754cffc4686ac4c76bebcc9605e3f82f0b066b0</a><a href="#t11:58" class="time">11:58</a>
wwoodsjlaska: yeah, we care about RO (CD/DVD) vs. RO (USB) vs. RW (USB)<a href="#t11:58" class="time">11:58</a>
jlaskajds2001: re: persistance ... is that included by default if you burn a liveCD ... or is special livecd-tools magic required to do that?<a href="#t11:59" class="time">11:59</a>
jlaskawwoods: okay<a href="#t11:59" class="time">11:59</a>
jds2001i think special magic is required.<a href="#t11:59" class="time">11:59</a>
wwoodsjlaska: persistence only works on USB<a href="#t11:59" class="time">11:59</a>
jds2001of course, since that's the only RW media :)<a href="#t11:59" class="time">11:59</a>
wwoodsyou need to pass livecd-iso-to-disk a special flag<a href="#t11:59" class="time">11:59</a>
wwoodslivecd-iso-to-disk --overlay-size-mb <size><a href="#t12:00" class="time">12:00</a>
jlaskajds2001: wwoods: so do we consider that a test for the livecd-tools suite ... and not for the provided liveCD iso images?<a href="#t12:00" class="time">12:00</a>
poelcatwwoods: how much longer do you guys need for QA meeting? BugZappers were hoping to meet at 12:00<a href="#t12:00" class="time">12:00</a>
wwoodswe can take this session to #fedora-qa<a href="#t12:01" class="time">12:01</a>
viking-icewwoods: we might wanna add to the package selection test matrix All packages ( along with default and minimal )<a href="#t12:01" class="time">12:01</a>
wwoodsviking-ice: it's there already<a href="#t12:01" class="time">12:01</a>

Generated by irclog2html.py 2.3 by <a href="mailto:marius@pov.lt">Marius Gedminas</a> - find it at <a href="http://mg.pov.lt/irclog2html/">mg.pov.lt</a>!