16:00:42 <adamw> #startmeeting Fedora QA meeting
16:00:42 <zodbot> Meeting started Mon Dec  7 16:00:42 2015 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:42 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:42 <zodbot> The meeting name has been set to 'fedora_qa_meeting'
16:00:47 <adamw> #meetingname fedora-qa
16:00:47 <zodbot> The meeting name has been set to 'fedora-qa'
16:00:50 <adamw> #topic Roll call
16:00:55 <adamw> #info we have apologies from kparal
16:01:02 <adamw> .fire kparal apologies NOT ACCEPTED
16:01:02 <zodbot> adamw fires kparal apologies NOT ACCEPTED
16:01:11 * garretraziel is here
16:01:18 <adamw> anyone else thinking about not attending, want to think again? ;)
16:01:28 <garretraziel> .fire cannon
16:01:28 <zodbot> adamw fires cannon
16:01:48 <tflink> ha
16:02:22 * satellit listening
16:02:50 <garretraziel> (on the cannon-related note, this weekend was 210 anniversary of Battle of Austerlitz)
16:03:48 <adamw> i celebrated by drinking!
16:03:59 * adamw celebrates things every weekend. sometimes he even knows what they are
16:06:13 <adamw> alrighty, seems we're a bit light on numbers but let's go ahead
16:06:32 * Southern_Gentlem 
16:06:44 <adamw> #topic Previous meeting follow-up
16:06:59 <adamw> otherwise known as 'the part of the meeting where adam wishes he hadn't just closed all the tabs with last week's logs in them'
16:07:50 <adamw> alright, so, #info "kparal to look further into the details of go/no-go process and propose a practical policy for changing it to cover blockers fixed by updates" - he did that, we've been discussing it on the list for the last while
16:08:50 <adamw> #info "kparal to check with dnf-system-upgrade maintainers if they're OK with blocking on N+2 upgrades" - he did that and sent a mail with the result: wwoods has no objections
16:08:58 <adamw> any other follow-up from 11-23?
16:09:33 <garretraziel> not here
16:10:26 <garretraziel> but then again, I have memory span of aquarium fish
16:10:47 <adamw> ah, then as a reminder, all the tasks are yours, and you're also running this meeting
16:10:49 * adamw goes fishing
16:11:00 <adamw> oh, which reminds me
16:11:11 <adamw> #chair tflink Southern_Gentlem
16:11:11 <zodbot> Current chairs: Southern_Gentlem adamw tflink
16:11:26 <adamw> #topic Non-media blocker process
16:11:29 <tflink> not sure I like where this is going :)
16:11:43 <tflink> oh, that's not bad
16:12:08 <adamw> So, the discussion about how exactly to change the release process is still ongoing
16:13:01 <adamw> i'm not sure we're ready to take any votes on that
16:13:32 <adamw> however, i figure we could go ahead and interpret the tracking bits at least (i.e. the new magic whiteboard words)
16:13:52 <adamw> all that would really involve is updating the policy pages and updating blockerbugs (the webapp) to handle them - i have a draft patch for that
16:14:31 <adamw> I suggested 'Accepted0Day' (for the pending release's 0-day blugs) and 'AcceptedStable' (for previous release bugs)
16:14:48 <adamw> kparal suggested 'AcceptedPrevious' or 'AcceptedPrevRelease' instead of 'AcceptedStable'
16:15:02 <adamw> anyone got votes on what terms to use, or other options, or reasons we shouldn't go ahead and do this?
16:16:21 <Southern_Gentlem> does it really matter what the varable is called as long as the documentation say what it is ?
16:16:38 <adamw> Southern_Gentlem: nope, not really, i wasn't planning on spending the whole meeting on it :)
16:16:40 <garretraziel> not to confuse anybody who didn't read the documentation I presume
16:16:47 <adamw> but yeah, there is that
16:17:18 <adamw> like how we continually had to explain to people what 'NTH' and 'nice-to-have' meant before we renamed to 'freeze exception'
16:17:37 <adamw> unfortunately none of the three choices is completely obvious in the way 'blocker' anad 'freeze exception' are, but i couldn't think of anything better...
16:18:23 * tflink likes AcceptedPrevRelease
16:19:32 <adamw> it's kind of a bear to type, but it's the most understandable
16:19:41 <adamw> and it's no worse than AcceptedFreezeException in the typing stakes i guess
16:19:43 <Southern_Gentlem> i like your zeroday better than the other
16:20:02 <adamw> Southern_Gentlem: i think we agreed on Accepted0Day, it's the other one that's got multiple options
16:20:19 <adamw> anyone for AcceptedPreviousRelease? :)
16:20:51 <Southern_Gentlem> that is not really clear
16:21:23 <Southern_Gentlem> that will be confusion
16:21:56 <tflink> adamw: I suppose that's just as bad to type and more clear
16:22:10 <adamw> Southern_Gentlem: what do you prefer?
16:22:11 <Southern_Gentlem> accepted stable if they have been fixed unstable if they have not
16:22:13 <tflink> Southern_Gentlem: any thoughts on alternatives?
16:22:22 <adamw> Southern_Gentlem: there are *two* new types of blocker, we need names for both
16:22:46 <adamw> one is blockers that need fixing with a 0-day update for the new release (but don't need to go on the images)
16:22:50 <adamw> that's the one we're calling Accepted0Day
16:23:04 <adamw> the other is blockers that need fixing with an update for the previous stable releases before the new release comes out
16:23:28 <adamw> that's the type we need another name for; the options so far being AcceptedStable, AcceptedPrevious, AcceptedPrevRelease and AcceptedPreviousRelease
16:23:38 <Southern_Gentlem> ok go with the accepted prev
16:23:58 <adamw> that could mean any of the last three choices :)
16:25:09 <adamw> proposal: let's just go with AcceptedPreviousRelease , it's the clearest and not much harder to type than AcceptedPrevRelease
16:25:22 <tflink> +1
16:25:33 <garretraziel> ok, +1
16:25:50 <adamw> ok, i'll take the hit to work on this one
16:26:27 <adamw> #action adamw to come up with draft wiki changes and blockerbugs patch for new blocker handling, using Accepted0Day and AcceptedPreviousRelease as the new magic words
16:27:33 <adamw> i don't see anything we really need to discuss in a meeting regarding the other part of this (changing the release process to ensure the updates actually happen), seems like kparal is in the middle of revising the proposal based on feedback from releng etc
16:27:38 <adamw> does anyone see anything we can help with there?
16:29:02 <adamw> alrighty then, moving on
16:29:14 <adamw> #topic Two release upgrades
16:29:47 <adamw> so another outstanding criteria/validation test proposal is to block on two-release upgrades - i.e. upgrade from F21 to F23, F22 to F24, and so on
16:31:06 <adamw> so far only really me, richard ryniker and sgallagh has responded to that
16:31:10 <adamw> did anyone else have thoughts on it?
16:31:14 <garretraziel> would it be required to do proper two-release (F21 to F23 directly), or would be upgrading one release after the other (F21 to F22 and then F22 to F23) satisfy also?
16:31:47 * adamw brb, call of nature
16:31:55 <adamw> garretraziel: this is about direct two-release upgrades i believe
16:32:11 <adamw> in theory the one-by-one upgrade is what you're supposed to do at present, but in practice i don't know if anyone does.
16:32:20 * satellit what about installs from other repos?  message to not allow it
16:32:56 <satellit> if detected
16:33:22 * tflink thinks its a good idea
16:33:58 * garretraziel also thinks that it is a good idea
16:36:09 <adamw> satellit: how do you mean?
16:36:20 <adamw> satellit: are you talking about issues when you have packages from third-party repos?
16:37:31 <satellit> copr chrome installs
16:37:58 <adamw> that's kinda a separate topic - it affects single-release upgrades just as much
16:38:06 <satellit> k
16:38:15 <adamw> it's worth suggesting any ideas you have to improve how dnf works in that area of course, but doesn't need a meeting discussion i don't think
16:38:40 <adamw> ok, sounds like we just have +1s on this one mostly - it'd be good if folks could post their responses to the list
16:38:43 <satellit> be nice to get a message that they need to be disabled and not start upgrade
16:38:48 <adamw> then kparal can take it forward from there
16:41:03 <adamw> #info tflink and garretraziel are +1 to two-release upgrade support, no other notes
16:41:16 <adamw> alrighty, that's all i had on the agenda
16:41:19 <adamw> #topic Open floor
16:41:22 <adamw> did I miss anything?
16:41:45 <adamw> i guess we should get moving on test days for this cycle soon
16:44:30 * adamw watches dust balls blow by
16:45:21 <adamw> alrighty, sounds like we don't have much!
16:45:50 <adamw> i didn't announce a blocker review meeting for today cos no-one seemed too enthusiastic about doing them this early and there were only a couple of proposed blockers when i looked
16:46:05 <adamw> there are three now, so if anyone feels like it we could go over those quickly in #fedora-blocker-review at the top of the hour
16:46:12 <adamw> or just leave it for next week
16:46:30 * garretraziel will be leaving home, so he cannot attend
16:48:13 <adamw> alrighty then, sounds like we're leaving it for next week
16:48:16 * adamw sets the big fuse
16:48:23 <adamw> i guess everyone's just really excited to get to work, right? :)
16:48:40 <garretraziel> I'm excited to go home :-D
16:48:43 <tflink> darn tootin'
16:49:21 <adamw> garretraziel: ...and continue working? :p
16:49:39 <adamw> garretraziel: thanks for the phab reviews btw
16:49:40 <garretraziel> yeah... something along those lines
16:50:11 <garretraziel> adamw: could you please look at D670, D672 and D673 when you'll have time :-)?
16:50:21 <adamw> yeah, i will - sorry i didn't get to 'em last week
16:50:36 <garretraziel> np, I have other things to do :-)
16:51:02 <adamw> allrighty, seems like we're all done here
16:51:07 <adamw> thanks for coming folks!
16:51:20 <garretraziel> thanks adam
16:51:28 <adamw> #endmeeting