ReleaseEngineering/Meetings/2008-apr-07

From FedoraProject

Jump to: navigation, search

Fedora Release Engineering Meeting :: Monday 2008-04-07

Fedora 9 Readiness

  • Final freeze on Tuesday, April 8, 2008
  • Internet2 issue could affect ability to feed mirrors at F9 GA
  • Ongoing review of blocker bugs until GA


IRC Transcript

f13ping: notting jeremy jwb wwoods warren lmacken poelcat rdieter<a href="#t13:01" class="time">13:01</a>
* poelcat here<a href="#t13:02" class="time">13:02</a>
f13(wwoods is out)<a href="#t13:02" class="time">13:02</a>
* notting is here<a href="#t13:02" class="time">13:02</a>
* jwb is here<a href="#t13:02" class="time">13:02</a>
* lmacken is here<a href="#t13:02" class="time">13:02</a>
* warren here<a href="#t13:02" class="time">13:02</a>
f13aight, lets get started.<a href="#t13:03" class="time">13:03</a>
-!- f13 changed the topic of #fedora-meeting to: Fedora Release Engineering Meeting - Fedora 9 Final Freeze<a href="#t13:03" class="time">13:03</a>
f13The final freeze is tomorrow, and as usual I'm going to setup an at job to throw the switch tonight so tomorrow's rawhide is the frozen content.<a href="#t13:03" class="time">13:03</a>
f13I've got f9-final tag in koji already, and I'm updating it with the latest builds from dist-f9<a href="#t13:04" class="time">13:04</a>
nottingwe're having an early tuesday freeze, not a late tuesday freeze?<a href="#t13:04" class="time">13:04</a>
f13I'm going to start signing tonight too, if the clone finishes in time.<a href="#t13:04" class="time">13:04</a>
f13notting: yeah, we did that for Alpha and Beta<a href="#t13:04" class="time">13:04</a>
f13gives releng an extra day of testing<a href="#t13:04" class="time">13:04</a>
warrenhow are we feeling about the stability of rawhide?  I had some worrying crashes during the weekend (no compiz involved)<a href="#t13:04" class="time">13:04</a>
f13warren: I'm not "happy" but I'm not slitting my wrists yet.<a href="#t13:05" class="time">13:05</a>
poelcattoday's rawhide was good for me <a href="http://fedoraproject.org/wiki/JohnPoelstra/RawhideToday">http://fedoraproject.org/wiki/JohnPoelstra/RawhideToday</a><a href="#t13:05" class="time">13:05</a>
jwbrawhide has been fine for me since beta<a href="#t13:05" class="time">13:05</a>
jwbwith the exception of hibernate<a href="#t13:06" class="time">13:06</a>
jlaskawarren: I think it largely depends on what components you're interested in<a href="#t13:06" class="time">13:06</a>
f13Well, I triggered a blocker bug this morning in anaconda, so that's lame for me<a href="#t13:06" class="time">13:06</a>
f13and I still have to plow through this upgrade stuff.<a href="#t13:06" class="time">13:06</a>
warrenjlaska: oh nothing important, just dbus-daemon crashing, X deadlocking, and kernel oopsing<a href="#t13:07" class="time">13:07</a>
f13upgrades in general are scary.<a href="#t13:07" class="time">13:07</a>
jwbf13, what upgrade stuff?<a href="#t13:07" class="time">13:07</a>
jlaskadetails details ;)<a href="#t13:07" class="time">13:07</a>
f13jwb: finding things that went from multilib to not multilib and getting them blacklisted correctly in anaconda<a href="#t13:07" class="time">13:07</a>
jwbah<a href="#t13:07" class="time">13:07</a>
f13jwb: plus finding other upgrade gotchas.<a href="#t13:07" class="time">13:07</a>
nottingi am concerned about our ability to deliver the preview, in light of mdomsch's discussion about final<a href="#t13:07" class="time">13:07</a>
f13there are a number of upgrade related bugs on teh blocker list.<a href="#t13:07" class="time">13:07</a>
jwbnotting, wait... what?<a href="#t13:07" class="time">13:07</a>
f13notting: preview is just going ot be torrent only<a href="#t13:07" class="time">13:07</a>
nottingah, ok<a href="#t13:07" class="time">13:07</a>
jlaskaf13: so dumb question ... once we freeze, the plan is then to widdle down the blocker bug list?<a href="#t13:07" class="time">13:07</a>
nottingdoom postponed!<a href="#t13:08" class="time">13:08</a>
f13notting: it's like the regularly scheduled snapshot, just with a differen tname.<a href="#t13:08" class="time">13:08</a>
nottingok. i remain concerned about final, though. yuck.<a href="#t13:08" class="time">13:08</a>
f13jlaska: yeah, I think each day we'll probably trim a bit more off the blocker list, and get more toward "we'd actually slip the release for this"<a href="#t13:08" class="time">13:08</a>
* rdieter here (a little)<a href="#t13:08" class="time">13:08</a>
f13notting: as do I.<a href="#t13:08" class="time">13:08</a>
f13for those not in the "know"<a href="#t13:08" class="time">13:08</a>
poelcatf13: how will we test out jigdo before GA?<a href="#t13:08" class="time">13:08</a>
f13RH can't currently deliver any content over Internet2 to anybody<a href="#t13:08" class="time">13:08</a>
f13which means our I2 mirrors get way behind<a href="#t13:09" class="time">13:09</a>
warrenAl Gore didn't invent it yet.<a href="#t13:09" class="time">13:09</a>
jwboh<a href="#t13:09" class="time">13:09</a>
f13and all have ot use phx resources to get content, which is causing resource contention<a href="#t13:09" class="time">13:09</a>
* jds2001 sits in the back<a href="#t13:09" class="time">13:09</a>
f13resources which are supposed to be shut off for releases due to not wanting to knock redhat.com off the internet again<a href="#t13:09" class="time">13:09</a>
f13poelcat: I'm thinking of testing it by hand a bit with some custom mirrormanager urls that I'll ask mdomsch to create for me.<a href="#t13:10" class="time">13:10</a>
nottingdo we have everything in place needed for preupgrade?<a href="#t13:10" class="time">13:10</a>
poelcatf13: let me know if you want some help from a 'home user' :)<a href="#t13:10" class="time">13:10</a>
f13notting: I have no idea on that front.  I think we're awefully late to be landing "features" such as that.<a href="#t13:10" class="time">13:10</a>
f13poelcat: will do, likely the mirrormanager url will just reference rawhide<a href="#t13:11" class="time">13:11</a>
f13Part of the final freeze is also the mass CVS branching<a href="#t13:12" class="time">13:12</a>
f13I'm not entirely sure why the schedule has it on the 9th, I probably asked for it and promptly forgot why<a href="#t13:12" class="time">13:12</a>
f13but abadger1999 needs some time to try and recover some optimizations on the pkgdb/fas side of things to make the branching go faster.<a href="#t13:13" class="time">13:13</a>
f13it's still probbaly going to require a cvs outage, and a mail shutoff to keep from mailbombing everybody<a href="#t13:13" class="time">13:13</a>
abadger1999also note, I think the pure cvs side of things has slowed down as well.<a href="#t13:14" class="time">13:14</a>
jwbf13, maybe you were still thinking it was going to be a late tues freeze, so you wanted it on the 9th?<a href="#t13:14" class="time">13:14</a>
f13I had a script at one point to do it, but that was pre fas2, and some other things have changed on pkgdb side, so I'll likely have to rewrite the script.<a href="#t13:14" class="time">13:14</a>
f13jwb: could be.<a href="#t13:14" class="time">13:14</a>
nottingabadger1999: it's not like modules ever gets *smaller*<a href="#t13:14" class="time">13:14</a>
abadger1999Right.<a href="#t13:14" class="time">13:14</a>
f13abadger1999: curious, if the cvs slowdown is the ACL lookup + the "whom do I mail" lookup<a href="#t13:14" class="time">13:14</a>
f13which I would think with an outage we could kill both of those<a href="#t13:15" class="time">13:15</a>
abadger1999Esp. the whom do I mail would speed things up.<a href="#t13:16" class="time">13:16</a>
* abadger1999 writes a note to disable getnotifylist<a href="#t13:16" class="time">13:16</a>
warrenabadger1999: if we have a cvs outage, might we use that as an opportunity to finally rename cvsextras?<a href="#t13:16" class="time">13:16</a>
abadger1999warren: You and f13 should work it out.  I can make it happen whenever everyone wants it.<a href="#t13:17" class="time">13:17</a>
warrenf13: any preference?<a href="#t13:18" class="time">13:18</a>
f13warren: do you have a list of changes that would require?  Maybe an open infrastructure ticket?  noted which wiki pages need updating, etc..?<a href="#t13:19" class="time">13:19</a>
f13I wouldn't be so keen on breaking cvs at the critical point in our release.  Much more comfortable doing it post-f9<a href="#t13:19" class="time">13:19</a>
warrenyeah, that might be a better idea<a href="#t13:21" class="time">13:21</a>
f13I'm going to be flipping the fedora-release bit to make it look like F9, as well as turning off rawhide and on the "fedora" and "updates" repos.  We'll pull a mirrormanager trick again and just have those redirect to rawhide.<a href="#t13:21" class="time">13:21</a>
f13(which should aide in testing out jigdo prior to release day)<a href="#t13:22" class="time">13:22</a>
warrencool<a href="#t13:22" class="time">13:22</a>
warrenperfect<a href="#t13:22" class="time">13:22</a>
f13and the rest of the time is just losing sleep over blocker lists.<a href="#t13:22" class="time">13:22</a>
f13So, open floor on F9 Final issues.<a href="#t13:22" class="time">13:22</a>
nottingif we can't push it, we can't ship it.<a href="#t13:23" class="time">13:23</a>
f13yep<a href="#t13:23" class="time">13:23</a>
f13I'm probably going to harass people daily about this<a href="#t13:23" class="time">13:23</a>
nottingfor F7 EOL, do we want to pick a date now, or wait until we're a little more clear on the panic/don't panic state of the blocker list?<a href="#t13:24" class="time">13:24</a>
f13I'd say panic/don't panic.<a href="#t13:25" class="time">13:25</a>
f13wait until we have a real RC<a href="#t13:25" class="time">13:25</a>
warrenDo we consider the upstart fails to shutdown, upstart causing always/frequent unclean unmount issues, possibly related runlevel changes do nothing... blockers?<a href="#t13:25" class="time">13:25</a>
nottingwarren: the hell?<a href="#t13:25" class="time">13:25</a>
f13warren: have you been able to find anybody else who sees this?<a href="#t13:26" class="time">13:26</a>
nottingplease elaborate on your first and second comments with bug numbers<a href="#t13:26" class="time">13:26</a>
warrenreally nobody else is seeing this? wow.<a href="#t13:26" class="time">13:26</a>
poelcatrelated to that F7 EOL and the recent ______ on f-dev-list about those darn BugZappers<a href="#t13:26" class="time">13:26</a>
poelcatare there any compelling reasons to keep EOL bugs open?<a href="#t13:27" class="time">13:27</a>
poelcatsomeone shut me down if this is too much of a tangent for this meeting :)<a href="#t13:27" class="time">13:27</a>
f13poelcat: well, the answer to that question is always "yes", but the real question is 'compelling enough to put up with the cruft' and that I think is no.<a href="#t13:27" class="time">13:27</a>
nottingpoelcat: only on an individual reporter/maintainer's opinion on specific bugs<a href="#t13:27" class="time">13:27</a>
warren<a href="https://bugzilla.redhat.com/show_bug.cgi?id=438444">https://bugzilla.redhat.com/show_bug.cgi?id=438444</a> switching to runlevel 1 does nothing <a href="https://bugzilla.redhat.com/show_bug.cgi?id=439699">https://bugzilla.redhat.com/show_bug.cgi?id=439699</a> you see nothing during shutdown (and sometimes it fails to shutdown)  <a href="https://bugzilla.redhat.com/show_bug.cgi?id=438449">https://bugzilla.redhat.com/show_bug.cgi?id=438449</a> killall race (might possibly related)<a href="#t13:27" class="time">13:27</a>
buggbotBug 438444: high, low, ---, Casey Dahlin, NEW , upstart - 'telinit 1' is not doing anything even close to advertised<a href="#t13:27" class="time">13:27</a>
buggbotBug 439699: low, low, ---, Casey Dahlin, NEW , No shutdown msgs displayed<a href="#t13:27" class="time">13:27</a>
buggbotBug 438449: low, low, ---, Casey Dahlin, NEW , /etc/rc.d/init.d/killall is racing with other "stops"<a href="#t13:27" class="time">13:27</a>
warrenI've personally NEVER seen my filesystem not replay journal since we've switched to upstart<a href="#t13:27" class="time">13:27</a>
nottingpoelcat: does the bugzappers/triage stuff have an ability to only prod bugs once?<a href="#t13:27" class="time">13:27</a>
nottingdid you file a bug?<a href="#t13:28" class="time">13:28</a>
poelcatnotting: sortof... we've got that c00l whiteboard tag ;-)<a href="#t13:28" class="time">13:28</a>
warrenwell, been relying on the existing bugs.<a href="#t13:28" class="time">13:28</a>
nottingwarren: none of those bugs have anything to do with journal replay<a href="#t13:28" class="time">13:28</a>
warrennotting: if it fails to cleanly shutdown it might?<a href="#t13:29" class="time">13:29</a>
nottingwarren: presumably you'd notice that , considering you'd have to hit the power key, etc.<a href="#t13:29" class="time">13:29</a>
warrennotting: it is inconsistent, but sometimes it powers off very quickly after I hit Shutdown<a href="#t13:30" class="time">13:30</a>
poelcatnotting: so you're saying some way for a developmer to tag a bug as "don't auto close me" ?<a href="#t13:30" class="time">13:30</a>
warrensometimes I do have to hold down the power button because X died, I haven no login getty's, and it is just stuck<a href="#t13:30" class="time">13:30</a>
nottingpoelcat: i mean, once the triage system flags needinfo/whatever, i think it shouldn't try and do it *again* the next time it's chugging through rawhide<a href="#t13:30" class="time">13:30</a>
jds2001well rawhide will be re-based to F9<a href="#t13:31" class="time">13:31</a>
poelcatnotting: well it shouldn't because the next action would be to ignore it or CLOSE if still needinfo<a href="#t13:31" class="time">13:31</a>
nottingpoelcat: and if it's moved to 'devel' again...?<a href="#t13:32" class="time">13:32</a>
warrenin rare occasions I do actually see stuff shutting down<a href="#t13:32" class="time">13:32</a>
poelcatnotting: then it stays in 'rawhide' until the next GA when it gets rebased to the GA version<a href="#t13:32" class="time">13:32</a>
jds2001it'll get put in the frying pan for the next cycle i think.<a href="#t13:32" class="time">13:32</a>
jds2001poelcat: +1<a href="#t13:32" class="time">13:32</a>
nottingpoelcat: right. that's what i mean about only frobbing the bug once<a href="#t13:32" class="time">13:32</a>
jds2001hmm, is there a compelling reason not to every 6 months?<a href="#t13:33" class="time">13:33</a>
nottingnot sure. i suppose we can see how it plays out<a href="#t13:33" class="time">13:33</a>
nottingi suppose my bigger triage concern is 'only one message per bug plz' :)<a href="#t13:34" class="time">13:34</a>
f13seems like we're drifting here.<a href="#t13:34" class="time">13:34</a>
jds2001yeah, sorry bout that :(<a href="#t13:34" class="time">13:34</a>
-!- f13 changed the topic of #fedora-meeting to: Fedora Release Engineering - Open Floor<a href="#t13:34" class="time">13:34</a>
nottingf13: apologies.<a href="#t13:34" class="time">13:34</a>
nottinglmacken: bodhi need any prep for f9?<a href="#t13:36" class="time">13:36</a>
lmackennotting: I don't believe so<a href="#t13:37" class="time">13:37</a>
lmackenwhen do we want to start queueing up updates ?<a href="#t13:37" class="time">13:37</a>
f13our sync scripts probably need updates<a href="#t13:37" class="time">13:37</a>
lmackenI can create the F9 release in bodhi at any time, and keep it locked<a href="#t13:37" class="time">13:37</a>
f13lets wait until we've branched<a href="#t13:38" class="time">13:38</a>
poelcatf13: similar question for bug triage... when should we rebase rawhide-->f9 ?<a href="#t13:38" class="time">13:38</a>
poelcator should I ask this somewhere else?<a href="#t13:39" class="time">13:39</a>
f13poelcat: probably elsewhere, but I'd say after we start shipping F10 content in rawhide.<a href="#t13:40" class="time">13:40</a>
f13which would be after F9 goes gold.<a href="#t13:40" class="time">13:40</a>
poelcatf13: okay thanks<a href="#t13:42" class="time">13:42</a>
f13if there's nothing else, I'd like to wrap up and get back to work.<a href="#t13:43" class="time">13:43</a>
warrennod<a href="#t13:44" class="time">13:44</a>
* warren looking into upstart issues...<a href="#t13:44" class="time">13:44</a>
f13thanks all!<a href="#t13:45" class="time">13:45</a>

Generated by irclog2html.py 2.3 by Marius Gedminas - find it at mg.pov.lt!