From Fedora Project Wiki
IRC Transcript
| wwoods | bah! fedora QA meeting will be delayed a bit (stupid DST) | <a href="#t09:57" class="time">09:57</a> |
|---|---|---|
| f13 | wwoods: lol | <a href="#t10:01" class="time">10:01</a> |
| wwoods | okay, QA meeting can start now. blerg! | <a href="#t10:33" class="time">10:33</a> |
| wwoods | I don't have a complex agenda for this one | <a href="#t10:34" class="time">10:34</a> |
| wwoods | basically all I'm concerned with right now is further filling out the test matrix | <a href="#t10:34" class="time">10:34</a> |
| skvidal | wwoods: so new blockers for f8 shouldn't be brought up? | <a href="#t10:35" class="time">10:35</a> |
| wwoods | you can't block f8 anymore | <a href="#t10:35" class="time">10:35</a> |
| wwoods | it's already done | <a href="#t10:35" class="time">10:35</a> |
| * skvidal was kidding | <a href="#t10:35" class="time">10:35</a> | |
| wwoods | but 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> |
| wwoods | e.g. yelp crashing on all searches (bug 361041) | <a href="#t10:36" class="time">10:36</a> |
| buggbot | Bug <a href="https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=361041">https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=361041</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> |
| wwoods | f13: do we have updates-testing populated now? | <a href="#t10:36" class="time">10:36</a> |
| wwoods | yelp 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> |
| f13 | wwoods: yes. | <a href="#t10:38" class="time">10:38</a> |
| f13 | wwoods: 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> |
| wwoods | is updates-testing a supplement to updates, or a replacement for it? | <a href="#t10:39" class="time">10:39</a> |
| f13 | supplement. | <a href="#t10:39" class="time">10:39</a> |
| wwoods | no broken deps right now | <a href="#t10:39" class="time">10:39</a> |
| wwoods | just that I can't pull yelp from koji by itself | <a href="#t10:39" class="time">10:39</a> |
| f13 | ah, right, I think lmacken fixed up the broken deps last night. | <a href="#t10:39" class="time">10:39</a> |
| wwoods | GRRRRR I hate that pup steals focus whenever it pops up a new window | <a href="#t10:40" class="time">10:40</a> |
| wwoods | I've cancelled this update 5 times during this meeting | <a href="#t10:40" class="time">10:40</a> |
| skvidal | wwoods: s/pup/evetything/ | <a href="#t10:40" class="time">10:40</a> |
| wwoods | it'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> |
| wwoods | but pup's status stuff should REALLY be just in the main window | <a href="#t10:40" class="time">10:40</a> |
| wwoods | it's weird how much I'm hoping PackageKit pans out | <a href="#t10:41" class="time">10:41</a> |
| lmacken | hehe | <a href="#t10:41" class="time">10:41</a> |
| wwoods | it 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> |
| wwoods | anyway. tangent. | <a href="#t10:42" class="time">10:42</a> |
| lmacken | that's the goal :) | <a href="#t10:42" class="time">10:42</a> |
| wwoods | so yeah we'll check for broken deps | <a href="#t10:42" class="time">10:42</a> |
| lmacken | yelp 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> |
| wwoods | oh 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> |
| lmacken | right | <a href="#t10:44" class="time">10:44</a> |
| wwoods | looks 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> |
| wwoods | so yeah, that's about all I had. | <a href="#t10:45" class="time">10:45</a> |
| wwoods | oh, I'm kind of worried about people getting PA set up properly | <a href="#t10:45" class="time">10:45</a> |
| lmacken | what does "setting it up properly" entail ? | <a href="#t10:46" class="time">10:46</a> |
| wwoods | that's the problem. | <a href="#t10:46" class="time">10:46</a> |
| wwoods | in theory, upgraders should just have to yum groupinstall sound-and-video | <a href="#t10:46" class="time">10:46</a> |
| wwoods | but I think there's some trickery with KDE | <a href="#t10:46" class="time">10:46</a> |
| wwoods | and 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> |
| wwoods | the docs aren't where I'd like 'em to be, basically | <a href="#t10:47" class="time">10:47</a> |
| wwoods | so 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> |
| wwoods | but 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> |
| wwoods | are there other things we expect to be doing a lot of hopeless triage on? | <a href="#t10:51" class="time">10:51</a> |
| wwoods | I'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> |
| ajax | suspend. | <a href="#t10:53" class="time">10:53</a> |
| wwoods | oh good god yeah | <a href="#t10:53" class="time">10:53</a> |
| wwoods | but we have some fairly good references (the quirks page) for that | <a href="#t10:54" class="time">10:54</a> |
| ajax | we'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> |
| ajax | but that's despair for another day | <a href="#t10:55" class="time">10:55</a> |
| wwoods | well, deep-down-terrible things like.. bad BIOS? deep-seated kernel bugs? | <a href="#t10:55" class="time">10:55</a> |
| wwoods | or just incomplete support for stuff (which is where I assume nvidia is) | <a href="#t10:55" class="time">10:55</a> |
| wwoods | oh god the nvidia/suspend thing. yeah. | <a href="#t10:56" class="time">10:56</a> |
| ajax | bios horrors and incomplete support, yeah. | <a href="#t10:56" class="time">10:56</a> |
| wwoods | well, 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> |
| wwoods | kind of | <a href="#t10:57" class="time">10:57</a> |
| wwoods | anyway, yeah, that's something to look out for but it's mostly listed on <a href="http://fedoraproject.org/wiki/Bugs/F8Common">http://fedoraproject.org/wiki/Bugs/F8Common</a> | <a href="#t10:58" class="time">10:58</a> |
| wwoods | okay, anything else? | <a href="#t10:59" class="time">10:59</a> |
| poelcat | weren't we going to talk about the testing schedule for F9? | <a href="#t11:00" class="time">11:00</a> |
| wwoods | right! I knew there was something. | <a href="#t11:02" class="time">11:02</a> |
| wwoods | <a href="http://fedoraproject.org/wiki/ReleaseEngineering/DevelopmentChangesProposal">http://fedoraproject.org/wiki/ReleaseEngineering/DevelopmentChangesProposal</a> was updated a bit | <a href="#t11:03" class="time">11:03</a> |
| f13 | actually | <a href="#t11:03" class="time">11:03</a> |
| f13 | you should look at... | <a href="#t11:03" class="time">11:03</a> |
| f13 | <a href="http://fedoraproject.org/wiki/ReleaseEngineering/Overview">http://fedoraproject.org/wiki/ReleaseEngineering/Overview</a> | <a href="#t11:03" class="time">11:03</a> |
| f13 | and try to figure out where you want to insert yourselves in that. | <a href="#t11:04" class="time">11:04</a> |
| f13 | the Overview is a bit more of a broad overview, above even the changes proposal | <a href="#t11:04" class="time">11:04</a> |
| wwoods | gotcha | <a href="#t11:04" class="time">11:04</a> |
| poelcat | i was hoping we could agree more on the testing slots here: <a href="http://poelstra.fedorapeople.org/schedules/f9/f9-tasks-overview.html">http://poelstra.fedorapeople.org/schedules/f9/f9-tasks-overview.html</a> | <a href="#t11:05" class="time">11:05</a> |
| wwoods | anyway, on further reflection, I think I have the following comments: | <a href="#t11:05" class="time">11:05</a> |
| wwoods | 1) "Preview Release" might be a better name than "Release Candidate" | <a href="#t11:05" class="time">11:05</a> |
| poelcat | and close on our discussion from last thurs aobut RC testing | <a href="#t11:05" class="time">11:05</a> |
| wwoods | 2) 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> |
| wwoods | but 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> |
| f13 | wwoods: 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> | |
| f13 | wwoods: I find it hard to say no to simple bugfixes in ancillary packages. | <a href="#t11:07" class="time">11:07</a> |
| poelcat | f13: why? | <a href="#t11:07" class="time">11:07</a> |
| wwoods | right, and I generally don't have a problem with those | <a href="#t11:07" class="time">11:07</a> |
| f13 | poelcat: 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> |
| f13 | poelcat: it just wasn't reproducable until specific scenarios were found, late in teh game. | <a href="#t11:08" class="time">11:08</a> |
| f13 | the 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> |
| f13 | poelcat: "why" what? | <a href="#t11:08" class="time">11:08</a> |
| wwoods | no 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> |
| wwoods | I'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> |
| poelcat | why 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> |
| wwoods | uhh. 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> |
| f13 | wwoods: 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> |
| f13 | in this case Dan was sleep deprived or something and stomped on some changes Jeremy did. | <a href="#t11:10" class="time">11:10</a> |
| f13 | and we didn't notice in time. | <a href="#t11:11" class="time">11:11</a> |
| poelcat | wwoods: what we GA should sit a little more and change less at the end | <a href="#t11:11" class="time">11:11</a> |
| wwoods | poelcat: we're not talking about that stage of the release right now | <a href="#t11:11" class="time">11:11</a> |
| poelcat | i think I'm in a minority on this view, that is okay :) | <a href="#t11:11" class="time">11:11</a> |
| jeremy | poelcat: if we do that, we just increase the amount available on day-0 | <a href="#t11:11" class="time">11:11</a> |
| f13 | to be fair, it /did/ change less | <a href="#t11:11" class="time">11:11</a> |
| f13 | and there is that. | <a href="#t11:11" class="time">11:11</a> |
| f13 | we already have a /huge/ amount of stuff piled up for 0-day | <a href="#t11:11" class="time">11:11</a> |
| wwoods | right | <a href="#t11:11" class="time">11:11</a> |
| wwoods | We're on a time-based release schedule that emphasizes rapid development | <a href="#t11:12" class="time">11:12</a> |
| poelcat | jeremy: to me that is a lesser problem than GOLD media that isn't as stable | <a href="#t11:12" class="time">11:12</a> |
| wwoods | furthermore we're a heavily developer-oriented distribution | <a href="#t11:12" class="time">11:12</a> |
| poelcat | wwoods: we say that all the time, but what do we base that on? | <a href="#t11:12" class="time">11:12</a> |
| ajax | the 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> |
| f13 | poelcat: the fact that we dropped features because they weren't done on time | <a href="#t11:13" class="time">11:13</a> |
| poelcat | we did ? :) | <a href="#t11:13" class="time">11:13</a> |
| f13 | I 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> |
| poelcat | okay, we dropped some :) | <a href="#t11:14" class="time">11:14</a> |
| wwoods | If 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> |
| poelcat | i'm not saying sit on them, I'm saying test them :) | <a href="#t11:14" class="time">11:14</a> |
| f13 | we'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> |
| wwoods | and then look at the average (and total) Upstream Involvement per distribution | <a href="#t11:14" class="time">11:14</a> |
| f13 | poelcat: 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> |
| wwoods | and I'd make serious bets that Fedora would be waaaay ahead of anything else | <a href="#t11:14" class="time">11:14</a> |
| f13 | poelcat: this causes "change" | <a href="#t11:15" class="time">11:15</a> |
| f13 | poelcat: 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> |
| f13 | poelcat: 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> |
| wwoods | the work will *always* expand to fill available testing time | <a href="#t11:16" class="time">11:16</a> |
| poelcat | f13: 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> |
| wwoods | because the amount of work you *could* do is *vast* | <a href="#t11:16" class="time">11:16</a> |
| poelcat | i wonder if it can be reduced, maybe I'm naive :) | <a href="#t11:16" class="time">11:16</a> |
| f13 | poelcat: 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> |
| wwoods | the solution is not to grow the freeze but to make the process more effective | <a href="#t11:16" class="time">11:16</a> |
| f13 | poelcat: 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> |
| f13 | we have 23 days, which actually becomes 16~ days to get bugfixes in | <a href="#t11:17" class="time">11:17</a> |
| f13 | which is more like 14 days, two weeks. | <a href="#t11:17" class="time">11:17</a> |
| f13 | so, 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> |
| f13 | indeed | <a href="#t11:19" class="time">11:19</a> |
| wwoods | we're already using 2/26 (call it 10%) of the cycle for the final change | <a href="#t11:19" class="time">11:19</a> |
| poelcat | so is 1.6.4 wrong here: <a href="http://poelstra.fedorapeople.org/schedules/f9/f9-tasks-overview.html">http://poelstra.fedorapeople.org/schedules/f9/f9-tasks-overview.html</a> | <a href="#t11:19" class="time">11:19</a> |
| wwoods | err final freeze | <a href="#t11:19" class="time">11:19</a> |
| poelcat | for starters then, how about if the schedule to reflects what our actual testing windows are | <a href="#t11:20" class="time">11:20</a> |
| poelcat | i think everyone has a different definition | <a href="#t11:21" class="time">11:21</a> |
| lmacken | f13: +1 for not letting selinux get a free ride | <a href="#t11:22" class="time">11:22</a> |
| wwoods | final freeze is currently ~3.5 weeks before release (1mo - 1wk) | <a href="#t11:22" class="time">11:22</a> |
| poelcat | wwoods: so what part of what I've proposed needs to be fixd? | <a href="#t11:23" class="time">11:23</a> |
| wwoods | s/Release Candidate/Release Preview/ | <a href="#t11:23" class="time">11:23</a> |
| f13 | what defines a "testing window" | <a href="#t11:24" class="time">11:24</a> |
| f13 | ? | <a href="#t11:24" class="time">11:24</a> |
| f13 | I 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> |
| wwoods | f13: the "Freezes" listed are shorter than what's listed | <a href="#t11:24" class="time">11:24</a> |
| wwoods | because one week of each freeze is consumed by compose -> mirrors | <a href="#t11:25" class="time">11:25</a> |
| wwoods | so a three week freeze gives us two weeks to test (at most) | <a href="#t11:25" class="time">11:25</a> |
| poelcat | f13: when want people to focus on testing alpha, beta, RC | <a href="#t11:25" class="time">11:25</a> |
| f13 | ok, so a test window for /that/ particular compose. | <a href="#t11:25" class="time">11:25</a> |
| wwoods | right | <a href="#t11:25" class="time">11:25</a> |
| wwoods | anyway 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> |
| wwoods | and then you've got beta = 5 weeks and then 4 weekly snapshot releases | <a href="#t11:27" class="time">11:27</a> |
| poelcat | i made everything land on thursdays | <a href="#t11:27" class="time">11:27</a> |
| poelcat | which is what we've traditionally (i believe) done | <a href="#t11:27" class="time">11:27</a> |
| f13 | Freezes are on Tuesday, releases on thursdays | <a href="#t11:27" class="time">11:27</a> |
| wwoods | then two weeks for PR1 | <a href="#t11:28" class="time">11:28</a> |
| f13 | We really should start freezing in the morning of Tuesday | <a href="#t11:28" class="time">11:28</a> |
| f13 | IE what was in rawhide the night before | <a href="#t11:28" class="time">11:28</a> |
| f13 | so that Tuesday's rawhide is a reasonable test case | <a href="#t11:28" class="time">11:28</a> |
| f13 | that 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> |
| f13 | since 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> |
| f13 | perhaps 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> |
| wwoods | this schedule also has "testing" *after* compose->sync->release | <a href="#t11:30" class="time">11:30</a> |
| poelcat | yes | <a href="#t11:30" class="time">11:30</a> |
| poelcat | testing the "alpha, beta, rc" | <a href="#t11:30" class="time">11:30</a> |
| wwoods | feh | <a href="#t11:30" class="time">11:30</a> |
| wwoods | they're rawhide snapshots | <a href="#t11:31" class="time">11:31</a> |
| wwoods | the 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> |
| wwoods | testing rawhide during the compose/stage/release is exactly as useful as testing the release itself | <a href="#t11:31" class="time">11:31</a> |
| poelcat | maybe I explain my thinking better here: <a href="http://poelcat.wordpress.com/2007/10/29/quality-from-more-than-milestones/">http://poelcat.wordpress.com/2007/10/29/quality-from-more-than-milestones/</a> | <a href="#t11:32" class="time">11:32</a> |
| poelcat | i don't think we can engage more people by thinking in terms of "rawhide" | <a href="#t11:33" class="time">11:33</a> |
| wwoods | this 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> |
| poelcat | so why not try to make it more accessible to them? | <a href="#t11:33" class="time">11:33</a> |
| f13 | wwoods: 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> |
| f13 | in the past, test releases were mostly used to test installer code paths for media installs | <a href="#t11:34" class="time">11:34</a> |
| f13 | since we don't make media each night | <a href="#t11:34" class="time">11:34</a> |
| wwoods | we're getting onto a tangent about the purpose of our testing | <a href="#t11:35" class="time">11:35</a> |
| wwoods | that's not something I want to start right now | <a href="#t11:35" class="time">11:35</a> |
| poelcat | if we don't know what our purpose is how can we plan the schedule? | <a href="#t11:35" class="time">11:35</a> |
| f13 | simply put | <a href="#t11:35" class="time">11:35</a> |
| f13 | the purpose is to provide users with a known good jump off point. | <a href="#t11:36" class="time">11:36</a> |
| f13 | they 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> |
| poelcat | that makes sense | <a href="#t11:36" class="time">11:36</a> |
| f13 | almost 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> |
| wwoods | we 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> |
| f13 | the 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> |
| poelcat | wwoods: yes, and we are trying to get to an *approved* schedule that we agree on :) | <a href="#t11:38" class="time">11:38</a> |
| wwoods | f13: right. testing the milestones themselves is not useful | <a href="#t11:38" class="time">11:38</a> |
| wwoods | the 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> |
| wwoods | the milestone itself is not an interesting test target | <a href="#t11:38" class="time">11:38</a> |
| f13 | which 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> |
| wwoods | this is why I don't like having 'fNtestY' versions in bugzilla | <a href="#t11:39" class="time">11:39</a> |
| wwoods | yes | <a href="#t11:39" class="time">11:39</a> |
| f13 | there is value in knowing /when/ and /how/ a user jumped on the rawhide train | <a href="#t11:39" class="time">11:39</a> |
| f13 | because a bug in the installer at Alpha can plague a user all the way through | <a href="#t11:39" class="time">11:39</a> |
| wwoods | so 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> |
| f13 | in my mockup schedule I mostly guessed about translation freeze | <a href="#t11:41" class="time">11:41</a> |
| f13 | since we don't have a test3 anymore | <a href="#t11:41" class="time">11:41</a> |
| f13 | I'd like their input on when the freeze should fall | <a href="#t11:41" class="time">11:41</a> |
| f13 | gee, 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> |
| f13 | and what I have in the DevelopmentChanges mock schedule. | <a href="#t11:42" class="time">11:42</a> |
| wwoods | right, exactly. poelcat's got it at apr. 10 | <a href="#t11:42" class="time">11:42</a> |
| f13 | poelcat: why did you differ from that? | <a href="#t11:42" class="time">11:42</a> |
| wwoods | he 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> |
| poelcat | wwoods: correct | <a href="#t11:42" class="time">11:42</a> |
| f13 | ok, that's easily correctable. | <a href="#t11:43" class="time">11:43</a> |
| wwoods | so, yeah, freezes go on tuesdays. that's a minor change though | <a href="#t11:43" class="time">11:43</a> |
| wwoods | the actual discussion question is: apr. 8 or apr. 1 for final freeze? | <a href="#t11:43" class="time">11:43</a> |
| poelcat | if 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> |
| f13 | I'd prefer apr 8 | <a href="#t11:43" class="time">11:43</a> |
| wwoods | why's that? | <a href="#t11:44" class="time">11:44</a> |
| wwoods | just to keep freeze time at a minimum? | <a href="#t11:44" class="time">11:44</a> |
| poelcat | wwoods: 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> |
| poelcat | i'll refactor | <a href="#t11:48" class="time">11:48</a> |
| poelcat | and then we can see if things make more sense? | <a href="#t11:48" class="time">11:48</a> |
| f13 | wwoods: yes, I think two weeks of only requested builds get in is plenty of time. | <a href="#t11:48" class="time">11:48</a> |
| f13 | wwoods: 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> | |
| f13 | poelcat: 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> |
| wwoods | yeah, 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> |
| poelcat | f13 whatever is easiest... telephone if you like | <a href="#t11:50" class="time">11:50</a> |
| wwoods | but 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> |
| poelcat | or 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> |
| wwoods | there *will* be changes. calling it an RC would be deceptive. | <a href="#t11:50" class="time">11:50</a> |
| poelcat | the taskjuggler file looks simple, but your're right it gets complicated | <a href="#t11:51" class="time">11:51</a> |
| wwoods | Preview Release wins the google-off | <a href="#t11:52" class="time">11:52</a> |
| wwoods | so yeah, PR1 | <a href="#t11:52" class="time">11:52</a> |
| poelcat | wwoods: fair enough... then 2 days for the RC is cool? | <a href="#t11:53" class="time">11:53</a> |
| wwoods | we went through 5 RCs in two days for this cycle | <a href="#t11:54" class="time">11:54</a> |
| wwoods | 2 days is fine if we can keep it to a minimum number of respins | <a href="#t11:55" class="time">11:55</a> |
| wwoods | four respins is too many | <a href="#t11:55" class="time">11:55</a> |
| poelcat | so then should we add more time to make it reasonable? | <a href="#t11:56" class="time">11:56</a> |
| f13 | ALso it's worth noting that not all RCs see the light of day | <a href="#t11:56" class="time">11:56</a> |
| f13 | poelcat: I'll look at that part specifically | <a href="#t11:56" class="time">11:56</a> |
| f13 | but 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> |
| poelcat | f13: 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> | |
| f13 | and 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> |
| f13 | poelcat: maybe, lets just catch up later. | <a href="#t11:57" class="time">11:57</a> |
| wwoods | we 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> |
| wwoods | spin, 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> |
| wwoods | Really I need to define "smoketest" | <a href="#t11:59" class="time">11:59</a> |
| wwoods | and automate it | <a href="#t11:59" class="time">11:59</a> |
| f13 | wwoods: right, but I think it's mostly been time based. | <a href="#t12:00" class="time">12:00</a> |
| f13 | as 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> |
| wwoods | kind 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 irclog2html.py 2.3 by Marius Gedminas - find it at mg.pov.lt!