From Fedora Project Wiki

< QA‎ | Meetings

(hack up an 0409 meeting page)
 
(fix up irc log (weird))
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
= Attendees =
= Attendees =
* adamw (153)
* VICODAN2 (111)
* tflink (36)
* nirik (22)
* brunowolff (13)
* Martix (12)
* jreznik (12)
* Viking-Ice (8)
* Cerlyn (7)
* robatino (5)
* zodbot (3)
* rbergeron (3)
* rdieter (1)
* satellit_ (1)


= Agenda =
= Agenda =
Line 13: Line 27:
== Fedora 17 Beta status / blocker review ==
== Fedora 17 Beta status / blocker review ==
* [[Current_Release_Blockers]]
* [[Current_Release_Blockers]]
* Need to spin RC4 ASAP: blockers remain in anaconda/preupgrade and selinux
* Need to spin RC4 ASAP: blockers remained in anaconda/preupgrade and selinux
* [[rhbug:809707|#809707]] was rejected as a beta blocker as we can only think of very few cases which will be hit by it, and there is an obvious 'workaround' (really, the fix): correct the system date


== Test Day report ==
== Test Day report ==
* [[Test_Day:2012-04-04_Power_Management|Power Management Test Day on 04-04]]
* Turnout for the [[Test_Day:2012-04-04_Power_Management|Power Management Test Day on 04-04]] was good, looks like a solid bunch of results. It was open house in Brno, so a lot of input came from that
* [[Test_Day:2012-04-05_L10n_I18n_Installation|Installation l10n/i18n Test Day on 04-05]]
* Seems to have been solid data in the [[Test_Day:2012-04-05_L10n_I18n_Installation|Installation l10n/i18n Test Day on 04-05]] but the results table is a little odd, may need tidying up


== Upcoming QA events ==
== Upcoming QA events ==
* [[Test_Day:2012-04-10_KDE_4.8|KDE 4.8 Test Day tomorrow (04-10)]] - KDE team is on top of preparation
* [[Test_Day:2012-04-12_Virtualization_Test_Day|Virtualization Test Day 04-12]] - virt team is taking a freeform testing approach, looks like they have the page set up as they want it
* Beta Go/No-Go scheduled (again) for 04-11
* Beta Go/No-Go scheduled (again) for 04-11


== AutoQA update ==
== AutoQA update ==
* No news, once more


== Open floor ==
== Open floor ==
* Some discussion of whether preupgrade bugs should block media spins: adam to propose changes on the list
* Andre noted that mediacheck is now 'hidden' and should be exposed or enabled by default: see [[rhbug:809663|#809663]]
== Action items ==
* adamw to send formal proposal for preupgrade criteria adjustment to the list


== IRC Log ==
== IRC Log ==
{|
|- id="t15:00:07"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #startmeeting Fedora QA meeting
|| [[#t15:00:07|15:00]]
|- id="t15:00:07"
! style="background-color: #42427e" | zodbot
| style="color: #42427e" | Meeting started Mon Apr  9 15:00:07 2012 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
|| [[#t15:00:07|15:00]]
|- id="t15:00:07"
! style="background-color: #42427e" | zodbot
| style="color: #42427e" | Useful Commands: #action #agreed #halp #info #idea #link #topic.
|| [[#t15:00:07|15:00]]
|- id="t15:00:11"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #meetingname fedora-qa
|| [[#t15:00:11|15:00]]
|- id="t15:00:11"
! style="background-color: #42427e" | zodbot
| style="color: #42427e" | The meeting name has been set to 'fedora-qa'
|| [[#t15:00:11|15:00]]
|- id="t15:00:20"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #topic roll call
|| [[#t15:00:20|15:00]]
|- id="t15:00:27"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | well hey, it appears to be meeting time again.
|| [[#t15:00:27|15:00]]
|- id="t15:00:43"
! style="background-color: #818144" | tflink
| style="color: #818144" | it does indeed
|| [[#t15:00:43|15:00]]
|- id="t15:01:20"
| colspan="2" | * tflink thinks the attendance is going to be a bit light today
|| [[#t15:01:20|15:01]]
|- id="t15:01:46"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | likely
|| [[#t15:01:46|15:01]]
|- id="t15:01:50"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | who's around? come crawl out of the woodwork
|| [[#t15:01:50|15:01]]
|- id="t15:02:04"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | if it's just me and you we may as well cancel
|| [[#t15:02:04|15:02]]
|- id="t15:02:08"
| colspan="2" | * Cerlyn is here
|| [[#t15:02:08|15:02]]
|- id="t15:02:48"
| colspan="2" | * brunowolff is here
|| [[#t15:02:48|15:02]]
|- id="t15:03:02"
| colspan="2" | * nirik is lurking around as always
|| [[#t15:03:02|15:03]]
|- id="t15:03:41"
| colspan="2" | * satellit_ listening
|| [[#t15:03:41|15:03]]
|- id="t15:03:56"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | ooh, the woodwork is positively slithering, it appears.
|| [[#t15:03:56|15:03]]
|- id="t15:05:12"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | HI
|| [[#t15:05:12|15:05]]
|- id="t15:05:28"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | hi dan.
|| [[#t15:05:28|15:05]]
|- id="t15:05:34"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | how goes it?
|| [[#t15:05:34|15:05]]
|- id="t15:05:34"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | so, we don't have anything from last week that i can think of
|| [[#t15:05:34|15:05]]
|- id="t15:05:39"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | i just woke up
|| [[#t15:05:39|15:05]]
|- id="t15:05:43"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | anyone else think of anything to follow up on?
|| [[#t15:05:43|15:05]]
|- id="t15:06:15"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | probably nothing i can offer that hasn't been talked about already
|| [[#t15:06:15|15:06]]
|- id="t15:06:25"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | i installed RC3 yesterday on a VM
|| [[#t15:06:25|15:06]]
|- id="t15:06:42"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | okay, let's skip previous meeting follow-up then
|| [[#t15:06:42|15:06]]
|- id="t15:07:03"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #topic Fedora 17 Beta status / blocker review
|| [[#t15:07:03|15:07]]
|- id="t15:07:27"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | so, not looking great here, we have no rc4 and still two open blockers, it seems. unless i missed something this morning.
|| [[#t15:07:27|15:07]]
|- id="t15:07:40"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | nope sounds about right
|| [[#t15:07:40|15:07]]
|- id="t15:07:44"
| colspan="2" | * Viking-Ice sneaks in
|| [[#t15:07:44|15:07]]
|- id="t15:08:06"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | anyone heard anything from mgrepl or wwoods through any side channels?
|| [[#t15:08:06|15:08]]
|- id="t15:08:28"
! style="background-color: #818144" | tflink
| style="color: #818144" | nope
|| [[#t15:08:28|15:08]]
|- id="t15:08:33"
! style="background-color: #488888" | brunowolff
| style="color: #488888" | I saw a bunch of updates did get pulled in to F17 stable over the weekend.
|| [[#t15:08:33|15:08]]
|- id="t15:08:43"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | that was the gnome 3.4 update.
|| [[#t15:08:43|15:08]]
|- id="t15:09:38"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | the login screen still shows the sql server login
|| [[#t15:09:38|15:09]]
|- id="t15:10:03"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | brunowolff: yeah, we're tidying up the stuff from rc3.
|| [[#t15:10:03|15:10]]
|- id="t15:10:27"
! style="background-color: #488888" | brunowolff
| style="color: #488888" | It looks like today's compose failed. Though it's kind of an odd looking error.
|| [[#t15:10:27|15:10]]
|- id="t15:10:30"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | VICODAN2: that one's not a beta blocker. think desktop team was bikeshedding it, but it should be gone for final one way or another, i guess.
|| [[#t15:10:30|15:10]]
|- id="t15:11:01"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | yea i'd like to have a word with them
|| [[#t15:11:01|15:11]]
|- id="t15:11:49"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | oh
|| [[#t15:11:49|15:11]]
|- id="t15:11:56"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | package dependencies seems to be fixed
|| [[#t15:11:56|15:11]]
|- id="t15:12:16"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | no more problems when running yum update after installing a bunch of packages with customize now
|| [[#t15:12:16|15:12]]
|- id="t15:12:44"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | i did have to install twice yesterday, but im going to blame virtualbox on that
|| [[#t15:12:44|15:12]]
|- id="t15:12:48"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | so, basically, seems we need to get out the pokey sticks and start poking mgrepl and wwoods. not a whole lot we can do till then.
|| [[#t15:12:48|15:12]]
|- id="t15:12:58"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | nope
|| [[#t15:12:58|15:12]]
|- id="t15:13:04"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | rbergeron: have you been performing official pokeage?
|| [[#t15:13:04|15:13]]
|- id="t15:14:40"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | maybe hes poking them now
|| [[#t15:14:40|15:14]]
|- id="t15:15:22"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | she
|| [[#t15:15:22|15:15]]
|- id="t15:16:01"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | she's been idle for 20 mins
|| [[#t15:16:01|15:16]]
|- id="t15:16:38"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | oh, well.
|| [[#t15:16:38|15:16]]
|- id="t15:16:47"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | tflink: we don't have any blockers to review, right?
|| [[#t15:16:47|15:16]]
|- id="t15:16:56"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | oh, hey, we do have one new one.
|| [[#t15:16:56|15:16]]
|- id="t15:17:10"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | the other two proposed are already discussed, i just didn't secretaryize from friday yet, my bad.
|| [[#t15:17:10|15:17]]
|- id="t15:17:23"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #topic Beta blocker review: http://bugzilla.redhat.com/show_bug.cgi?id=809707
|| [[#t15:17:23|15:17]]
|- id="t15:18:56"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | LOL
|| [[#t15:18:56|15:18]]
|- id="t15:19:06"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | this sounds worse reading through it than it does from the summary...
|| [[#t15:19:06|15:19]]
|- id="t15:19:09"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | this is not a blocker
|| [[#t15:19:09|15:19]]
|- id="t15:19:13"
! style="background-color: #4b904b" | Viking-Ice
| style="color: #4b904b" | Do we have any "date" criteria
|| [[#t15:19:13|15:19]]
|- id="t15:19:25"
! style="background-color: #4b904b" | Viking-Ice
| style="color: #4b904b" | if not then not a blocker just regular bug
|| [[#t15:19:25|15:19]]
|- id="t15:19:47"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | this is lamer than the y2k bug
|| [[#t15:19:47|15:19]]
|- id="t15:19:56"
! style="background-color: #4d4d93" | Cerlyn
| style="color: #4d4d93" | it's a failure to boot due to the RTC not being correct
|| [[#t15:19:56|15:19]]
|- id="t15:19:59"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | yeah.
|| [[#t15:19:59|15:19]]
|- id="t15:20:32"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | that's the problem: if you have system date earlier than 2012-01-29 for any reason (newly bought system, duff system clock, testing something) you get a crash on boot.
|| [[#t15:20:32|15:20]]
|- id="t15:20:35"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | someone needs a new cr2032
|| [[#t15:20:35|15:20]]
|- id="t15:20:57"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | yeah but this is complaining about 1-1-2000
|| [[#t15:20:57|15:20]]
|- id="t15:21:09"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | 1-29-2012 is a bigger problem but not as big :P
|| [[#t15:21:09|15:21]]
|- id="t15:21:15"
! style="background-color: #4b904b" | Viking-Ice
| style="color: #4b904b" | is it not rather rare that that is the case
|| [[#t15:21:15|15:21]]
|- id="t15:21:29"
! style="background-color: #4d4d93" | Cerlyn
| style="color: #4d4d93" | This comes up on early XO-1.75 prototypes which occasionally reset their clock for no reason
|| [[#t15:21:29|15:21]]
|- id="t15:21:31"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | really?
|| [[#t15:21:31|15:21]]
|- id="t15:21:50"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Cerlyn: yeah, I was wondering about the XO case
|| [[#t15:21:50|15:21]]
|- id="t15:22:09"
! style="background-color: #488888" | brunowolff
| style="color: #488888" | I am thinking this is a blocker. But it looked like there was a simple change that could be done to avoid triggering the bug and I think that would be OK for Beta.
|| [[#t15:22:09|15:22]]
|- id="t15:22:13"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | but if they're prototypes...then i guess it's kind of annoying for prototype testers, but not a huge issue
|| [[#t15:22:13|15:22]]
|- id="t15:22:20"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | oh is that the laptop for the african children?
|| [[#t15:22:20|15:22]]
|- id="t15:22:32"
! style="background-color: #4b904b" | Viking-Ice
| style="color: #4b904b" | and nobody with the XO team investigating why the clock reset's itselfs?
|| [[#t15:22:32|15:22]]
|- id="t15:22:50"
! style="background-color: #4d4d93" | Cerlyn
| style="color: #4d4d93" | Production units should not be prone to doing this provided they aren't kept in storage improperly to the point the RTC battery drains
|| [[#t15:22:50|15:22]]
|- id="t15:22:57"
! style="background-color: #97974f" | rbergeron
| style="color: #97974f" | adamw: not this morning yet. /me is on phone in meeting, i will flog shortly
|| [[#t15:22:57|15:22]]
|- id="t15:23:07"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | rbergeron: set whips to stun
|| [[#t15:23:07|15:23]]
|- id="t15:23:44"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | so we're kind of left with the generalized 'some kind of weird oops or the RTC battery ran out' case, really
|| [[#t15:23:44|15:23]]
|- id="t15:23:51"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | yup
|| [[#t15:23:51|15:23]]
|- id="t15:24:17"
! style="background-color: #818144" | tflink
| style="color: #818144" | sounds like a conditional violation of the "needs to boot into graphical env" criterion
|| [[#t15:24:17|15:24]]
|- id="t15:24:26"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | not a blocker, but a bug none the less, i can think of way more important things to worry about
|| [[#t15:24:26|15:24]]
|- id="t15:24:36"
! style="background-color: #4d4d93" | Cerlyn
| style="color: #4d4d93" | Is there any known signs that clock values other than an RTC reset may cause this?
|| [[#t15:24:36|15:24]]
|- id="t15:25:19"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Cerlyn: well, any value before jan 29th causes it.
|| [[#t15:25:19|15:25]]
|- id="t15:25:31"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | but there's very few reasons to have a system date that wrong that i can think of.
|| [[#t15:25:31|15:25]]
|- id="t15:25:39"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | good thing it's April 9th
|| [[#t15:25:39|15:25]]
|- id="t15:25:52"
! style="background-color: #97974f" | rbergeron
| style="color: #97974f" | adamw: willdo
|| [[#t15:25:52|15:25]]
|- id="t15:26:08"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | doesn't NTP start before Gnome?
|| [[#t15:26:08|15:26]]
|- id="t15:26:19"
! style="background-color: #818144" | tflink
| style="color: #818144" | assuming you have it turned on, yes
|| [[#t15:26:19|15:26]]
|- id="t15:26:28"
! style="background-color: #4b904b" | Viking-Ice
| style="color: #4b904b" | in any case I vote -1 on blocker even NTH since this is more an exception than a rule that this happens
|| [[#t15:26:28|15:26]]
|- id="t15:26:31"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | well, problem solved.
|| [[#t15:26:31|15:26]]
|- id="t15:26:46"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | VICODAN2: ntp isn't enabled by default
|| [[#t15:26:46|15:26]]
|- id="t15:26:52"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | i know.
|| [[#t15:26:52|15:26]]
|- id="t15:27:20"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | you have to have dead battery and ntp turned off for this to happen
|| [[#t15:27:20|15:27]]
|- id="t15:27:22"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | but yeah, i think i'm with viking-ice, the cases that are going to hit this are just too corner-y and there's an obvious 'workaround' (fix the darn date)
|| [[#t15:27:22|15:27]]
|- id="t15:27:30"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | i have a better chance of winning the lottery
|| [[#t15:27:30|15:27]]
|- id="t15:27:32"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | probably +1 final blocker, but -1 beta
|| [[#t15:27:32|15:27]]
|- id="t15:28:18"
! style="background-color: #818144" | tflink
| style="color: #818144" | yeah, this seems like a rather hairy failure mode but I'm not sure it's beta blocker worty
|| [[#t15:28:18|15:28]]
|- id="t15:28:24"
! style="background-color: #488888" | brunowolff
| style="color: #488888" | It won't be obvious that setting the correct date in the bios is the needed fix. So it would be nice to have this documented with commmon bugs.
|| [[#t15:28:24|15:28]]
|- id="t15:28:24"
! style="background-color: #4b904b" | Viking-Ice
| style="color: #4b904b" | yeah +1 final
|| [[#t15:28:24|15:28]]
|- id="t15:28:31"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | +1
|| [[#t15:28:31|15:28]]
|- id="t15:28:43"
! style="background-color: #4d4d93" | Cerlyn
| style="color: #4d4d93" | +1
|| [[#t15:28:43|15:28]]
|- id="t15:28:56"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | tflink: gnome's failure modes now are just hairy in general. in gnome2 if g-s-d crashed you got a basically working desktop with fonts and sizes and window theme and so on that you didn't specify. in gnome3 you get the fail whale. progress!
|| [[#t15:28:56|15:28]]
|- id="t15:29:25"
! style="background-color: #818144" | tflink
| style="color: #818144" | at least its obvious when something goes wrong
|| [[#t15:29:25|15:29]]
|- id="t15:29:33"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | can we just move back to gnome 2?
|| [[#t15:29:33|15:29]]
|- id="t15:29:44"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | propose #agreed 809707 is rejected as a beta blocker as we can only think of very few cases which will be hit by it, and there is an obvious 'workaround' (really, the fix): correct the system date
|| [[#t15:29:44|15:29]]
|- id="t15:29:45"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | i propose a move back to gnome 2
|| [[#t15:29:45|15:29]]
|- id="t15:29:53"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | VICODAN2: not here, you don't.
|| [[#t15:29:53|15:29]]
|- id="t15:29:54"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | :P
|| [[#t15:29:54|15:29]]
|- id="t15:29:55"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | :(
|| [[#t15:29:55|15:29]]
|- id="t15:30:01"
! style="background-color: #818144" | tflink
| style="color: #818144" | adamw: ack
|| [[#t15:30:01|15:30]]
|- id="t15:30:37"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | its funny
|| [[#t15:30:37|15:30]]
|- id="t15:30:40"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | you install f17
|| [[#t15:30:40|15:30]]
|- id="t15:30:42"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | login
|| [[#t15:30:42|15:30]]
|- id="t15:30:49"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | and you are presented with an empty desktop
|| [[#t15:30:49|15:30]]
|- id="t15:30:54"
! style="background-color: #488888" | brunowolff
| style="color: #488888" | I'd prefer to see common bugs suggestion for this one.
|| [[#t15:30:54|15:30]]
|- id="t15:30:55"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | with like
|| [[#t15:30:55|15:30]]
|- id="t15:31:02"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | "windows" and "activities"
|| [[#t15:31:02|15:31]]
|- id="t15:31:32"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | brunowolff: stick 'commonbugs' in the keywords list
|| [[#t15:31:32|15:31]]
|- id="t15:31:49"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | VICODAN2: the desktop battles belong on devel list, or desktop list, or really anywhere that's not here. =)
|| [[#t15:31:49|15:31]]
|- id="t15:32:05"
! style="background-color: #9b519b" | Martix
| style="color: #9b519b" | regarding Test Days, could you approve mail for tomorrow test
|| [[#t15:32:05|15:32]]
|- id="t15:32:10"
! style="background-color: #9b519b" | Martix
| style="color: #9b519b" | day?
|| [[#t15:32:10|15:32]]
|- id="t15:32:16"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | it's really terrible, i'll look them up.
|| [[#t15:32:16|15:32]]
|- id="t15:32:28"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Martix: will do
|| [[#t15:32:28|15:32]]
|- id="t15:32:33"
! style="background-color: #9b519b" | Martix
| style="color: #9b519b" | adamw: thanks
|| [[#t15:32:33|15:32]]
|- id="t15:32:36"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | any more acks?
|| [[#t15:32:36|15:32]]
|- id="t15:32:40"
! style="background-color: #488888" | brunowolff
| style="color: #488888" | For right now I was suggesting ammending the proposal, but if no one has any objections, I'll just mark the bug.
|| [[#t15:32:40|15:32]]
|- id="t15:32:45"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | oh okay
|| [[#t15:32:45|15:32]]
|- id="t15:32:58"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | commonbugs proposing doesn't really have to follow nth/blocker procedure
|| [[#t15:32:58|15:32]]
|- id="t15:33:08"
! style="background-color: #4d4d93" | Cerlyn
| style="color: #4d4d93" | adamw: Do we wish to propose it as a final blocker in the same motion, or is that a later vote?
|| [[#t15:33:08|15:33]]
|- id="t15:33:14"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | it's a final blocker
|| [[#t15:33:14|15:33]]
|- id="t15:33:15"
! style="background-color: #488888" | brunowolff
| style="color: #488888" | ack
|| [[#t15:33:15|15:33]]
|- id="t15:33:18"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | you can nominate a bug for commonbugs any time, at your own authority, it's just a 'suggestion' to people who like to update the page
|| [[#t15:33:18|15:33]]
|- id="t15:33:32"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Cerlyn: i was going to keep it for later just to keep things simple
|| [[#t15:33:32|15:33]]
|- id="t15:33:39"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | it sounds like it'll likely get fixed before we hit final blocker review anyhow
|| [[#t15:33:39|15:33]]
|- id="t15:34:28"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | yep
|| [[#t15:34:28|15:34]]
|- id="t15:34:53"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #agreed 809707 is rejected as a beta blocker as we can only think of very few cases which will be hit by it, and there is an obvious 'workaround' (really, the fix): correct the system date
|| [[#t15:34:53|15:34]]
|- id="t15:35:07"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | also
|| [[#t15:35:07|15:35]]
|- id="t15:35:12"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | other workaround is use ntp
|| [[#t15:35:12|15:35]]
|- id="t15:35:16"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | anything else anyone's worried about for beta?
|| [[#t15:35:16|15:35]]
|- id="t15:35:26"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | well
|| [[#t15:35:26|15:35]]
|- id="t15:35:33"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | let me tell you about my experience yesterday
|| [[#t15:35:33|15:35]]
|- id="t15:35:38"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | again this is in a vbox vm
|| [[#t15:35:38|15:35]]
|- id="t15:35:42"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | i install f17
|| [[#t15:35:42|15:35]]
|- id="t15:35:45"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | im at the end
|| [[#t15:35:45|15:35]]
|- id="t15:36:13"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | "congratulations fedora is installed!" "remove the cdrom and reboot!" remove cdrom from drive and press reboot and it hangs
|| [[#t15:36:13|15:36]]
|- id="t15:36:25"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | do hard reset, reboot and im dropped in to a grub shell
|| [[#t15:36:25|15:36]]
|- id="t15:36:39"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | booted off DVD again, did an upgrade and it was fine
|| [[#t15:36:39|15:36]]
|- id="t15:36:49"
! style="background-color: #818144" | tflink
| style="color: #818144" | VICODAN2: have you filed a bug?
|| [[#t15:36:49|15:36]]
|- id="t15:36:50"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | if it's not reproducible and you didn't get logs from the failure, there's not a whole lot anyone can do with that.
|| [[#t15:36:50|15:36]]
|- id="t15:36:58"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | no. I want to reproduce it again
|| [[#t15:36:58|15:36]]
|- id="t15:37:24"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | and i was hoping rc4 would drop soon
|| [[#t15:37:24|15:37]]
|- id="t15:37:26"
! style="background-color: #818144" | tflink
| style="color: #818144" | VICODAN2: make sure you grab the logs from the failed install
|| [[#t15:37:26|15:37]]
|- id="t15:37:34"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | so I could report it against RC4
|| [[#t15:37:34|15:37]]
|- id="t15:37:41"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | well it technically wasn't a "failed install"
|| [[#t15:37:41|15:37]]
|- id="t15:37:58"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | when is RC4 dropping?
|| [[#t15:37:58|15:37]]
|- id="t15:38:08"
! style="background-color: #818144" | tflink
| style="color: #818144" | not sure, we're waiting for blocker fixes
|| [[#t15:38:08|15:38]]
|- id="t15:38:19"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | so a week? 2 at most?
|| [[#t15:38:19|15:38]]
|- id="t15:38:35"
! style="background-color: #818144" | tflink
| style="color: #818144" | the hope is in the next day or two
|| [[#t15:38:35|15:38]]
|- id="t15:38:41"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | k
|| [[#t15:38:41|15:38]]
|- id="t15:38:48"
! style="background-color: #818144" | tflink
| style="color: #818144" | but we're getting a bit off into the weeds for a meeting, here
|| [[#t15:38:48|15:38]]
|- id="t15:39:03"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | i'll wait for rc4 and try it again
|| [[#t15:39:03|15:39]]
|- id="t15:39:10"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | how do i grab logs from anacdona/install?
|| [[#t15:39:10|15:39]]
|- id="t15:39:30"
! style="background-color: #818144" | tflink
| style="color: #818144" | VICODAN2: can you ask in #fedora-qa, this is getting off topic for the meeting
|| [[#t15:39:30|15:39]]
|- id="t15:39:35"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | yessir
|| [[#t15:39:35|15:39]]
|- id="t15:39:37"
! style="background-color: #818144" | tflink
| style="color: #818144" | thanks
|| [[#t15:39:37|15:39]]
|- id="t15:39:54"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | okay, so, there we are.
|| [[#t15:39:54|15:39]]
|- id="t15:39:56"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | anything else?
|| [[#t15:39:56|15:39]]
|- id="t15:40:03"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | i need to get to work
|| [[#t15:40:03|15:40]]
|- id="t15:40:08"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #info rc4 is waiting on blocker fixes, we are trying to ping responsible parties.
|| [[#t15:40:08|15:40]]
|- id="t15:40:35"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #topic Test Day report
|| [[#t15:40:35|15:40]]
|- id="t15:40:52"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | VICODAN2: the agenda's at https://fedoraproject.org/wiki/QA/Meetings/20120409
|| [[#t15:40:52|15:40]]
|- id="t15:41:15"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | so we had power management test day - https://fedoraproject.org/wiki/Test_Day:2012-04-04_Power_Management - and installer i18n/l10n test days last week - https://fedoraproject.org/wiki/Test_Day:2012-04-05_L10n_I18n_Installation
|| [[#t15:41:15|15:41]]
|- id="t15:41:23"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | did anyone make it out to those? I suck at attending test days lately.
|| [[#t15:41:23|15:41]]
|- id="t15:41:26"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | yep
|| [[#t15:41:26|15:41]]
|- id="t15:41:28"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | i did
|| [[#t15:41:28|15:41]]
|- id="t15:41:33"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | i did power management day
|| [[#t15:41:33|15:41]]
|- id="t15:41:34"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | how'd they go?
|| [[#t15:41:34|15:41]]
|- id="t15:41:39"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | pretty good
|| [[#t15:41:39|15:41]]
|- id="t15:41:48"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | lots of people ran the reports
|| [[#t15:41:48|15:41]]
|- id="t15:42:14"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | i was impressed as to how well it was actually working
|| [[#t15:42:14|15:42]]
|- id="t15:42:33"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | f17 was actually able to read my battery info through a virtualbox vm
|| [[#t15:42:33|15:42]]
|- id="t15:43:18"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | i18n/l10n, didnt attend, dont know anything about it
|| [[#t15:43:18|15:43]]
|- id="t15:43:23"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | looks like we got good turnout for the pm day, yup.
|| [[#t15:43:23|15:43]]
|- id="t15:43:45"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #info turnout for the power management test day was good, looks like a solid bunch of results - https://fedoraproject.org/wiki/Test_Day:2012-04-04_Power_Management
|| [[#t15:43:45|15:43]]
|- id="t15:43:48"
! style="background-color: #9b519b" | Martix
| style="color: #9b519b" | it was Open House in Brno office :-)
|| [[#t15:43:48|15:43]]
|- id="t15:44:02"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | brb, hoppin in the shower
|| [[#t15:44:02|15:44]]
|- id="t15:44:13"
! style="background-color: #9b519b" | Martix
| style="color: #9b519b" | so many people got involved
|| [[#t15:44:13|15:44]]
|- id="t15:44:36"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | cool
|| [[#t15:44:36|15:44]]
|- id="t15:44:43"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #info PM test day was open house in Brno
|| [[#t15:44:43|15:44]]
|- id="t15:45:35"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #info seems to have been solid data in the i18n/l10n installation test day too, but the results table is a little odd, may need tidying up
|| [[#t15:45:35|15:45]]
|- id="t15:46:10"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #topic upcoming events
|| [[#t15:46:10|15:46]]
|- id="t15:46:43"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | so it looks like we have KDE 4.10 tomorrow and Virtualization on Thursday
|| [[#t15:46:43|15:46]]
|- id="t15:46:52"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | er, 4.8, rather
|| [[#t15:46:52|15:46]]
|- id="t15:46:58"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #info KDE 4.8 Test Day tomorrow - https://fedoraproject.org/wiki/Test_Day:2012-04-10_KDE_4.8
|| [[#t15:46:58|15:46]]
|- id="t15:47:07"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | when we say "virtualization" are we mainly concerned with KVM?
|| [[#t15:47:07|15:47]]
|- id="t15:47:09"
! style="background-color: #9b519b" | Martix
| style="color: #9b519b" | yep, I am looking for your test reports :-)
|| [[#t15:47:09|15:47]]
|- id="t15:47:15"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #info Virtualization Test Day on Thursday - https://fedoraproject.org/wiki/Test_Day:2012-04-12_Virtualization_Test_Day
|| [[#t15:47:15|15:47]]
|- id="t15:47:15"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | VICODAN2: yep
|| [[#t15:47:15|15:47]]
|- id="t15:47:18"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | k
|| [[#t15:47:18|15:47]]
|- id="t15:47:21"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | VICODAN2: it means 'fedora virt stack' - see the page
|| [[#t15:47:21|15:47]]
|- id="t15:47:48"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | yep
|| [[#t15:47:48|15:47]]
|- id="t15:47:52"
! style="background-color: #539e9e" | jreznik
| style="color: #539e9e" | for kde 4.8 rdieter prepared the image, we are finishing test cases, ltinkl reviewed Martix's testcases, looks good
|| [[#t15:47:52|15:47]]
|- id="t15:47:56"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | so the kde page has test cases but the results table is still generic and no special live images up
|| [[#t15:47:56|15:47]]
|- id="t15:48:01"
! style="background-color: #539e9e" | jreznik
| style="color: #539e9e" | also some marketing is done
|| [[#t15:48:01|15:48]]
|- id="t15:48:05"
! style="background-color: #539e9e" | jreznik
| style="color: #539e9e" | adamw: yep, I know
|| [[#t15:48:05|15:48]]
|- id="t15:48:10"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | jreznik: looks like you need to update the image links and results table - cool
|| [[#t15:48:10|15:48]]
|- id="t15:48:14"
! style="background-color: #539e9e" | jreznik
| style="color: #539e9e" | will be fixed once we will have all testcases
|| [[#t15:48:14|15:48]]
|- id="t15:48:18"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | we'll get the test-ann mail approved
|| [[#t15:48:18|15:48]]
|- id="t15:48:19"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | great
|| [[#t15:48:19|15:48]]
|- id="t15:48:35"
! style="background-color: #539e9e" | jreznik
| style="color: #539e9e" | adamw: Martix should update the link to image, at least he promised it :)
|| [[#t15:48:35|15:48]]
|- id="t15:48:39"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #info KDE team is on top of preparation for tomorrow
|| [[#t15:48:39|15:48]]
|- id="t15:48:41"
! style="background-color: #9b519b" | Martix
| style="color: #9b519b" | jreznik: thanks, but we need finish more test cases
|| [[#t15:48:41|15:48]]
|- id="t15:49:16"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #info virt test day is taking a freeform testing approach, looks like they have the page set up as they want it
|| [[#t15:49:16|15:49]]
|- id="t15:49:18"
! style="background-color: #9b519b" | Martix
| style="color: #9b519b" | jreznik: its already updated
|| [[#t15:49:18|15:49]]
|- id="t15:49:26"
! style="background-color: #539e9e" | jreznik
| style="color: #539e9e" | Martix: ok
|| [[#t15:49:26|15:49]]
|- id="t15:49:34"
! style="background-color: #9b519b" | Martix
| style="color: #9b519b" | jreznik: waiting for sha256 verification
|| [[#t15:49:34|15:49]]
|- id="t15:49:56"
! style="background-color: #539e9e" | jreznik
| style="color: #539e9e" | I'd like to combine test cases with freeform tests on the rest topics we don't have a test case
|| [[#t15:49:56|15:49]]
|- id="t15:49:56"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | oh yeah, i just saw the 'tbd' and missed the links, d'oh :)
|| [[#t15:49:56|15:49]]
|- id="t15:50:10"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | jreznik: you can certainly do that if you get enough people in IRC to get the chat flowing
|| [[#t15:50:10|15:50]]
|- id="t15:50:20"
! style="background-color: #9b519b" | Martix
| style="color: #9b519b" | x86_64 image passed media verification, I'll add sha256 sum, but still downloading i686 image
|| [[#t15:50:20|15:50]]
|- id="t15:51:04"
! style="background-color: #9b519b" | Martix
| style="color: #9b519b" | or can rdieter provide sha256 sums for his images?
|| [[#t15:51:04|15:51]]
|- id="t15:51:21"
! style="background-color: #4b904b" | Viking-Ice
| style="color: #4b904b" | VICODAN2, I would go as far to say the only thing we care about kvm ( because it's the only solution we can actually do anything about )
|| [[#t15:51:21|15:51]]
|- id="t15:51:26"
! style="background-color: #a25555" | rdieter
| style="color: #a25555" | Martix: good idea, I totally forgot about that.
|| [[#t15:51:26|15:51]]
|- id="t15:52:53"
! style="background-color: #539e9e" | jreznik
| style="color: #539e9e" | adamw: I hope to ge traffic but we completely forgot Easter, so a lot of people still on vacations :)
|| [[#t15:52:53|15:52]]
|- id="t15:53:13"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | ah, well, we'll see :)
|| [[#t15:53:13|15:53]]
|- id="t15:53:34"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | okay, so they're both looking pretty well prepared for, let us know if there's anything we can do to help jreznik
|| [[#t15:53:34|15:53]]
|- id="t15:53:38"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | aside from showing up of course :)
|| [[#t15:53:38|15:53]]
|- id="t15:54:23"
! style="background-color: #539e9e" | jreznik
| style="color: #539e9e" | adamw: yep, thanks :) Martix is still around, so we have a good fedora qa guy taking care of it :)
|| [[#t15:54:23|15:54]]
|- id="t15:54:36"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | well, i wouldn't say 'good'....&lt;ducks&gt;
|| [[#t15:54:36|15:54]]
|- id="t15:55:08"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | oh, and go/no-go is set for wednesday once more.
|| [[#t15:55:08|15:55]]
|- id="t15:55:39"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | i'm not saying it means anything, just that i've seen World Domination For Beginners in martix's desk drawer
|| [[#t15:55:39|15:55]]
|- id="t15:55:40"
! style="background-color: #539e9e" | jreznik
| style="color: #539e9e" | adamw: :) I should probably use a different word :) amazing? awesome? :)
|| [[#t15:55:40|15:55]]
|- id="t15:55:59"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | and he keeps sending in expense requests for sharks and lasers
|| [[#t15:55:59|15:55]]
|- id="t15:56:27"
| colspan="2" | * jreznik knows Martix for several years...
|| [[#t15:56:27|15:56]]
|- id="t15:56:30"
! style="background-color: #9b519b" | Martix
| style="color: #9b519b" | adamw: hehe, we must block Fedora Beta release for all costs! &lt;/irony&gt; :-D
|| [[#t15:56:30|15:56]]
|- id="t15:57:16"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | :P
|| [[#t15:57:16|15:57]]
|- id="t15:57:23"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | okay, so looks like upcoming events are under control
|| [[#t15:57:23|15:57]]
|- id="t15:57:33"
| colspan="2" | * jreznik hopes :)
|| [[#t15:57:33|15:57]]
|- id="t15:57:46"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #topic AutoQA update
|| [[#t15:57:46|15:57]]
|- id="t15:57:51"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | i'm guessing there's no news here again?
|| [[#t15:57:51|15:57]]
|- id="t15:58:22"
! style="background-color: #818144" | tflink
| style="color: #818144" | nope, we've been pretty consumed w/ F17 beta testing AFAIK
|| [[#t15:58:22|15:58]]
|- id="t15:59:40"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | fun. :/
|| [[#t15:59:40|15:59]]
|- id="t15:59:43"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #info there is no news. ding.
|| [[#t15:59:43|15:59]]
|- id="t15:59:49"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #topic Open floor
|| [[#t15:59:49|15:59]]
|- id="t16:00:31"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | back
|| [[#t16:00:31|16:00]]
|- id="t16:00:42"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | so, i did have one thing for open floor, though we're slightly over time
|| [[#t16:00:42|16:00]]
|- id="t16:00:55"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | go on...
|| [[#t16:00:55|16:00]]
|- id="t16:01:06"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | i can send a formal proposal to the list, but - it actually occurred to me last week as we were slipping a release for a bug in preupgrade that there's no damn reason to slip releases for bugs in preupgrade.
|| [[#t16:01:06|16:01]]
|- id="t16:01:11"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | even if they're on the anaconda side.
|| [[#t16:01:11|16:01]]
|- id="t16:01:25"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | that's my bug :)
|| [[#t16:01:25|16:01]]
|- id="t16:01:32"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | i give you permission to move it to final blocker
|| [[#t16:01:32|16:01]]
|- id="t16:01:40"
| colspan="2" | * rbergeron doesn't look at this line
|| [[#t16:01:40|16:01]]
|- id="t16:01:50"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | am i missing anything? or should we just treat all preupgrade blockers as 'special' the way we currently treat livecd-iso-to-disk blockers?
|| [[#t16:01:50|16:01]]
|- id="t16:02:10"
! style="background-color: #818144" | tflink
| style="color: #818144" | I assume that the rationale is something along the lines of "as long as some upgrade method works"?
|| [[#t16:02:10|16:02]]
|- id="t16:02:16"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | no
|| [[#t16:02:16|16:02]]
|- id="t16:02:32"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | the rationale is that preupgrade doesn't pull anything from anywhere that goes out as media
|| [[#t16:02:32|16:02]]
|- id="t16:02:41"
! style="background-color: #488888" | brunowolff
| style="color: #488888" | That's assuming we know the fix needs to be in preupgrade, not in some f17 package.
|| [[#t16:02:41|16:02]]
|- id="t16:02:45"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | no
|| [[#t16:02:45|16:02]]
|- id="t16:02:49"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | think about it :)
|| [[#t16:02:49|16:02]]
|- id="t16:02:50"
! style="background-color: #818144" | tflink
| style="color: #818144" | adamw: the difference in my mind is that most livecd-iso-to-disk bugs can be fixed outside of the release
|| [[#t16:02:50|16:02]]
|- id="t16:02:53"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | what's the problem with testing preupgrade?
|| [[#t16:02:53|16:02]]
|- id="t16:03:07"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | we always have to wait for a stable update push to test it
|| [[#t16:03:07|16:03]]
|- id="t16:03:16"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | why not just get rid of preupgrade all together?
|| [[#t16:03:16|16:03]]
|- id="t16:03:28"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | it's so annoying...the only way we can test preupgrade blockers is to update the tree on the mirrors...just re-spinning  the media doesn't help...
|| [[#t16:03:28|16:03]]
|- id="t16:03:31"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | *gears whirring*
|| [[#t16:03:31|16:03]]
|- id="t16:03:38"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | then why are we blocking media composes on preupgrade bugs? :)
|| [[#t16:03:38|16:03]]
|- id="t16:03:39"
! style="background-color: #818144" | tflink
| style="color: #818144" | officially, yes but now that we have a method of testing preupgrade before everything hits stable, it's a little easier
|| [[#t16:03:39|16:03]]
|- id="t16:04:01"
! style="background-color: #818144" | tflink
| style="color: #818144" | because preupgrade requires interaction with anaconda, which can't be fixed by updates
|| [[#t16:04:01|16:04]]
|- id="t16:04:04"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | tflink: follow the thought process, though. point is, preupgrade process and media composes are completely independent of each other, effectively.
|| [[#t16:04:04|16:04]]
|- id="t16:04:08"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | yes it can. for preupgrade.
|| [[#t16:04:08|16:04]]
|- id="t16:04:23"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | look
|| [[#t16:04:23|16:04]]
|- id="t16:04:25"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | preupgrade never uses the anaconda on the media. it always pulls its anaconda from the tree on the repos.
|| [[#t16:04:25|16:04]]
|- id="t16:04:28"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | you can upgrade via yum right?
|| [[#t16:04:28|16:04]]
|- id="t16:04:37"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | you can upgrade via dvd right?
|| [[#t16:04:37|16:04]]
|- id="t16:04:47"
! style="background-color: #818144" | tflink
| style="color: #818144" | I didn't think that preupgrade pulled from updates, though
|| [[#t16:04:47|16:04]]
|- id="t16:04:52"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | if we ship Beta with anaconda that's 'broken' re preupgrade, and we then push an anaconda update that fixes preupgrade stable, does preupgrade start working?
|| [[#t16:04:52|16:04]]
|- id="t16:04:57"
! style="background-color: #818144" | tflink
| style="color: #818144" | I thought that it always pulls from stable
|| [[#t16:04:57|16:04]]
|- id="t16:05:04"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | tflink: there is no updates before release
|| [[#t16:05:04|16:05]]
|- id="t16:05:17"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | there are only two repos for f17 at present: updates-testing and 'stable'
|| [[#t16:05:17|16:05]]
|- id="t16:05:24"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | when we approve an update, it goes to 'stable'
|| [[#t16:05:24|16:05]]
|- id="t16:05:26"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | lol "stable"
|| [[#t16:05:26|16:05]]
|- id="t16:05:27"
! style="background-color: #818144" | tflink
| style="color: #818144" | adamw: updates/updates-testing - not stable was what I was getting at
|| [[#t16:05:27|16:05]]
|- id="t16:05:38"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | tflink: there is no 'updates' for branched releases. the tree is empty.
|| [[#t16:05:38|16:05]]
|- id="t16:05:43"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | but it pulls from updates-testing by default anyway
|| [[#t16:05:43|16:05]]
|- id="t16:05:44"
! style="background-color: #818144" | tflink
| style="color: #818144" | adamw: preupgrade uses the initrd and vmlinuz from the tree
|| [[#t16:05:44|16:05]]
|- id="t16:06:09"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | tflink: right. but that gets rebuilt every day from whatever's in 'stable'. as soon as we push a fixed anaconda, we get a new vmlinuz/initrd on the mirrors.
|| [[#t16:06:09|16:06]]
|- id="t16:06:18"
! style="background-color: #818144" | tflink
| style="color: #818144" | we do?
|| [[#t16:06:18|16:06]]
|- id="t16:06:30"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | lol
|| [[#t16:06:30|16:06]]
|- id="t16:06:32"
! style="background-color: #818144" | tflink
| style="color: #818144" | I thought that was only updated on the mirrors @ releases
|| [[#t16:06:32|16:06]]
|- id="t16:06:33"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | i believe so. i might be wrong, of course.
|| [[#t16:06:33|16:06]]
|- id="t16:06:54"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | again, why do we need preupgrade?
|| [[#t16:06:54|16:06]]
|- id="t16:06:58"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | last question before i leave
|| [[#t16:06:58|16:06]]
|- id="t16:07:00"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | tflink: no, otherwise we'd never get preupgrade behaviour changes except at alpha, beta and final.
|| [[#t16:07:00|16:07]]
|- id="t16:07:20"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | VICODAN2: in theory, it's a more reliable mechanism than yum. we don't officially support yum upgrades. preupgrade is the supported 'online' upgrade method.
|| [[#t16:07:20|16:07]]
|- id="t16:07:41"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | i would say let's deprecate preupgrade and make yum the new standard
|| [[#t16:07:41|16:07]]
|- id="t16:07:44"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | yum works great
|| [[#t16:07:44|16:07]]
|- id="t16:07:53"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | i've upgraded from 11-&gt;12-&gt;13-&gt;14-&gt;15 via yum
|| [[#t16:07:53|16:07]]
|- id="t16:08:19"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | the only thing
|| [[#t16:08:19|16:08]]
|- id="t16:08:33"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | is making yum handle the new boot process stuffs
|| [[#t16:08:33|16:08]]
|- id="t16:08:37"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | which ims sure it could do
|| [[#t16:08:37|16:08]]
|- id="t16:08:43"
! style="background-color: #488888" | brunowolff
| style="color: #488888" | You need to know special things to to yum upgrades between some releases, preupgrade is supposed to hide that from you.
|| [[#t16:08:43|16:08]]
|- id="t16:08:45"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | that's my $.02
|| [[#t16:08:45|16:08]]
|- id="t16:08:52"
! style="background-color: #818144" | tflink
| style="color: #818144" | adamw: have we had many changes in preupgrade that required anaconda fixes? the one that I remember from F16 required changes in preupgrade only
|| [[#t16:08:52|16:08]]
|- id="t16:08:55"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | there would not be any support for that from devel side. they are fairly strongly of the opinion that yum is not a supportable upgrade mechanism. it's sidetracking the question of whether preupgrade issues need to block media composes, anyway.
|| [[#t16:08:55|16:08]]
|- id="t16:08:55"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | no need to hide it
|| [[#t16:08:55|16:08]]
|- id="t16:08:57"
! style="background-color: #818144" | tflink
| style="color: #818144" | unless I'm just mis-remembering
|| [[#t16:08:57|16:08]]
|- id="t16:09:24"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | nirik: can you confirm or deny whether i'm right about how branched tree works?
|| [[#t16:09:24|16:09]]
|- id="t16:09:25"
! style="background-color: #488888" | brunowolff
| style="color: #488888" | For you maybe. For lots of people yes.
|| [[#t16:09:25|16:09]]
|- id="t16:09:38"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | well, we aren't getting much "support" from the devel side on preupgrade now are we?
|| [[#t16:09:38|16:09]]
|- id="t16:09:41"
| colspan="2" | * nirik reads up.
|| [[#t16:09:41|16:09]]
|- id="t16:09:44"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | has anyone done any work on this?
|| [[#t16:09:44|16:09]]
|- id="t16:09:47"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | while we're doing that - preupgrade goes out and reads https://mirrors.fedoraproject.org/releases.txt to find out where to get its anaconda from.
|| [[#t16:09:47|16:09]]
|- id="t16:09:52"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | i found the bug like a month or two ago
|| [[#t16:09:52|16:09]]
|- id="t16:10:09"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | VICODAN2: which bug? there have been like eight preupgrade bugs, in serial. we fix one of them at a time, and keep finding more.
|| [[#t16:10:09|16:10]]
|- id="t16:10:21"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | f16, preupgrade to 17
|| [[#t16:10:21|16:10]]
|- id="t16:10:24"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | VICODAN2: the current preupgrade blocker was not filed by you. it was filed by me.
|| [[#t16:10:24|16:10]]
|- id="t16:10:28"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | https://bugzilla.redhat.com/show_bug.cgi?id=810391
|| [[#t16:10:28|16:10]]
|- id="t16:10:33"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | adamw: right. there's updates-testing and empty updates, and a 'base' repo. We rebuild the base repo every night with anything thats going to stable.
|| [[#t16:10:33|16:10]]
|- id="t16:10:33"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | so mine was fixed then eh?
|| [[#t16:10:33|16:10]]
|- id="t16:10:38"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | all i know is that it's still not working
|| [[#t16:10:38|16:10]]
|- id="t16:10:44"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | ill check my bug then
|| [[#t16:10:44|16:10]]
|- id="t16:10:53"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | nirik: so say we build rc4 right now, then we get an anaconda that fixes preupgrade tomorrow
|| [[#t16:10:53|16:10]]
|- id="t16:11:07"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | build rc5!
|| [[#t16:11:07|16:11]]
|- id="t16:11:09"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | :P
|| [[#t16:11:09|16:11]]
|- id="t16:11:09"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | nirik: whenever that anaconda gets pushed 'stable', preupgrade will start working, right? it doesn't matter that it wasn't in the rc4 compose?
|| [[#t16:11:09|16:11]]
|- id="t16:11:35"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | adamw: I think so, unless preupgrades releases.txt points to the release instead of the f17 devel tree.
|| [[#t16:11:35|16:11]]
|- id="t16:11:38"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | ok my boss just called me and yelled at me
|| [[#t16:11:38|16:11]]
|- id="t16:11:45"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | i need to go now, i've caused enough havoc here
|| [[#t16:11:45|16:11]]
|- id="t16:11:48"
! style="background-color: #854685" | VICODAN2
| style="color: #854685" | have fun y'all
|| [[#t16:11:48|16:11]]
|- id="t16:11:50"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | nirik: it uses https://mirrors.fedoraproject.org/releases.txt
|| [[#t16:11:50|16:11]]
|- id="t16:11:55"
! style="background-color: #818144" | tflink
| style="color: #818144" | nirik: I didn't think that the devel tree was mirrored in many places
|| [[#t16:11:55|16:11]]
|- id="t16:12:10"
! style="background-color: #818144" | tflink
| style="color: #818144" | ie most mirrors use the release
|| [[#t16:12:10|16:12]]
|- id="t16:12:13"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | nirik: what's that pointing to?
|| [[#t16:12:13|16:12]]
|- id="t16:12:15"
! style="background-color: #818144" | tflink
| style="color: #818144" | but I could easily be wrong
|| [[#t16:12:15|16:12]]
|- id="t16:12:32"
! style="background-color: #488888" | brunowolff
| style="color: #488888" | And if the bug is in preupgrade, that will be fixed in earlier releases. So I am buying that preupgrade should not block composes.
|| [[#t16:12:32|16:12]]
|- id="t16:12:37"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | adamw: correct. that points to whatever we point it at. ;) Right now it points to the devel tree.
|| [[#t16:12:37|16:12]]
|- id="t16:12:50"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | tflink: all mirrors who do rawhide should also have f17
|| [[#t16:12:50|16:12]]
|- id="t16:13:41"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | right now we have:
|| [[#t16:13:41|16:13]]
|- id="t16:13:49"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | (flood coming)
|| [[#t16:13:49|16:13]]
|- id="t16:13:52"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | [Fedora 17 (Beefy Miracle)]
|| [[#t16:13:52|16:13]]
|- id="t16:13:52"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | stable=False
|| [[#t16:13:52|16:13]]
|- id="t16:13:53"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | preupgrade-ok=True
|| [[#t16:13:53|16:13]]
|- id="t16:13:53"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | version=17
|| [[#t16:13:53|16:13]]
|- id="t16:13:53"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-17&amp;arch=$basearch
|| [[#t16:13:53|16:13]]
|- id="t16:13:53"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | installmirrorlist=http://mirrors.fedoraproject.org/mirrorlist?path=pub/fedora/linux/development/17/$basearch/os/
|| [[#t16:13:53|16:13]]
|- id="t16:14:07"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | brunowolff: well, thinking about it, so far i think it shows that preupgrade shouldn't block alpha or beta composes
|| [[#t16:14:07|16:14]]
|- id="t16:14:10"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Final may be a different question
|| [[#t16:14:10|16:14]]
|- id="t16:14:42"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | nirik: for final releases, what does preupgrade use? is it using the original 'frozen' release tree, i.e. whatever anaconda we shipped at release time?
|| [[#t16:14:42|16:14]]
|- id="t16:14:50"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | yeah, we do point to releases for final.
|| [[#t16:14:50|16:14]]
|- id="t16:14:53"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | okay
|| [[#t16:14:53|16:14]]
|- id="t16:15:03"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | (though we could probably improve that if we wanted, i guess.)
|| [[#t16:15:03|16:15]]
|- id="t16:15:04"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-16&amp;arch=$basearch
|| [[#t16:15:04|16:15]]
|- id="t16:15:04"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | installmirrorlist=http://mirrors.fedoraproject.org/mirrorlist?path=pub/fedora/linux/releases/16/Fedora/$basearch/os/
|| [[#t16:15:04|16:15]]
|- id="t16:15:20"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | so, i think i'm right in that alpha and beta composes can disregard preupgrade
|| [[#t16:15:20|16:15]]
|- id="t16:15:31"
! style="background-color: #818144" | tflink
| style="color: #818144" | yeah, that makes sense to me
|| [[#t16:15:31|16:15]]
|- id="t16:15:42"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | okay...can anyone else see anything we're not accounting for?
|| [[#t16:15:42|16:15]]
|- id="t16:16:00"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | if everyone's following the logic so far, i'll send a proposal to the list - guess the easiest thing is just to push the preupgrade criterion to final
|| [[#t16:16:00|16:16]]
|- id="t16:16:19"
! style="background-color: #818144" | tflink
| style="color: #818144" | sounds like a plan
|| [[#t16:16:19|16:16]]
|- id="t16:16:47"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | I'd be worried if we moved all preupgrade to final tho
|| [[#t16:16:47|16:16]]
|- id="t16:17:09"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | 'all preupgrade'?
|| [[#t16:17:09|16:17]]
|- id="t16:17:21"
! style="background-color: #488888" | brunowolff
| style="color: #488888" | Just because it blocks composes doesn't necessarily mean we wouldn't block a release if needed fix for say anaconda hadn't gone to stable.
|| [[#t16:17:21|16:17]]
|- id="t16:17:36"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | well, if we ignore preupgrade for alpha and beta it means at final we would have a nasty set of russian dolls of bugs to try and fix before release.
|| [[#t16:17:36|16:17]]
|- id="t16:17:50"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | nirik: not being blocking doesn't mean it gets 'ignored'
|| [[#t16:17:50|16:17]]
|- id="t16:17:56"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | right.
|| [[#t16:17:56|16:17]]
|- id="t16:17:56"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | nirik: we usually try and do the whole matrix at alpha and beta stages
|| [[#t16:17:56|16:17]]
|- id="t16:18:03"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | but yeah, i take the point
|| [[#t16:18:03|16:18]]
|- id="t16:18:06"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | i guess we can discuss further on list
|| [[#t16:18:06|16:18]]
|- id="t16:18:13"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | just wanted to clarify that it wasn't ignoring it... just not blocking composes.
|| [[#t16:18:13|16:18]]
|- id="t16:18:15"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | thanks for letting me kick that one around :)
|| [[#t16:18:15|16:18]]
|- id="t16:18:27"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #action adamw to send formal proposal for preupgrade criteria adjustment to the list
|| [[#t16:18:27|16:18]]
|- id="t16:18:32"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | anyone have anything else for open floor?
|| [[#t16:18:32|16:18]]
|- id="t16:18:44"
! style="background-color: #57a657" | robatino
| style="color: #57a657" | long term, the mediacheck needs to be exposed again
|| [[#t16:18:44|16:18]]
|- id="t16:18:58"
! style="background-color: #57a657" | robatino
| style="color: #57a657" | i filed https://bugzilla.redhat.com/show_bug.cgi?id=809663
|| [[#t16:18:58|16:18]]
|- id="t16:19:10"
! style="background-color: #57a657" | robatino
| style="color: #57a657" | right now, it's not discoverable for install discs
|| [[#t16:19:10|16:19]]
|- id="t16:19:48"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | right, i saw that bug
|| [[#t16:19:48|16:19]]
|- id="t16:20:14"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #info mediacheck is now 'hidden' as it was previously part of loader, it can be prompted with a cmdline parameter but most people won't know that: https://bugzilla.redhat.com/show_bug.cgi?id=809663
|| [[#t16:20:14|16:20]]
|- id="t16:20:25"
! style="background-color: #818144" | tflink
| style="color: #818144" | wouldn't the required change be in lorax/pungi?
|| [[#t16:20:25|16:20]]
|- id="t16:20:51"
| colspan="2" | * tflink can't remember if pungi does anything with the syslinux menu off the top of his head
|| [[#t16:20:51|16:20]]
|- id="t16:22:25"
! style="background-color: #57a657" | robatino
| style="color: #57a657" | and it might be good to modify the final criteria to require mediacheck (we could do it right now since it's there already)
|| [[#t16:22:25|16:22]]
|- id="t16:22:59"
! style="background-color: #57a657" | robatino
| style="color: #57a657" | just its existence, i mean, not having it done by default
|| [[#t16:22:59|16:22]]
|- id="t16:24:04"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | right, i think we have a dormant list thread about that? maybe wake it up
|| [[#t16:24:04|16:24]]
|- id="t16:25:38"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | okay...anything else?
|| [[#t16:25:38|16:25]]
|- id="t16:26:19"
! style="background-color: #818144" | tflink
| style="color: #818144" | I have some other questions about the preupgrade issue, but they can wait for the email thread
|| [[#t16:26:19|16:26]]
|- id="t16:26:50"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | okie dokie
|| [[#t16:26:50|16:26]]
|- id="t16:26:55"
| colspan="2" | * adamw sets fuse for 2 minutes
|| [[#t16:26:55|16:26]]
|- id="t16:28:29"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | thanks for coming, all!
|| [[#t16:28:29|16:28]]
|- id="t16:28:55"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #endmeeting
|| [[#t16:28:55|16:28]]
|}
Generated by irclog2html.py 2.8 by [mailto:marius@pov.lt Marius Gedminas] - find it at [http://mg.pov.lt/irclog2html mg.pov.lt]!

Latest revision as of 21:30, 10 April 2012

Attendees

  • adamw (153)
  • VICODAN2 (111)
  • tflink (36)
  • nirik (22)
  • brunowolff (13)
  • Martix (12)
  • jreznik (12)
  • Viking-Ice (8)
  • Cerlyn (7)
  • robatino (5)
  • zodbot (3)
  • rbergeron (3)
  • rdieter (1)
  • satellit_ (1)

Agenda

  • Previous meeting follow-up
  • Fedora 17 Beta status / blocker review
  • Test Day report
  • Upcoming QA events
  • AutoQA update
  • Open floor

Previous meeting follow-up

Fedora 17 Beta status / blocker review

  • Current_Release_Blockers
  • Need to spin RC4 ASAP: blockers remained in anaconda/preupgrade and selinux
  • #809707 was rejected as a beta blocker as we can only think of very few cases which will be hit by it, and there is an obvious 'workaround' (really, the fix): correct the system date

Test Day report

Upcoming QA events

AutoQA update

  • No news, once more

Open floor

  • Some discussion of whether preupgrade bugs should block media spins: adam to propose changes on the list
  • Andre noted that mediacheck is now 'hidden' and should be exposed or enabled by default: see #809663

Action items

  • adamw to send formal proposal for preupgrade criteria adjustment to the list

IRC Log

adamw #startmeeting Fedora QA meeting 15:00
zodbot Meeting started Mon Apr 9 15:00:07 2012 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00
zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00
adamw #meetingname fedora-qa 15:00
zodbot The meeting name has been set to 'fedora-qa' 15:00
adamw #topic roll call 15:00
adamw well hey, it appears to be meeting time again. 15:00
tflink it does indeed 15:00
* tflink thinks the attendance is going to be a bit light today 15:01
adamw likely 15:01
adamw who's around? come crawl out of the woodwork 15:01
adamw if it's just me and you we may as well cancel 15:02
* Cerlyn is here 15:02
* brunowolff is here 15:02
* nirik is lurking around as always 15:03
* satellit_ listening 15:03
adamw ooh, the woodwork is positively slithering, it appears. 15:03
VICODAN2 HI 15:05
adamw hi dan. 15:05
VICODAN2 how goes it? 15:05
adamw so, we don't have anything from last week that i can think of 15:05
VICODAN2 i just woke up 15:05
adamw anyone else think of anything to follow up on? 15:05
VICODAN2 probably nothing i can offer that hasn't been talked about already 15:06
VICODAN2 i installed RC3 yesterday on a VM 15:06
adamw okay, let's skip previous meeting follow-up then 15:06
adamw #topic Fedora 17 Beta status / blocker review 15:07
adamw so, not looking great here, we have no rc4 and still two open blockers, it seems. unless i missed something this morning. 15:07
VICODAN2 nope sounds about right 15:07
* Viking-Ice sneaks in 15:07
adamw anyone heard anything from mgrepl or wwoods through any side channels? 15:08
tflink nope 15:08
brunowolff I saw a bunch of updates did get pulled in to F17 stable over the weekend. 15:08
nirik that was the gnome 3.4 update. 15:08
VICODAN2 the login screen still shows the sql server login 15:09
adamw brunowolff: yeah, we're tidying up the stuff from rc3. 15:10
brunowolff It looks like today's compose failed. Though it's kind of an odd looking error. 15:10
adamw VICODAN2: that one's not a beta blocker. think desktop team was bikeshedding it, but it should be gone for final one way or another, i guess. 15:10
VICODAN2 yea i'd like to have a word with them 15:11
VICODAN2 oh 15:11
VICODAN2 package dependencies seems to be fixed 15:11
VICODAN2 no more problems when running yum update after installing a bunch of packages with customize now 15:12
VICODAN2 i did have to install twice yesterday, but im going to blame virtualbox on that 15:12
adamw so, basically, seems we need to get out the pokey sticks and start poking mgrepl and wwoods. not a whole lot we can do till then. 15:12
VICODAN2 nope 15:12
adamw rbergeron: have you been performing official pokeage? 15:13
VICODAN2 maybe hes poking them now 15:14
adamw she 15:15
VICODAN2 she's been idle for 20 mins 15:16
adamw oh, well. 15:16
adamw tflink: we don't have any blockers to review, right? 15:16
adamw oh, hey, we do have one new one. 15:16
adamw the other two proposed are already discussed, i just didn't secretaryize from friday yet, my bad. 15:17
adamw #topic Beta blocker review: http://bugzilla.redhat.com/show_bug.cgi?id=809707 15:17
VICODAN2 LOL 15:18
adamw this sounds worse reading through it than it does from the summary... 15:19
VICODAN2 this is not a blocker 15:19
Viking-Ice Do we have any "date" criteria 15:19
Viking-Ice if not then not a blocker just regular bug 15:19
VICODAN2 this is lamer than the y2k bug 15:19
Cerlyn it's a failure to boot due to the RTC not being correct 15:19
adamw yeah. 15:19
adamw that's the problem: if you have system date earlier than 2012-01-29 for any reason (newly bought system, duff system clock, testing something) you get a crash on boot. 15:20
VICODAN2 someone needs a new cr2032 15:20
VICODAN2 yeah but this is complaining about 1-1-2000 15:20
VICODAN2 1-29-2012 is a bigger problem but not as big :P 15:21
Viking-Ice is it not rather rare that that is the case 15:21
Cerlyn This comes up on early XO-1.75 prototypes which occasionally reset their clock for no reason 15:21
VICODAN2 really? 15:21
adamw Cerlyn: yeah, I was wondering about the XO case 15:21
brunowolff I am thinking this is a blocker. But it looked like there was a simple change that could be done to avoid triggering the bug and I think that would be OK for Beta. 15:22
adamw but if they're prototypes...then i guess it's kind of annoying for prototype testers, but not a huge issue 15:22
VICODAN2 oh is that the laptop for the african children? 15:22
Viking-Ice and nobody with the XO team investigating why the clock reset's itselfs? 15:22
Cerlyn Production units should not be prone to doing this provided they aren't kept in storage improperly to the point the RTC battery drains 15:22
rbergeron adamw: not this morning yet. /me is on phone in meeting, i will flog shortly 15:22
adamw rbergeron: set whips to stun 15:23
adamw so we're kind of left with the generalized 'some kind of weird oops or the RTC battery ran out' case, really 15:23
VICODAN2 yup 15:23
tflink sounds like a conditional violation of the "needs to boot into graphical env" criterion 15:24
VICODAN2 not a blocker, but a bug none the less, i can think of way more important things to worry about 15:24
Cerlyn Is there any known signs that clock values other than an RTC reset may cause this? 15:24
adamw Cerlyn: well, any value before jan 29th causes it. 15:25
adamw but there's very few reasons to have a system date that wrong that i can think of. 15:25
VICODAN2 good thing it's April 9th 15:25
rbergeron adamw: willdo 15:25
VICODAN2 doesn't NTP start before Gnome? 15:26
tflink assuming you have it turned on, yes 15:26
Viking-Ice in any case I vote -1 on blocker even NTH since this is more an exception than a rule that this happens 15:26
VICODAN2 well, problem solved. 15:26
adamw VICODAN2: ntp isn't enabled by default 15:26
VICODAN2 i know. 15:26
VICODAN2 you have to have dead battery and ntp turned off for this to happen 15:27
adamw but yeah, i think i'm with viking-ice, the cases that are going to hit this are just too corner-y and there's an obvious 'workaround' (fix the darn date) 15:27
VICODAN2 i have a better chance of winning the lottery 15:27
adamw probably +1 final blocker, but -1 beta 15:27
tflink yeah, this seems like a rather hairy failure mode but I'm not sure it's beta blocker worty 15:28
brunowolff It won't be obvious that setting the correct date in the bios is the needed fix. So it would be nice to have this documented with commmon bugs. 15:28
Viking-Ice yeah +1 final 15:28
VICODAN2 +1 15:28
Cerlyn +1 15:28
adamw tflink: gnome's failure modes now are just hairy in general. in gnome2 if g-s-d crashed you got a basically working desktop with fonts and sizes and window theme and so on that you didn't specify. in gnome3 you get the fail whale. progress! 15:28
tflink at least its obvious when something goes wrong 15:29
VICODAN2 can we just move back to gnome 2? 15:29
adamw propose #agreed 809707 is rejected as a beta blocker as we can only think of very few cases which will be hit by it, and there is an obvious 'workaround' (really, the fix): correct the system date 15:29
VICODAN2 i propose a move back to gnome 2 15:29
adamw VICODAN2: not here, you don't. 15:29
adamw :P 15:29
VICODAN2 :( 15:29
tflink adamw: ack 15:30
VICODAN2 its funny 15:30
VICODAN2 you install f17 15:30
VICODAN2 login 15:30
VICODAN2 and you are presented with an empty desktop 15:30
brunowolff I'd prefer to see common bugs suggestion for this one. 15:30
VICODAN2 with like 15:30
VICODAN2 "windows" and "activities" 15:31
adamw brunowolff: stick 'commonbugs' in the keywords list 15:31
adamw VICODAN2: the desktop battles belong on devel list, or desktop list, or really anywhere that's not here. =) 15:31
Martix regarding Test Days, could you approve mail for tomorrow test 15:32
Martix day? 15:32
VICODAN2 it's really terrible, i'll look them up. 15:32
adamw Martix: will do 15:32
Martix adamw: thanks 15:32
adamw any more acks? 15:32
brunowolff For right now I was suggesting ammending the proposal, but if no one has any objections, I'll just mark the bug. 15:32
adamw oh okay 15:32
adamw commonbugs proposing doesn't really have to follow nth/blocker procedure 15:32
Cerlyn adamw: Do we wish to propose it as a final blocker in the same motion, or is that a later vote? 15:33
VICODAN2 it's a final blocker 15:33
brunowolff ack 15:33
adamw you can nominate a bug for commonbugs any time, at your own authority, it's just a 'suggestion' to people who like to update the page 15:33
adamw Cerlyn: i was going to keep it for later just to keep things simple 15:33
adamw it sounds like it'll likely get fixed before we hit final blocker review anyhow 15:33
VICODAN2 yep 15:34
adamw #agreed 809707 is rejected as a beta blocker as we can only think of very few cases which will be hit by it, and there is an obvious 'workaround' (really, the fix): correct the system date 15:34
VICODAN2 also 15:35
VICODAN2 other workaround is use ntp 15:35
adamw anything else anyone's worried about for beta? 15:35
VICODAN2 well 15:35
VICODAN2 let me tell you about my experience yesterday 15:35
VICODAN2 again this is in a vbox vm 15:35
VICODAN2 i install f17 15:35
VICODAN2 im at the end 15:35
VICODAN2 "congratulations fedora is installed!" "remove the cdrom and reboot!" remove cdrom from drive and press reboot and it hangs 15:36
VICODAN2 do hard reset, reboot and im dropped in to a grub shell 15:36
VICODAN2 booted off DVD again, did an upgrade and it was fine 15:36
tflink VICODAN2: have you filed a bug? 15:36
adamw if it's not reproducible and you didn't get logs from the failure, there's not a whole lot anyone can do with that. 15:36
VICODAN2 no. I want to reproduce it again 15:36
VICODAN2 and i was hoping rc4 would drop soon 15:37
tflink VICODAN2: make sure you grab the logs from the failed install 15:37
VICODAN2 so I could report it against RC4 15:37
VICODAN2 well it technically wasn't a "failed install" 15:37
VICODAN2 when is RC4 dropping? 15:37
tflink not sure, we're waiting for blocker fixes 15:38
VICODAN2 so a week? 2 at most? 15:38
tflink the hope is in the next day or two 15:38
VICODAN2 k 15:38
tflink but we're getting a bit off into the weeds for a meeting, here 15:38
VICODAN2 i'll wait for rc4 and try it again 15:39
VICODAN2 how do i grab logs from anacdona/install? 15:39
tflink VICODAN2: can you ask in #fedora-qa, this is getting off topic for the meeting 15:39
VICODAN2 yessir 15:39
tflink thanks 15:39
adamw okay, so, there we are. 15:39
VICODAN2 anything else? 15:39
VICODAN2 i need to get to work 15:40
adamw #info rc4 is waiting on blocker fixes, we are trying to ping responsible parties. 15:40
adamw #topic Test Day report 15:40
adamw VICODAN2: the agenda's at https://fedoraproject.org/wiki/QA/Meetings/20120409 15:40
adamw so we had power management test day - https://fedoraproject.org/wiki/Test_Day:2012-04-04_Power_Management - and installer i18n/l10n test days last week - https://fedoraproject.org/wiki/Test_Day:2012-04-05_L10n_I18n_Installation 15:41
adamw did anyone make it out to those? I suck at attending test days lately. 15:41
VICODAN2 yep 15:41
VICODAN2 i did 15:41
VICODAN2 i did power management day 15:41
adamw how'd they go? 15:41
VICODAN2 pretty good 15:41
VICODAN2 lots of people ran the reports 15:41
VICODAN2 i was impressed as to how well it was actually working 15:42
VICODAN2 f17 was actually able to read my battery info through a virtualbox vm 15:42
VICODAN2 i18n/l10n, didnt attend, dont know anything about it 15:43
adamw looks like we got good turnout for the pm day, yup. 15:43
adamw #info turnout for the power management test day was good, looks like a solid bunch of results - https://fedoraproject.org/wiki/Test_Day:2012-04-04_Power_Management 15:43
Martix it was Open House in Brno office :-) 15:43
VICODAN2 brb, hoppin in the shower 15:44
Martix so many people got involved 15:44
adamw cool 15:44
adamw #info PM test day was open house in Brno 15:44
adamw #info seems to have been solid data in the i18n/l10n installation test day too, but the results table is a little odd, may need tidying up 15:45
adamw #topic upcoming events 15:46
adamw so it looks like we have KDE 4.10 tomorrow and Virtualization on Thursday 15:46
adamw er, 4.8, rather 15:46
adamw #info KDE 4.8 Test Day tomorrow - https://fedoraproject.org/wiki/Test_Day:2012-04-10_KDE_4.8 15:46
VICODAN2 when we say "virtualization" are we mainly concerned with KVM? 15:47
Martix yep, I am looking for your test reports :-) 15:47
adamw #info Virtualization Test Day on Thursday - https://fedoraproject.org/wiki/Test_Day:2012-04-12_Virtualization_Test_Day 15:47
adamw VICODAN2: yep 15:47
VICODAN2 k 15:47
adamw VICODAN2: it means 'fedora virt stack' - see the page 15:47
VICODAN2 yep 15:47
jreznik for kde 4.8 rdieter prepared the image, we are finishing test cases, ltinkl reviewed Martix's testcases, looks good 15:47
adamw so the kde page has test cases but the results table is still generic and no special live images up 15:47
jreznik also some marketing is done 15:48
jreznik adamw: yep, I know 15:48
adamw jreznik: looks like you need to update the image links and results table - cool 15:48
jreznik will be fixed once we will have all testcases 15:48
adamw we'll get the test-ann mail approved 15:48
adamw great 15:48
jreznik adamw: Martix should update the link to image, at least he promised it :) 15:48
adamw #info KDE team is on top of preparation for tomorrow 15:48
Martix jreznik: thanks, but we need finish more test cases 15:48
adamw #info virt test day is taking a freeform testing approach, looks like they have the page set up as they want it 15:49
Martix jreznik: its already updated 15:49
jreznik Martix: ok 15:49
Martix jreznik: waiting for sha256 verification 15:49
jreznik I'd like to combine test cases with freeform tests on the rest topics we don't have a test case 15:49
adamw oh yeah, i just saw the 'tbd' and missed the links, d'oh :) 15:49
adamw jreznik: you can certainly do that if you get enough people in IRC to get the chat flowing 15:50
Martix x86_64 image passed media verification, I'll add sha256 sum, but still downloading i686 image 15:50
Martix or can rdieter provide sha256 sums for his images? 15:51
Viking-Ice VICODAN2, I would go as far to say the only thing we care about kvm ( because it's the only solution we can actually do anything about ) 15:51
rdieter Martix: good idea, I totally forgot about that. 15:51
jreznik adamw: I hope to ge traffic but we completely forgot Easter, so a lot of people still on vacations :) 15:52
adamw ah, well, we'll see :) 15:53
adamw okay, so they're both looking pretty well prepared for, let us know if there's anything we can do to help jreznik 15:53
adamw aside from showing up of course :) 15:53
jreznik adamw: yep, thanks :) Martix is still around, so we have a good fedora qa guy taking care of it :) 15:54
adamw well, i wouldn't say 'good'....<ducks> 15:54
adamw oh, and go/no-go is set for wednesday once more. 15:55
adamw i'm not saying it means anything, just that i've seen World Domination For Beginners in martix's desk drawer 15:55
jreznik adamw: :) I should probably use a different word :) amazing? awesome? :) 15:55
adamw and he keeps sending in expense requests for sharks and lasers 15:55
* jreznik knows Martix for several years... 15:56
Martix adamw: hehe, we must block Fedora Beta release for all costs! </irony> :-D 15:56
adamw :P 15:57
adamw okay, so looks like upcoming events are under control 15:57
* jreznik hopes :) 15:57
adamw #topic AutoQA update 15:57
adamw i'm guessing there's no news here again? 15:57
tflink nope, we've been pretty consumed w/ F17 beta testing AFAIK 15:58
adamw fun. :/ 15:59
adamw #info there is no news. ding. 15:59
adamw #topic Open floor 15:59
VICODAN2 back 16:00
adamw so, i did have one thing for open floor, though we're slightly over time 16:00
VICODAN2 go on... 16:00
adamw i can send a formal proposal to the list, but - it actually occurred to me last week as we were slipping a release for a bug in preupgrade that there's no damn reason to slip releases for bugs in preupgrade. 16:01
adamw even if they're on the anaconda side. 16:01
VICODAN2 that's my bug :) 16:01
VICODAN2 i give you permission to move it to final blocker 16:01
* rbergeron doesn't look at this line 16:01
adamw am i missing anything? or should we just treat all preupgrade blockers as 'special' the way we currently treat livecd-iso-to-disk blockers? 16:01
tflink I assume that the rationale is something along the lines of "as long as some upgrade method works"? 16:02
adamw no 16:02
adamw the rationale is that preupgrade doesn't pull anything from anywhere that goes out as media 16:02
brunowolff That's assuming we know the fix needs to be in preupgrade, not in some f17 package. 16:02
adamw no 16:02
adamw think about it :) 16:02
tflink adamw: the difference in my mind is that most livecd-iso-to-disk bugs can be fixed outside of the release 16:02
adamw what's the problem with testing preupgrade? 16:02
adamw we always have to wait for a stable update push to test it 16:03
VICODAN2 why not just get rid of preupgrade all together? 16:03
adamw it's so annoying...the only way we can test preupgrade blockers is to update the tree on the mirrors...just re-spinning the media doesn't help... 16:03
adamw *gears whirring* 16:03
adamw then why are we blocking media composes on preupgrade bugs? :) 16:03
tflink officially, yes but now that we have a method of testing preupgrade before everything hits stable, it's a little easier 16:03
tflink because preupgrade requires interaction with anaconda, which can't be fixed by updates 16:04
adamw tflink: follow the thought process, though. point is, preupgrade process and media composes are completely independent of each other, effectively. 16:04
adamw yes it can. for preupgrade. 16:04
VICODAN2 look 16:04
adamw preupgrade never uses the anaconda on the media. it always pulls its anaconda from the tree on the repos. 16:04
VICODAN2 you can upgrade via yum right? 16:04
VICODAN2 you can upgrade via dvd right? 16:04
tflink I didn't think that preupgrade pulled from updates, though 16:04
adamw if we ship Beta with anaconda that's 'broken' re preupgrade, and we then push an anaconda update that fixes preupgrade stable, does preupgrade start working? 16:04
tflink I thought that it always pulls from stable 16:04
adamw tflink: there is no updates before release 16:05
adamw there are only two repos for f17 at present: updates-testing and 'stable' 16:05
adamw when we approve an update, it goes to 'stable' 16:05
VICODAN2 lol "stable" 16:05
tflink adamw: updates/updates-testing - not stable was what I was getting at 16:05
adamw tflink: there is no 'updates' for branched releases. the tree is empty. 16:05
VICODAN2 but it pulls from updates-testing by default anyway 16:05
tflink adamw: preupgrade uses the initrd and vmlinuz from the tree 16:05
adamw tflink: right. but that gets rebuilt every day from whatever's in 'stable'. as soon as we push a fixed anaconda, we get a new vmlinuz/initrd on the mirrors. 16:06
tflink we do? 16:06
VICODAN2 lol 16:06
tflink I thought that was only updated on the mirrors @ releases 16:06
adamw i believe so. i might be wrong, of course. 16:06
VICODAN2 again, why do we need preupgrade? 16:06
VICODAN2 last question before i leave 16:06
adamw tflink: no, otherwise we'd never get preupgrade behaviour changes except at alpha, beta and final. 16:07
adamw VICODAN2: in theory, it's a more reliable mechanism than yum. we don't officially support yum upgrades. preupgrade is the supported 'online' upgrade method. 16:07
VICODAN2 i would say let's deprecate preupgrade and make yum the new standard 16:07
VICODAN2 yum works great 16:07
VICODAN2 i've upgraded from 11->12->13->14->15 via yum 16:07
VICODAN2 the only thing 16:08
VICODAN2 is making yum handle the new boot process stuffs 16:08
VICODAN2 which ims sure it could do 16:08
brunowolff You need to know special things to to yum upgrades between some releases, preupgrade is supposed to hide that from you. 16:08
VICODAN2 that's my $.02 16:08
tflink adamw: have we had many changes in preupgrade that required anaconda fixes? the one that I remember from F16 required changes in preupgrade only 16:08
adamw there would not be any support for that from devel side. they are fairly strongly of the opinion that yum is not a supportable upgrade mechanism. it's sidetracking the question of whether preupgrade issues need to block media composes, anyway. 16:08
VICODAN2 no need to hide it 16:08
tflink unless I'm just mis-remembering 16:08
adamw nirik: can you confirm or deny whether i'm right about how branched tree works? 16:09
brunowolff For you maybe. For lots of people yes. 16:09
VICODAN2 well, we aren't getting much "support" from the devel side on preupgrade now are we? 16:09
* nirik reads up. 16:09
VICODAN2 has anyone done any work on this? 16:09
adamw while we're doing that - preupgrade goes out and reads https://mirrors.fedoraproject.org/releases.txt to find out where to get its anaconda from. 16:09
VICODAN2 i found the bug like a month or two ago 16:09
adamw VICODAN2: which bug? there have been like eight preupgrade bugs, in serial. we fix one of them at a time, and keep finding more. 16:10
VICODAN2 f16, preupgrade to 17 16:10
adamw VICODAN2: the current preupgrade blocker was not filed by you. it was filed by me. 16:10
adamw https://bugzilla.redhat.com/show_bug.cgi?id=810391 16:10
nirik adamw: right. there's updates-testing and empty updates, and a 'base' repo. We rebuild the base repo every night with anything thats going to stable. 16:10
VICODAN2 so mine was fixed then eh? 16:10
VICODAN2 all i know is that it's still not working 16:10
VICODAN2 ill check my bug then 16:10
adamw nirik: so say we build rc4 right now, then we get an anaconda that fixes preupgrade tomorrow 16:10
VICODAN2 build rc5! 16:11
VICODAN2 :P 16:11
adamw nirik: whenever that anaconda gets pushed 'stable', preupgrade will start working, right? it doesn't matter that it wasn't in the rc4 compose? 16:11
nirik adamw: I think so, unless preupgrades releases.txt points to the release instead of the f17 devel tree. 16:11
VICODAN2 ok my boss just called me and yelled at me 16:11
VICODAN2 i need to go now, i've caused enough havoc here 16:11
VICODAN2 have fun y'all 16:11
adamw nirik: it uses https://mirrors.fedoraproject.org/releases.txt 16:11
tflink nirik: I didn't think that the devel tree was mirrored in many places 16:11
tflink ie most mirrors use the release 16:12
adamw nirik: what's that pointing to? 16:12
tflink but I could easily be wrong 16:12
brunowolff And if the bug is in preupgrade, that will be fixed in earlier releases. So I am buying that preupgrade should not block composes. 16:12
nirik adamw: correct. that points to whatever we point it at. ;) Right now it points to the devel tree. 16:12
nirik tflink: all mirrors who do rawhide should also have f17 16:12
nirik right now we have: 16:13
nirik (flood coming) 16:13
nirik [Fedora 17 (Beefy Miracle)] 16:13
nirik stable=False 16:13
nirik preupgrade-ok=True 16:13
nirik version=17 16:13
nirik mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-17&arch=$basearch 16:13
nirik installmirrorlist=http://mirrors.fedoraproject.org/mirrorlist?path=pub/fedora/linux/development/17/$basearch/os/ 16:13
adamw brunowolff: well, thinking about it, so far i think it shows that preupgrade shouldn't block alpha or beta composes 16:14
adamw Final may be a different question 16:14
adamw nirik: for final releases, what does preupgrade use? is it using the original 'frozen' release tree, i.e. whatever anaconda we shipped at release time? 16:14
nirik yeah, we do point to releases for final. 16:14
adamw okay 16:14
adamw (though we could probably improve that if we wanted, i guess.) 16:15
nirik mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-16&arch=$basearch 16:15
nirik installmirrorlist=http://mirrors.fedoraproject.org/mirrorlist?path=pub/fedora/linux/releases/16/Fedora/$basearch/os/ 16:15
adamw so, i think i'm right in that alpha and beta composes can disregard preupgrade 16:15
tflink yeah, that makes sense to me 16:15
adamw okay...can anyone else see anything we're not accounting for? 16:15
adamw if everyone's following the logic so far, i'll send a proposal to the list - guess the easiest thing is just to push the preupgrade criterion to final 16:16
tflink sounds like a plan 16:16
nirik I'd be worried if we moved all preupgrade to final tho 16:16
adamw 'all preupgrade'? 16:17
brunowolff Just because it blocks composes doesn't necessarily mean we wouldn't block a release if needed fix for say anaconda hadn't gone to stable. 16:17
nirik well, if we ignore preupgrade for alpha and beta it means at final we would have a nasty set of russian dolls of bugs to try and fix before release. 16:17
adamw nirik: not being blocking doesn't mean it gets 'ignored' 16:17
nirik right. 16:17
adamw nirik: we usually try and do the whole matrix at alpha and beta stages 16:17
adamw but yeah, i take the point 16:18
adamw i guess we can discuss further on list 16:18
nirik just wanted to clarify that it wasn't ignoring it... just not blocking composes. 16:18
adamw thanks for letting me kick that one around :) 16:18
adamw #action adamw to send formal proposal for preupgrade criteria adjustment to the list 16:18
adamw anyone have anything else for open floor? 16:18
robatino long term, the mediacheck needs to be exposed again 16:18
robatino i filed https://bugzilla.redhat.com/show_bug.cgi?id=809663 16:18
robatino right now, it's not discoverable for install discs 16:19
adamw right, i saw that bug 16:19
adamw #info mediacheck is now 'hidden' as it was previously part of loader, it can be prompted with a cmdline parameter but most people won't know that: https://bugzilla.redhat.com/show_bug.cgi?id=809663 16:20
tflink wouldn't the required change be in lorax/pungi? 16:20
* tflink can't remember if pungi does anything with the syslinux menu off the top of his head 16:20
robatino and it might be good to modify the final criteria to require mediacheck (we could do it right now since it's there already) 16:22
robatino just its existence, i mean, not having it done by default 16:22
adamw right, i think we have a dormant list thread about that? maybe wake it up 16:24
adamw okay...anything else? 16:25
tflink I have some other questions about the preupgrade issue, but they can wait for the email thread 16:26
adamw okie dokie 16:26
* adamw sets fuse for 2 minutes 16:26
adamw thanks for coming, all! 16:28
adamw #endmeeting 16:28

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