QA/Meetings/20071107

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!