16:00:28 #startmeeting Fedora QA meeting 16:00:28 Meeting started Mon Jan 4 16:00:28 2016 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:28 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:28 The meeting name has been set to 'fedora_qa_meeting' 16:00:33 #meetingname fedora-qa 16:00:33 The meeting name has been set to 'fedora-qa' 16:00:36 #topic Roll call 16:00:42 hi everyone! who's around for QA meeting #1? 16:00:45 * garretraziel is here 16:00:54 * kparal is here 16:00:56 * lbrabec is lurking 16:01:32 * pschindl is here 16:03:56 so, apparently there was some sort of giant tsunami last night and all that's left is vancouver and brno? :) 16:04:54 yeah, the tsunami froze solid on the borders of the czech republic, I'd say 16:04:58 phew, so we got lucky again 16:06:35 well, i guess we should send out a boat with some fivebeers or something 16:06:54 tflink: ahoy? did the white whale get you? 16:08:26 ah well, let's do what we can then. 16:08:30 #topic Previous meeting follow-up 16:09:34 #info there were no action items from the previous meeting; a few interesting topics that maybe need looking into, but nothing will have changed in those during the shutdown 16:09:56 #topic Non-media blocker status update 16:10:17 #info patch for blockerbugs is still not merged 16:10:26 #action adamw to work with tflink and get that done 16:10:37 kparal, where are we on the 'enforcement' side of things here? 16:11:07 #chair kparal garretraziel 16:11:07 Current chairs: adamw garretraziel kparal 16:11:20 I haven't moved it since I left for PTO in Christmas 16:11:27 *December 16:11:42 will look at it again 16:11:42 * satellit sorry i am late 16:12:48 adamw: I thought you were going to rework some of that blockerbugs patch 16:13:59 tflink: i thought you were 16:14:00 :P 16:14:55 this may explain why it isn't done 16:15:14 kparal: you weren't around for the last meeting IIRC, so can you give a quick summary anyhow? 16:15:20 looking at the proposal thread, I sent the last email, but nobody replied 16:15:36 I'll try to remember :) 16:16:27 I think (hope) that we mostly agreed with releng that a new tool can be created, which will ensure that mirrormanager will drop any old metadata hashes in the metalink 16:16:48 which will ensure that only the push containing _the important update_ will be served to our users 16:17:20 by push meaning updates repo tree 16:17:20 at least, ones using the metalink. 16:17:49 yes. if somebody uses a hardcoded repo, we have no way of influencing that 16:18:23 so, that's just a solution to one issue that came up while discussing the overall approach, right? 16:19:03 do we have an agreement with releng on approximately what the actual approach is going to be, yet? 16:19:20 I think that was the major issue, are there more of them? 16:21:20 it's true that I'm mainly speaking about making sure AcceptedPreviousRelease blockers get pushed. for anything related to the Branched release, I think there are no such timing issues 16:21:30 and we will be able to track all of this with the new keywords 16:22:28 i wasn't sure if we all agreed yet on what actually happens if we hit go/no-go and there are outstanding non-media blockers. 16:23:24 i.e. do we always slip, or does it depend on what exactly the status of a fix is, all that kind of stuff 16:23:25 yes, that's true. most people claimed we should postpone a week and don't try to introduce shorter delays 16:24:52 I was mostly concerned about the prevrelease blockers, and I haven't really discussed the stuff you just mentioned 16:25:03 but I agree it's also important 16:25:08 i guess ultimately what i'd be expecting is a draft of changes to the relevant wiki pages - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process , https://fedoraproject.org/wiki/Go_No_Go_Meeting , possibly the blocker review meeting SOP - that describes exactly what we do 16:25:19 OK 16:26:09 so sounds to me like the status is, we've agreed on a resolution for a technical issue that needs to be fixed for us to implement a reasonable process here, but we still haven't come up with an agreed proposal for the full process 16:26:13 accurate? 16:26:39 I believe so 16:26:53 ok 16:27:02 are you ok with continuing to work on that? 16:28:16 I'll ping releng and try to get their approval for the prevrelease blockers push process, because while I believe we agree, it hasn't been totally clear 16:29:07 about all the other processes, I don't know, I can work on it I guess. it's not really my cup of tea, but I can try ... :) 16:30:05 ok, well, let's split it into two #action's, and then if it turns out we'd rather spread the load, we can do that easier next week 16:31:15 how does: #action kparal to work with releng and mirrormanager devs to implement 'erase stale metadata' tool for ensuring PreviousRelease blocker-fixing updates will be served 16:31:16 sound? 16:31:19 for the first one 16:31:28 thumbs up 16:32:09 #action kparal to work with releng and mirrormanager devs to implement 'erase stale metadata' tool for ensuring PreviousRelease blocker-fixing updates will be served 16:33:08 and for the other: #action kparal to work on drafting proposed changes to the blocker process pages to define the rules for handling non-media blockers (when we slip, how long for, etc.) 16:33:09 ? 16:33:17 ok 16:34:11 #action kparal to work on drafting proposed changes to the blocker process pages to define the rules for handling non-media blockers (when we slip, how long for, etc.) 16:34:53 so yeah, if we need to offload that to someone else, we can, don't worry :) there is still time, as I think it's unlikely we'd have either type of blocker for alpha. 16:35:05 they're more likely to appear at beta, for upgrades. 16:35:34 anyone else got any notes on non-media blockers before we move on? 16:35:44 nothing from me 16:36:15 !!! it lives! 16:36:22 :P 16:36:33 alrighty then 16:36:43 #topic Two release upgrades 16:37:36 the status here is that people mostly agreed, and we should probably push a note about this into packaging guidelines 16:37:49 yep, sounds right 16:37:50 which is probably another action item for me 16:38:24 I'm just not sure whether I should not ask FESCo about this after all, since we seem to be changing just about all parts of Fedora for this 16:38:25 we'd also need test cases; i can work on that, since the upgrade test cases use my wiki template stuff 16:38:37 (or did we do test cases already?) 16:38:51 kparal: the packaging guideline changes have to go through FPC, iirc 16:39:03 either FPC or fesco; those pages are protected and you have to submit a ticket and usually defend it in a meeting 16:39:36 so i guess the question becomes, does it make sense to add the criterion before we get the packaging guidelines changed? 16:39:39 yes, I'm just not sure if "people seem to agree" from my person is a good enough reason for FPC 16:39:43 we will see, I guess 16:39:59 well, the justification would be the same one as the justification for having the criterion, right? 16:40:20 yes, I suppose the same 16:40:35 i'd suggest probably we should do the guideline change before implementing the criterion, as if FPC says 'no, we don't want to support that', it doesn't make sense to have it as a release criterion...agree? 16:41:01 yes 16:41:07 but we could add the test cases without waiting on the guidelines/criteria, and just mark them optional for now 16:41:10 OK 16:41:17 sounds good 16:41:30 I'll create a ticket for FPC 16:41:37 OK 16:41:45 again, if you're snowed under, we can redistribute next week 16:42:04 #action kparal to propose packaging guideline changes for N+1 upgrades to FPC 16:42:22 we are snowed under, but just literally :) 16:42:28 #action adamw to create N+1 upgrade test cases and add them to the test matrix as 'optional' for now 16:42:29 hehe :) 16:42:30 action item is ok 16:42:45 anything else on this, anyone? 16:43:43 nothing from me 16:44:20 nope 16:44:25 allllrighty 16:44:27 #topic Open floor 16:44:54 so a couple for openQA nerds: openQA prod is down right now I think because the disk is full, looks like gru isn't deleting stuff as it should be 16:44:56 i will look into that 16:45:56 openQA didn't report 20160103 results to the wiki, apparently, i thought that should be fixed, i'll look into it too. 16:46:06 #action adamw to fix up all openQA's craziness 16:46:55 :-) 16:47:17 did GRU worked for us in the past? 16:48:11 I'm not sure, but we've been blaming sqlite back then 16:50:27 garretraziel: it worked for me when i tested it very manually on happyassassin when i was looking into it 16:50:36 but we've never actually checked it worked in production on pgsql, no 16:50:48 so, i guess i get to find out why it isn't working.. 16:50:53 as for result submission: 16:50:54 Jan 03 15:45:28 openqa01.qa.fedoraproject.org fedora-openqa-schedule[4811]: ValueError: need more than 1 value to unpack 16:50:58 i'm pretty sure i fixed that 16:51:16 but now i haven't touched any of this stuff for two weeks i don't remember where :) 16:52:26 (it's the rsplit() on the test 'flavor' - the code assumes it'll always split into two pieces, but one flavor is 'universal', which doesn't...) 16:53:14 anyhow, i know what i'm gonna be doing today, i guess 16:53:18 anything else for open floor, folks? 16:54:22 not from me 16:54:51 nope 16:55:22 alrighty 16:55:25 happy new year, everyone! 16:56:01 as a quick reminder, the wiki Meetings page is no longer going to be updated with links to each week's minutes, as you can easily get them from meetbot; by popular demand i'll keep mailing the minutes out to test@, though. 16:56:55 * adamw sets the happy new year quantum fuse 16:57:34 new year! http://i.imgur.com/gPg2uLW.jpg 16:58:17 hehe 16:58:23 thanks for coming, everyone! 16:58:25 #endmeeting