From Fedora Project Wiki

< QA‎ | Meetings

IRC Transcript

wwoodsbah! fedora QA meeting will be delayed a bit (stupid DST)<a href="#t09:57" class="time">09:57</a>
f13wwoods: lol<a href="#t10:01" class="time">10:01</a>
wwoodsokay, QA meeting can start now. blerg!<a href="#t10:33" class="time">10:33</a>
wwoodsI don't have a complex agenda for this one<a href="#t10:34" class="time">10:34</a>
wwoodsbasically all I'm concerned with right now is further filling out the test matrix<a href="#t10:34" class="time">10:34</a>
skvidalwwoods: so new blockers for f8 shouldn't be brought up?<a href="#t10:35" class="time">10:35</a>
wwoodsyou can't block f8 anymore<a href="#t10:35" class="time">10:35</a>
wwoodsit's already done<a href="#t10:35" class="time">10:35</a>
* skvidal was kidding<a href="#t10:35" class="time">10:35</a>
wwoodsbut I'm going through F8Target looking for things that need to be done as 0-day updates<a href="#t10:35" class="time">10:35</a>
wwoodse.g. yelp crashing on all searches (bug 361041)<a href="#t10:36" class="time">10:36</a>
buggbotBug <a href=""></a> low, low, ---, Matthias Clasen, ASSIGNED , yelp-2.20.0-2.fc8 crashes if an omf contains a bad url<a href="#t10:36" class="time">10:36</a>
wwoodsf13: do we have updates-testing populated now?<a href="#t10:36" class="time">10:36</a>
wwoodsyelp was rebuilt against the newer firefox, so I need to get the whole firefox-dependent stack in order to test yelp<a href="#t10:37" class="time">10:37</a>
f13wwoods: yes.<a href="#t10:38" class="time">10:38</a>
f13wwoods: what would help is finding broken deps and helping us identify these so we don't have broken repos at luanch time.<a href="#t10:38" class="time">10:38</a>
wwoodsis updates-testing a supplement to updates, or a replacement for it?<a href="#t10:39" class="time">10:39</a>
f13supplement.<a href="#t10:39" class="time">10:39</a>
wwoodsno broken deps right now<a href="#t10:39" class="time">10:39</a>
wwoodsjust that I can't pull yelp from koji by itself<a href="#t10:39" class="time">10:39</a>
f13ah, right, I think lmacken fixed up the broken deps last night.<a href="#t10:39" class="time">10:39</a>
wwoodsGRRRRR I hate that pup steals focus whenever it pops up a new window<a href="#t10:40" class="time">10:40</a>
wwoodsI've cancelled this update 5 times during this meeting<a href="#t10:40" class="time">10:40</a>
skvidalwwoods: s/pup/evetything/<a href="#t10:40" class="time">10:40</a>
wwoodsit's fine for new windows to want focus (although IMHO it should be a window manager tuneable and set to off by default)<a href="#t10:40" class="time">10:40</a>
wwoodsbut pup's status stuff should REALLY be just in the main window<a href="#t10:40" class="time">10:40</a>
wwoodsit's weird how much I'm hoping PackageKit pans out<a href="#t10:41" class="time">10:41</a>
lmackenhehe<a href="#t10:41" class="time">10:41</a>
wwoodsit would be nice for all package management UI to be done by a much larger group, and be standard across distros<a href="#t10:42" class="time">10:42</a>
wwoodsanyway. tangent.<a href="#t10:42" class="time">10:42</a>
lmackenthat's the goal :)<a href="#t10:42" class="time">10:42</a>
wwoodsso yeah we'll check for broken deps<a href="#t10:42" class="time">10:42</a>
lmackenyelp will get pulled into testing with the next push, so we should make sure it doesn't break again<a href="#t10:43" class="time">10:43</a>
wwoodsoh so it *did* get pushed, then unpushed because the rest of the gecko stuff wasn't ready<a href="#t10:44" class="time">10:44</a>
lmackenright<a href="#t10:44" class="time">10:44</a>
wwoodslooks like people are on top of it, so I'm not gonna worry about chasing people down<a href="#t10:44" class="time">10:44</a>
wwoodsso yeah, that's about all I had.<a href="#t10:45" class="time">10:45</a>
wwoodsoh, I'm kind of worried about people getting PA set up properly<a href="#t10:45" class="time">10:45</a>
lmackenwhat does "setting it up properly" entail ?<a href="#t10:46" class="time">10:46</a>
wwoodsthat's the problem.<a href="#t10:46" class="time">10:46</a>
wwoodsin theory, upgraders should just have to yum groupinstall sound-and-video<a href="#t10:46" class="time">10:46</a>
wwoodsbut I think there's some trickery with KDE<a href="#t10:46" class="time">10:46</a>
wwoodsand also there's some weirdness if your hardware levels are set too high. people end up turning down the PA volume stuff instead of the actual ALSA mixers that are too high<a href="#t10:47" class="time">10:47</a>
wwoodsthe docs aren't where I'd like 'em to be, basically<a href="#t10:47" class="time">10:47</a>
wwoodsso yeah, if you have some sharp insights on that stuff, send 'em my way or something<a href="#t10:49" class="time">10:49</a>
wwoodsbut I expect to be doing a lot of triage on vague-ass "audio doesn't work right" reports<a href="#t10:50" class="time">10:50</a>
wwoodsare there other things we expect to be doing a lot of hopeless triage on?<a href="#t10:51" class="time">10:51</a>
wwoodsI'll take that as a no. Okay, back to testing updates and trying weirdo upgrades and whatnot. Thanks!<a href="#t10:53" class="time">10:53</a>
ajaxsuspend.<a href="#t10:53" class="time">10:53</a>
wwoodsoh good god yeah<a href="#t10:53" class="time">10:53</a>
wwoodsbut we have some fairly good references (the quirks page) for that<a href="#t10:54" class="time">10:54</a>
ajaxwe're getting to the point where the suspend problems that quirks can't fix are really deep down icky terrible things<a href="#t10:54" class="time">10:54</a>
ajaxbut that's despair for another day<a href="#t10:55" class="time">10:55</a>
wwoodswell, deep-down-terrible things like.. bad BIOS? deep-seated kernel bugs?<a href="#t10:55" class="time">10:55</a>
wwoodsor just incomplete support for stuff (which is where I assume nvidia is)<a href="#t10:55" class="time">10:55</a>
wwoodsoh god the nvidia/suspend thing. yeah.<a href="#t10:56" class="time">10:56</a>
ajaxbios horrors and incomplete support, yeah.<a href="#t10:56" class="time">10:56</a>
wwoodswell, it kind of makes triage easier when there aren't obvious, common things that people will report over and over<a href="#t10:57" class="time">10:57</a>
wwoodskind of<a href="#t10:57" class="time">10:57</a>
wwoodsanyway, yeah, that's something to look out for but it's mostly listed on <a href=""></a><a href="#t10:58" class="time">10:58</a>
wwoodsokay, anything else?<a href="#t10:59" class="time">10:59</a>
poelcatweren't we going to talk about the testing schedule for F9?<a href="#t11:00" class="time">11:00</a>
wwoodsright! I knew there was something.<a href="#t11:02" class="time">11:02</a>
wwoods<a href=""></a> was updated a bit<a href="#t11:03" class="time">11:03</a>
f13actually<a href="#t11:03" class="time">11:03</a>
f13you should look at...<a href="#t11:03" class="time">11:03</a>
f13<a href=""></a><a href="#t11:03" class="time">11:03</a>
f13and try to figure out where you want to insert yourselves in that.<a href="#t11:04" class="time">11:04</a>
f13the Overview is a bit more of a broad overview, above even the changes proposal<a href="#t11:04" class="time">11:04</a>
wwoodsgotcha<a href="#t11:04" class="time">11:04</a>
poelcati was hoping we could agree more on the testing slots here: <a href=""></a><a href="#t11:05" class="time">11:05</a>
wwoodsanyway, on further reflection, I think I have the following comments:<a href="#t11:05" class="time">11:05</a>
wwoods1) "Preview Release" might be a better name than "Release Candidate"<a href="#t11:05" class="time">11:05</a>
poelcatand close on our discussion from last thurs aobut RC testing<a href="#t11:05" class="time">11:05</a>
wwoods2) 3 weeks of final-freeze seemed to be OK, but I'd like it if we were a *little* pickier about changes next time<a href="#t11:05" class="time">11:05</a>
wwoodsbut I think that came from NM being late and changes cascading in because of that<a href="#t11:06" class="time">11:06</a>
wwoods(and the KDE team running behind)<a href="#t11:06" class="time">11:06</a>
f13wwoods: being picker about what goes in woudl help if you were involved in the decisions.<a href="#t11:07" class="time">11:07</a>
* poelcat thinks we should have more time for things to bake to avoid things like last wed to fri @ 9pm<a href="#t11:07" class="time">11:07</a>
f13wwoods: I find it hard to say no to simple bugfixes in ancillary packages.<a href="#t11:07" class="time">11:07</a>
poelcatf13: why?<a href="#t11:07" class="time">11:07</a>
wwoodsright, and I generally don't have a problem with those<a href="#t11:07" class="time">11:07</a>
f13poelcat: the thing that really kicked our ass was a major upgrade of rhgb, long before the final freeze.<a href="#t11:08" class="time">11:08</a>
f13poelcat: it just wasn't reproducable until specific scenarios were found, late in teh game.<a href="#t11:08" class="time">11:08</a>
f13the other last minute thing was because I didn't fully review the new selinux-policy before tagging it, which was bad on me, selinux-policy no longer gets a free ride.<a href="#t11:08" class="time">11:08</a>
f13poelcat: "why" what?<a href="#t11:08" class="time">11:08</a>
wwoodsno mostly minor bugfixes were fine, and the KDE changes kept being scary but seemed to turn out OK<a href="#t11:09" class="time">11:09</a>
wwoodsI'm thinking more of reactive changes that got shoved through - not sure I can cite immediate examples but selinux-policy is a candidate<a href="#t11:09" class="time">11:09</a>
poelcatwhy taking in simple fixes is okay... I guess I feel really strongly that the GOLD bits are really important, particularly to our future user base<a href="#t11:09" class="time">11:09</a>
wwoodsuhh. what GOLD bits? Are you suggesting that the thing listed as RC1 should actually be an RC?<a href="#t11:10" class="time">11:10</a>
f13wwoods: selinux was purely my fault.  We in hte past gave selinux-policy a free ride as Dan was very good at what he did.<a href="#t11:10" class="time">11:10</a>
f13in this case Dan was sleep deprived or something and stomped on some changes Jeremy did.<a href="#t11:10" class="time">11:10</a>
f13and we didn't notice in time.<a href="#t11:11" class="time">11:11</a>
poelcatwwoods: what we GA should sit a little more and change less at the end<a href="#t11:11" class="time">11:11</a>
wwoodspoelcat: we're not talking about that stage of the release right now<a href="#t11:11" class="time">11:11</a>
poelcati think I'm in a minority on this view, that is okay :)<a href="#t11:11" class="time">11:11</a>
jeremypoelcat: if we do that, we just increase the amount available on day-0<a href="#t11:11" class="time">11:11</a>
f13to be fair, it /did/ change less<a href="#t11:11" class="time">11:11</a>
f13and there is that.<a href="#t11:11" class="time">11:11</a>
f13we already have a /huge/ amount of stuff piled up for 0-day<a href="#t11:11" class="time">11:11</a>
wwoodsright<a href="#t11:11" class="time">11:11</a>
wwoodsWe're on a time-based release schedule that emphasizes rapid development<a href="#t11:12" class="time">11:12</a>
poelcatjeremy: to me that is a lesser problem than GOLD media that isn't as stable<a href="#t11:12" class="time">11:12</a>
wwoodsfurthermore we're a heavily developer-oriented distribution<a href="#t11:12" class="time">11:12</a>
poelcatwwoods: we say that all the time, but what do we base that on?<a href="#t11:12" class="time">11:12</a>
ajaxthe fact that only developers are insane enough to use our software?<a href="#t11:13" class="time">11:13</a>
ajax(sorry.  trolling.)<a href="#t11:13" class="time">11:13</a>
poelcat:)<a href="#t11:13" class="time">11:13</a>
f13poelcat: the fact that we dropped features because they weren't done on time<a href="#t11:13" class="time">11:13</a>
poelcatwe did ? :)<a href="#t11:13" class="time">11:13</a>
f13I just don't think it's worthwile of our time to sit on bits for a week just so that we can feel like they're "stable"<a href="#t11:14" class="time">11:14</a>
poelcatokay, we dropped some :)<a href="#t11:14" class="time">11:14</a>
wwoodsIf I had free time, I'd find a good metric to quantify Upstream Involvement per developer<a href="#t11:14" class="time">11:14</a>
poelcati'm not saying sit on them, I'm saying test them :)<a href="#t11:14" class="time">11:14</a>
f13we're /always/ going to find more bugs, and we're just going to make it harder to get done in time for the next release.<a href="#t11:14" class="time">11:14</a>
wwoodsand then look at the average (and total) Upstream Involvement per distribution<a href="#t11:14" class="time">11:14</a>
f13poelcat: my point on this is that when we enter the final freeze, there are people looking at and fixing bugs<a href="#t11:14" class="time">11:14</a>
wwoodsand I'd make serious bets that Fedora would be waaaay ahead of anything else<a href="#t11:14" class="time">11:14</a>
f13poelcat: this causes "change"<a href="#t11:15" class="time">11:15</a>
f13poelcat: just because we (Red Hat) didn't find those bugs doesn't mean that they shouldn't be fixed.<a href="#t11:15" class="time">11:15</a>
f13poelcat: we have a seriously /huge/ amount of software, there is going to be churn as these bugs are found and fixed.  We're giving a goodly amount of time for that last bit of testing/bugfixing<a href="#t11:15" class="time">11:15</a>
wwoodsthe work will *always* expand to fill available testing time<a href="#t11:16" class="time">11:16</a>
poelcatf13: but I think we too easily concede that the scramble like last week cannot be avoided<a href="#t11:16" class="time">11:16</a>
wwoodsbecause the amount of work you *could* do is *vast*<a href="#t11:16" class="time">11:16</a>
poelcati wonder if it can be reduced, maybe I'm naive :)<a href="#t11:16" class="time">11:16</a>
f13poelcat: unless you just stop looking at the bits, I don't think it can be avoided.<a href="#t11:16" class="time">11:16</a>
wwoodsthe solution is not to grow the freeze but to make the process more effective<a href="#t11:16" class="time">11:16</a>
f13poelcat: then again, not giving things free ride like selinux-policy would help too.<a href="#t11:16" class="time">11:16</a>
wwoods..which is an example of making the process more effective<a href="#t11:17" class="time">11:17</a>
f13we have 23 days, which actually becomes 16~ days to get bugfixes in<a href="#t11:17" class="time">11:17</a>
f13which is more like 14 days, two weeks.<a href="#t11:17" class="time">11:17</a>
f13so, two weeks of "only bugfix builds" getting in, which we have a mechanism in place to get human eyes on teh changes.<a href="#t11:18" class="time">11:18</a>
wwoods"more freeze time" does not scale as well as "more people examining changes"<a href="#t11:18" class="time">11:18</a>
f13indeed<a href="#t11:19" class="time">11:19</a>
wwoodswe're already using 2/26 (call it 10%) of the cycle for the final change<a href="#t11:19" class="time">11:19</a>
poelcatso is 1.6.4 wrong here: <a href=""></a><a href="#t11:19" class="time">11:19</a>
wwoodserr final freeze<a href="#t11:19" class="time">11:19</a>
poelcatfor starters then, how about if the schedule to reflects what our actual testing windows are<a href="#t11:20" class="time">11:20</a>
poelcati think everyone has a different definition<a href="#t11:21" class="time">11:21</a>
lmackenf13: +1 for not letting selinux get a free ride<a href="#t11:22" class="time">11:22</a>
wwoodsfinal freeze is currently ~3.5 weeks before release (1mo - 1wk)<a href="#t11:22" class="time">11:22</a>
poelcatwwoods: so what part of what I've proposed needs to be fixd?<a href="#t11:23" class="time">11:23</a>
wwoodss/Release Candidate/Release Preview/<a href="#t11:23" class="time">11:23</a>
f13what defines a "testing window"<a href="#t11:24" class="time">11:24</a>
f13?<a href="#t11:24" class="time">11:24</a>
f13I thought the only time a testing window wouldn't be open is when we aren't taking in any changes, period<a href="#t11:24" class="time">11:24</a>
wwoodsf13: the "Freezes" listed are shorter than what's listed<a href="#t11:24" class="time">11:24</a>
wwoodsbecause one week of each freeze is consumed by compose -> mirrors<a href="#t11:25" class="time">11:25</a>
wwoodsso a three week freeze gives us two weeks to test (at most)<a href="#t11:25" class="time">11:25</a>
poelcatf13: when want people to focus on testing alpha, beta, RC<a href="#t11:25" class="time">11:25</a>
f13ok, so a test window for /that/ particular compose.<a href="#t11:25" class="time">11:25</a>
wwoodsright<a href="#t11:25" class="time">11:25</a>
wwoodsanyway current schedule has final freeze at 8 apr (1 week after translation freeze). I don't know what day of the week we traditionally do freezes but the alpha has 8 weeks allocated<a href="#t11:27" class="time">11:27</a>
wwoodsand then you've got beta = 5 weeks and then 4 weekly snapshot releases<a href="#t11:27" class="time">11:27</a>
poelcati made everything land on thursdays<a href="#t11:27" class="time">11:27</a>
poelcatwhich is what we've traditionally (i believe) done<a href="#t11:27" class="time">11:27</a>
f13Freezes are on Tuesday, releases on thursdays<a href="#t11:27" class="time">11:27</a>
wwoodsthen two weeks for PR1<a href="#t11:28" class="time">11:28</a>
f13We really should start freezing in the morning of Tuesday<a href="#t11:28" class="time">11:28</a>
f13IE what was in rawhide the night before<a href="#t11:28" class="time">11:28</a>
f13so that Tuesday's rawhide is a reasonable test case<a href="#t11:28" class="time">11:28</a>
f13that gives you Tuesday, Wed, and maybe Thurs to get fixes in, compose should be done and handed to IS by Fri/Mon in order to be released on the next Thursday<a href="#t11:29" class="time">11:29</a>
f13since the Alpha isn't a blocking freeze, we can extend that time a bit, however then we risk having stale bits which isn't helpful.<a href="#t11:29" class="time">11:29</a>
f13perhaps it would be best to identify what the specific goals of an Alpha snapshot are, vs a Beta, vs a Pre-release<a href="#t11:30" class="time">11:30</a>
wwoodsthis schedule also has "testing" *after* compose->sync->release<a href="#t11:30" class="time">11:30</a>
poelcatyes<a href="#t11:30" class="time">11:30</a>
poelcattesting the "alpha, beta, rc"<a href="#t11:30" class="time">11:30</a>
wwoodsfeh<a href="#t11:30" class="time">11:30</a>
wwoodsthey're rawhide snapshots<a href="#t11:31" class="time">11:31</a>
wwoodsthe only thing that's useful about testing the beta is that the beta is a guaranteed-installable rawhide snapshot<a href="#t11:31" class="time">11:31</a>
wwoodstesting rawhide during the compose/stage/release is exactly as useful as testing the release itself<a href="#t11:31" class="time">11:31</a>
poelcatmaybe I explain my thinking better here: <a href=""></a><a href="#t11:32" class="time">11:32</a>
poelcati don't think we can engage more people by thinking in terms of "rawhide"<a href="#t11:33" class="time">11:33</a>
wwoodsthis point has already been made, bug: realistically the average user does not help test anything at all<a href="#t11:33" class="time">11:33</a>
poelcatso why not try to make it more accessible to them?<a href="#t11:33" class="time">11:33</a>
f13wwoods: also, if you have a rescue.iso from a snapshot, it can be used to install rawhide.  This gets you access to the newer bits while using a known stable installer.<a href="#t11:33" class="time">11:33</a>
f13in the past, test releases were mostly used to test installer code paths for media installs<a href="#t11:34" class="time">11:34</a>
f13since we don't make media each night<a href="#t11:34" class="time">11:34</a>
wwoodswe're getting onto a tangent about the purpose of our testing<a href="#t11:35" class="time">11:35</a>
wwoodsthat's not something I want to start right now<a href="#t11:35" class="time">11:35</a>
poelcatif we don't know what our purpose is how can we plan the schedule? <a href="#t11:35" class="time">11:35</a>
f13simply put<a href="#t11:35" class="time">11:35</a>
f13the purpose is to provide users with a known good jump off point.<a href="#t11:36" class="time">11:36</a>
f13they can start from a provided snapshot to install (the most difficult part), and from there continue to upgrade to get access to the latest bits<a href="#t11:36" class="time">11:36</a>
poelcatthat makes sense<a href="#t11:36" class="time">11:36</a>
f13almost any bug found with a snapshot is going to get an immediate "please reproduce with fully updated Rawhide" response.<a href="#t11:36" class="time">11:36</a>
wwoodswe already *have* a proposed schedule. waiting until we achieve Total QA Enlightenment to decide whether or not it's a good schedule is not a good plan<a href="#t11:36" class="time">11:36</a>
f13the fact that we have Live images now makes it extremely easy fo rsomebody to test the latest snapshot without disurpting their install.<a href="#t11:36" class="time">11:36</a>
poelcatwwoods: yes, and we are trying to get to an *approved* schedule that we agree on :)<a href="#t11:38" class="time">11:38</a>
wwoodsf13: right. testing the milestones themselves is not useful<a href="#t11:38" class="time">11:38</a>
wwoodsthe function of the milestones is to give the developers a target to hit and users an easy way to install rawhide<a href="#t11:38" class="time">11:38</a>
wwoodsthe milestone itself is not an interesting test target<a href="#t11:38" class="time">11:38</a>
f13which is part of the reason why I want to do away with milestone entries in bugzilla versions<a href="#t11:39" class="time">11:39</a>
wwoodsthis is why I don't like having 'fNtestY' versions in bugzilla<a href="#t11:39" class="time">11:39</a>
wwoodsyes<a href="#t11:39" class="time">11:39</a>
f13there is value in knowing /when/ and /how/ a user jumped on the rawhide train<a href="#t11:39" class="time">11:39</a>
f13because a bug in the installer at Alpha can plague a user all the way through<a href="#t11:39" class="time">11:39</a>
wwoodsso here's what I've got for the schedule: call it PR, not RC. Drop snapshot 4. move final devel freeze back to Apr. 8 (or, perhaps, move it *and* the translation freeze back one week)<a href="#t11:40" class="time">11:40</a>
f13in my mockup schedule I mostly guessed about translation freeze<a href="#t11:41" class="time">11:41</a>
f13since we don't have a test3 anymore<a href="#t11:41" class="time">11:41</a>
f13I'd like their input on when the freeze should fall<a href="#t11:41" class="time">11:41</a>
f13gee, April 8, that's exactly 23 days from the release date, which is what I have listed in hte Overview (and what we did for Fedora 8)<a href="#t11:42" class="time">11:42</a>
f13and what I have in the DevelopmentChanges mock schedule.<a href="#t11:42" class="time">11:42</a>
wwoodsright, exactly. poelcat's got it at apr. 10<a href="#t11:42" class="time">11:42</a>
f13poelcat: why did you differ from that?<a href="#t11:42" class="time">11:42</a>
wwoodshe put all the dates on Thursdays.<a href="#t11:42" class="time">11:42</a>
f13...<a href="#t11:42" class="time">11:42</a>
poelcatwwoods: correct<a href="#t11:42" class="time">11:42</a>
f13ok, that's easily correctable.<a href="#t11:43" class="time">11:43</a>
wwoodsso, yeah, freezes go on tuesdays. that's a minor change though<a href="#t11:43" class="time">11:43</a>
wwoodsthe actual discussion question is: apr. 8 or apr. 1 for final freeze?<a href="#t11:43" class="time">11:43</a>
poelcatif it is easier to print it off and tear it apart and fax it to me go for it!<a href="#t11:43" class="time">11:43</a>
f13I'd prefer apr 8<a href="#t11:43" class="time">11:43</a>
wwoodswhy's that?<a href="#t11:44" class="time">11:44</a>
wwoodsjust to keep freeze time at a minimum?<a href="#t11:44" class="time">11:44</a>
poelcatwwoods: f13: how about if you summarize the changes you want in an email/fax and send them to me<a href="#t11:48" class="time">11:48</a>
poelcati'll refactor<a href="#t11:48" class="time">11:48</a>
poelcatand then we can see if things make more sense?<a href="#t11:48" class="time">11:48</a>
f13wwoods: yes, I think two weeks of only requested builds get in is plenty of time.<a href="#t11:48" class="time">11:48</a>
f13wwoods: especially if we A) stop giving things free rides, and B) have some sort of post-include verify test lined up<a href="#t11:49" class="time">11:49</a>
* poelcat has to prep for another meeting<a href="#t11:49" class="time">11:49</a>
f13poelcat: Ok, I"ll try to do that.  There is just a ton of data to consume :/<a href="#t11:49" class="time">11:49</a>
wwoodsyeah, I think the amount of freeze time we have could totally work, so long as we get more eyeballs on changes<a href="#t11:49" class="time">11:49</a>
poelcatf13 whatever is easiest... telephone if you like <a href="#t11:50" class="time">11:50</a>
wwoodsbut yeah, we'll send you changes. but seriously: Preview Release (or Release Preview? hmm...). Definitely not "Release Candidate"<a href="#t11:50" class="time">11:50</a>
poelcator we refactor it in stages... get one part right and then tweak the next parts in stages<a href="#t11:50" class="time">11:50</a>
wwoodsthere *will* be changes. calling it an RC would be deceptive.<a href="#t11:50" class="time">11:50</a>
poelcatthe taskjuggler file looks simple, but your're right it gets complicated<a href="#t11:51" class="time">11:51</a>
wwoodsPreview Release wins the google-off<a href="#t11:52" class="time">11:52</a>
wwoodsso yeah, PR1<a href="#t11:52" class="time">11:52</a>
poelcatwwoods: fair enough... then 2 days for the RC is cool?<a href="#t11:53" class="time">11:53</a>
wwoodswe went through 5 RCs in two days for this cycle<a href="#t11:54" class="time">11:54</a>
wwoods2 days is fine if we can keep it to a minimum number of respins<a href="#t11:55" class="time">11:55</a>
wwoodsfour respins is too many<a href="#t11:55" class="time">11:55</a>
poelcatso then should we add more time to make it reasonable?<a href="#t11:56" class="time">11:56</a>
f13ALso it's worth noting that not all RCs see the light of day<a href="#t11:56" class="time">11:56</a>
f13poelcat: I'll look at that part specifically<a href="#t11:56" class="time">11:56</a>
f13but I think what matters is what is the difference between a Preview Release and a Release Candidate.<a href="#t11:56" class="time">11:56</a>
poelcatf13: want me to call you later and we can go over the details?<a href="#t11:56" class="time">11:56</a>
* poelcat is really gone now<a href="#t11:56" class="time">11:56</a>
f13and at what point do we make the switch over, what action happens (or time happens) so that we now consider things release candidate worthy<a href="#t11:57" class="time">11:57</a>
f13poelcat: maybe, lets just catch up later.<a href="#t11:57" class="time">11:57</a>
wwoodswe always seem to have a sense for when These Are Probably The Final Bits Really For Serious<a href="#t11:57" class="time">11:57</a>
wwoodsspin, smoketest.. if that fails, respin, otherwise release. if the released RC gets nasty reports, respin, otherwise, final release.<a href="#t11:59" class="time">11:59</a>
wwoodsReally I need to define "smoketest"<a href="#t11:59" class="time">11:59</a>
wwoodsand automate it<a href="#t11:59" class="time">11:59</a>
f13wwoods: right, but I think it's mostly been time based.<a href="#t12:00" class="time">12:00</a>
f13as in, "Oh, it's wed, if we don't have a final tree today/tomorrow, we're slipping, so lets call this a release candidate and see what shakes out"<a href="#t12:00" class="time">12:00</a>
wwoodskind of? I mean we generally don't start calling stuff RCs unless we're fairly confident all remaining blockers are fixed (or have fixes incoming)<a href="#t12:03" class="time">12:03</a>

Generated by 2.3 by Marius Gedminas - find it at!