16:00:59 <adamw> #startmeeting Fedora QA meeting
16:00:59 <zodbot> Meeting started Mon Jan 13 16:00:59 2014 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:59 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:03 <adamw> #meetingname fedora-qa
16:01:03 <zodbot> The meeting name has been set to 'fedora-qa'
16:01:09 <adamw> #topic Roll call
16:01:19 <adamw> morning folks, who's around for a nice steaming does of qa meeting?
16:01:23 <adamw> dose, even.
16:01:59 * kparal was just googling for 'does' meaning
16:02:10 <adamw> it means the monkey needs to change keyboards again
16:02:29 <jreznik> jreznik's monkey is here to pretend he's here
16:03:22 * tflink is here
16:03:26 * mkrizek is here
16:04:06 * roshi is here
16:04:25 <cmurf> study finds coffee improves memory
16:04:43 * roshi has fresh coffee
16:04:52 * cmurf takes a sip, vaguely recalls he's human. Maybe.
16:06:09 * pschindl is here
16:06:18 <adamw> cmurf: i guess i should go get some. hum. wonder why there's a dirty coffee cup next to me? can't quite remember.
16:07:27 <jreznik> cmurf: ah, I understand why my memory sucks - I don't drink coffee :)
16:08:03 * cmurf notices he's remembering all sorts of things with each sip.
16:08:12 <cmurf> 9 inch powder day at Winter Park
16:08:18 <kparal> adamw: you mean the one that looks like a whiskey bottle?
16:08:24 * pwhalen is here with coffee in hand
16:08:41 <adamw> kparal: i deny everything
16:08:51 <cmurf> haha kparal
16:09:13 <adamw> #topic Previous meeting follow-up
16:09:23 * roshi imagines a whiskey bottle with a homemade masking tape label reading "Coffee"
16:09:36 <adamw> #info "adamw to send a mail to test@ about the ten year t-shirt thing" - clearly, that happened: https://lists.fedoraproject.org/pipermail/test/2014-January/120006.html
16:09:50 <adamw> roshi: it says "Coffee. Definitely Coffee. Absolutely Not Something Else."
16:10:03 <roshi> ha
16:10:21 <tflink> adamw: that's a long label for a whiskey bottle
16:10:41 <adamw> in the jack daniel's style
16:10:58 <roshi> it wraps around, the more you drink the more the label tells you
16:12:26 <adamw> hehe
16:12:39 <adamw> so obviously we have a topic for the tshirt thing coming up, and we can move on
16:12:48 <adamw> #topic EOL process handling
16:13:36 <adamw> #info there has been a bit of a debate about the EOL (end-of-life) process, which is documented on the Wiki in a QA-ish space (Bugzappers), but which in practice has been handled by the program manager
16:14:05 <adamw> so i thought it was probably wise to stick a topic on the agenda in case we want to change anything there
16:14:23 <kparal> which ML was the debate on?
16:14:24 <jreznik> I still use Bugzappers area, it should be probably changed but for now it works
16:14:26 <adamw> is there a reason we'd want to try and assert 'ownership' of the eol process, or are we ok with the program manager doing it?
16:14:35 * adamw looks for the thread
16:14:54 <jreznik> adamw: I can take care of it, of course with qa and fesco feedback
16:15:05 <adamw> oh, yeah, it was in a non-obviously titled devel@ thread
16:15:35 <kparal> I think EOL process is more program manager thing than QA thing. but I haven't read the thread yet
16:15:43 <jreznik> kparal: yep
16:15:58 <adamw> #info thread started at https://lists.fedoraproject.org/pipermail/devel/2013-December/193094.html
16:15:59 <jreznik> but of course, I'm more than happy to get any feedback from qa and fesco
16:16:24 <adamw> viking-ice's contention is that the process mainly 'affects' people who report bugs, and QA has an interest to ensure they don't feel rejected by it
16:16:33 <adamw> (if i'm not mis-representing him)
16:17:18 <adamw> my personal opinion is that i'm OK with the program manager doing it, as long as it follows a clear-cut policy we can provide feedback on if necessary (which afaik it does)
16:17:32 <cmurf> i thought it was an automated thing
16:17:49 <jreznik> cmurf: it's mostly automated thing, the question is mostly when and what
16:17:55 <cmurf> the comment added that also changes bug status at least looks automated
16:18:00 <kparal> Viking-Ice: what would you do differently, in a nutshell?
16:18:24 <cmurf> i think that automated notice is fairly clear about why the bug is being closed
16:18:55 <kparal> yeah, if there are some proposals to improve the message, let's do it, I don't see a problem
16:19:03 <cmurf> as a bug reporter well before I did anything within QA wasn't adversely affected by those messages; Fedora has a short life, sorta like a fairy, *shrug* it's the way it goes.
16:19:17 <jreznik> well, for f18, we are not going to do big change and with fedora.next we will probably need to revamp it
16:19:44 <cmurf> ahh that makes sense
16:19:50 <jreznik> cmurf: and it's always compromise between what we can fix and what can't be fixed
16:20:14 <jreznik> it's unfortunate to close so many bugs but also it's bad to pretend we will touch them
16:20:21 <jreznik> (or even fix0
16:20:31 <cmurf> well a lot of bug reports aren't that great
16:20:53 <cmurf> i like to think a scant minority of my bug reports are crap, but I know this is a non-zero value.
16:21:47 <Viking-Ice> kparal, EOL belongs with us
16:22:06 <cmurf> seems like it belongs with a bot
16:22:26 <cmurf> you hit the date, the notices go out, the flags are switched - adios
16:22:34 <roshi> is it the kind of thing we could update the message with a link to more wiki instructions, point them to a QA contact
16:22:48 <roshi> then we can triage the experience from there?
16:22:56 <kparal> can't we do that without owning the process?
16:23:01 <roshi> that's what I thought it was cmurf
16:23:05 <Viking-Ice> it has gone through several revisions in our community and it was handle by John originally since he was working on reviving the triage effort not because he was a program manager
16:23:59 <jreznik> roshi: I can do everything you propose with message - just F18 EOL is tomorrow, so I'm going to run my script after the last push
16:24:02 <cmurf> the fact fedora lives for 13 months isn't a QA thing at all, therefore i don't see how bugs having a related EOL becomes QA
16:24:07 <Viking-Ice> kparal, in an nutshell what I would do differently would be to drop this EOL notice altogether and move existing bugs to new release
16:24:24 <cmurf> oh god no please no
16:24:35 <jreznik> Viking-Ice: moving bugs to the new release is part of that but AFTER review!
16:24:42 <cmurf> a LOT of bugs do actually get fixed
16:24:53 <Viking-Ice> cmurf, do you relaize how many reports we have lost due to that bloody thing
16:24:54 <cmurf> whether they're firmware, package, upstream, or user error
16:25:16 <jsmith> Viking-Ice: I think that's a FESCo decision
16:25:16 <jsmith> Viking-Ice: But personally, I'd be against that as well
16:25:31 <Viking-Ice> jsmith, this is not original fesco process is it
16:25:39 <kparal> I also don't think QA can decide this on its own
16:25:47 <roshi> kparal +1
16:25:52 <cmurf> Viking-Ice: yes I do because, i thank sweet jesus every cycle upon getting the 50+ emails telling me about my bugs being closed
16:25:52 <jsmith> kparal: I couldn't agree more
16:25:54 <Viking-Ice> kparal, oh but they can decide this for us
16:25:54 <adamw> https://fedoraproject.org/wiki/End_of_life_SOP does list it under Bugzappers, so we need to straighten that out whichever way it goes.
16:26:07 * adamw looking up the history of the process
16:26:09 <jreznik> Viking-Ice: as I said - it's compromise and better than pretend we will ever fix that bugs and believe me, I'm trying to take a look what I'm closing and sometimes it's sad what I have to close but as there are not enough people to fix bugs...
16:26:23 <roshi> I was just going to ask for some more history adamw
16:26:51 <jreznik> I think it's better to be clear - sorry, we can't fix it instead of pretending we will fix it (and there's still that option to move that bug to newer version if reporter still have energy)
16:26:59 <kparal> old bugs die, new bugs live. fair trade.
16:27:00 <Viking-Ice> jreznik, compromize would be closing this as cant fix
16:27:02 <Viking-Ice> not wontfix
16:27:14 <Viking-Ice> because the maintainer could not fix it
16:27:17 <cmurf> that could be valid
16:27:23 <cmurf> can't vs won't
16:27:37 <cmurf> once it's EOL'd the fix wouldn't be pushed so that sounds like can't
16:27:49 <jsmith> Viking-Ice: To answer your question re: FESCo -- FESCo has the stewardship in Fedora over engineering decisions.  Because this impacts more than just QA, I would say that absolutely yes -- FESCo has the right and power to decide this for us
16:28:11 <jreznik> Viking-Ice: it's can but won't but as I said, I'm more than happy to include any valid feedback, I'll note it for wed fesco
16:28:22 <cmurf> jsmith: yes although i can think of 4 better questions to ask FESCo than this, but okkk
16:29:09 <Viking-Ice> jsmith, to answer your question this was handled by the triagers and had nothing to do with fesco if you still believe so point me to the original report in fesco tracks where it was discussed putting this on in the first place
16:29:32 <jreznik> adamw: for Bugzappers there - after it died, nobody did EOL for a while, but looking on house keeping, john/robyn/me do it forever
16:29:46 <adamw> i'm more interested in when we decided to close bugs at eol
16:29:47 <kparal> Viking-Ice: I always have the idea that you're living in a world with infinite resources, while we others don't
16:29:50 <adamw> (and how)
16:30:39 <jreznik> adamw: it's definitely from john's era and well, it's the only thing to make bugzilla sane
16:30:44 <cmurf> isn't there a notice of EOL and then some time later another notice of it actually becoming EOL?
16:30:44 <Viking-Ice> kparal, not that's WG madness ( infinity resources ) and what do you think I'm trying to do here preventing us from losing newbie reporters which this process has caused us
16:30:57 <cmurf> the bug report i mean
16:31:13 <kparal> Viking-Ice: the problem is that the maintainers often don't reply, no that it is closed
16:31:24 <cmurf> yes
16:31:27 <adamw> jreznik: http://translate.google.com/translate?hl=en&sl=de&u=http://www.linux-community.de/Internal/Nachrichten/Fedora-8-End-of-Life&prev=/search%3Fq%3Dfedora%2Bbugzilla%2Beol%26start%3D20%26sa%3DN%26hl%3Den%26biw%3D1080%26bih%3D1740 has a comment from michael schwendt suggesting it was new in f9
16:31:30 <jreznik> Viking-Ice: so what do you want to do? loose people - as hey, they never fixed my bug and they did not have balls to admit thay can't fix it
16:31:32 <Viking-Ice> kparal, that's one of the problem the fact is people report and report until they get that EOL notice then they leave
16:31:33 <cmurf> maintainers don't reply, very common
16:31:42 <cmurf> they either already know of such bugs and just don't have time for bug management
16:32:07 <jreznik> so this EOL is to poke both reporters and maintainers and let them to react!
16:32:11 <cmurf> or they just don't acknowledge the bug
16:32:30 <cmurf> yeah i think it works fine, i'm unaware of a problem
16:32:39 <Viking-Ice> cmurf, or they dont know how to fix it which is more common then you think ( packagers ) and they dont forward it upstream but we are talking about the EOL process here
16:33:07 <cmurf> i've yet to see users who report bugs with EOL get ants in their pants after the EOL notice. if it's still a bug they say "yoohoo, this is still a bug" and the flip it back to new/assigned or whatever
16:33:22 <cmurf> now maybe that could be made more clear in the EOL notice? how to flip the flag?
16:33:30 <Viking-Ice> cmurf, and I have seen quite opposite for decates
16:33:41 <jreznik> guys, for F18 - reminder has been already sent, so I'm going to run my script this week and I'm more than ok to rework message based on QA/FESCO needs
16:33:51 <adamw> http://johnpoelstra.com/five-months-of-bug-triage/ is interesting
16:34:12 <adamw> suggests the policy of closing bugs came from the bugzappers initiative in the first place, as a cleanup drive
16:34:18 <jreznik> for fedora.next - a lot of stuff would be different, so we can work on improvements (and no, resetting version is not improvement at all ;-)
16:34:28 <jreznik> adamw: yes, it's cleanup
16:34:50 <cmurf> bug search finds these closed bugs right?
16:34:52 <Viking-Ice> "Closing bugs that pertain to release no longer maintained"
16:34:58 <adamw> a default search only searches open bugs.
16:34:59 <cmurf> or are closed bugs excluded from search by default?
16:35:00 <jreznik> it's done even in that super enterprise products people pays for bug fixes and even they have to do it :)
16:35:01 <cmurf> oops
16:35:06 <cmurf> well that could be a prblem then
16:35:12 <cmurf> maybe
16:35:12 <adamw> Viking-Ice: and "Establishing a clear life cycle for the handling of bugs which includes rebasing rawhide bugs at GA and auto-closing bugs open for unmaintained releases "
16:35:40 <jreznik> adamw: that rawhide rebase is re-approved by fesco
16:35:40 <adamw> so there's clearly some 'responsibility clean-up' to be done here at least
16:36:53 <jreznik> adamw: from that blog - "while also establishing better expectations with our users" this is what it is mostly for me
16:36:55 <adamw> #info https://fedoraproject.org/wiki/End_of_life_SOP still shows the bug closure to be the responsibility of 'Bugzappers'
16:37:34 <adamw> #info http://johnpoelstra.com/five-months-of-bug-triage/ implies the history of the EOL process - it was developed as part of the Bugzappers effort and originally done by poelcat with his Bugzappers hat on, not his Program Manager hat
16:37:36 * jreznik offers to work on the process with QA and FESCO feedback
16:38:21 <jreznik> otherwise scripts are open source, so anyone can run them :)
16:38:31 <adamw> is the fesco ticket that was involved here still open?
16:38:48 <jreznik> adamw: it is
16:39:17 <jreznik> https://fedorahosted.org/fesco/ticket/1198
16:39:25 <adamw> okay, so I guess we should post our response there
16:39:41 <jreznik> and scripts are available here https://git.fedorahosted.org/cgit/fedora-project-schedule.git/tree/scripts/closebugs
16:39:50 <adamw> does anyone else support viking's proposal to change the EOL process to rebase all bugs from EOL release to a maintained release?
16:40:06 <adamw> #info EOL scripts are available at https://git.fedorahosted.org/cgit/fedora-project-schedule.git/tree/scripts/closebugs
16:40:11 <kparal> I don't
16:40:33 <jreznik> simple dumb scripts, we've got several complaints but with infra guys we decided not to rewrite them (at least not for now as these cases were limited)
16:40:37 <cmurf> no
16:40:54 <cmurf> i think we're throwing out baby arms with the bathwater, not whole babies
16:41:03 <adamw> thanks for that image, cmurf
16:41:08 * cmurf snickers
16:41:37 <cmurf> It's an imperfect way of dealing with the problem, but a better way seems to require human intervention
16:41:46 <Viking-Ice> adamw, I was not officially suggesting that
16:41:47 * jreznik is ok to handle that process to FESCO or QA or both but he is definitely against rebase without human review
16:41:50 <adamw> does anyone think it's necessary/beneficial for QA to assert 'ownership' of the EOL process itself and take over running it from the program manager (whether we decide it should involve closing the bugs or re-basing them)?
16:42:04 <adamw> Viking-Ice: sorry, i should've explained more clearly what i'm doing
16:42:13 <adamw> i'm working to a proposal for what we should write in a fesco ticket
16:42:26 <adamw> trying to pave the way for a consensus note
16:42:43 <kparal> I think the process is fine with jreznik
16:42:55 <cmurf> I've yet to actually understand the problem, so I just keep hearing about solutions that I can't really agree with, *shrug*
16:42:57 <Viking-Ice> that fesco ticket should be closed and we create a ticket for this in our tracker and take Matt suggestion under advicement
16:43:00 <danofsatx> sorry I'm late
16:43:01 <adamw> i was expecting we'd wind up in a place where the note is 'QA as a whole is fine with the program manager doing the EOL actions, so long as they're following an SOP and there's an avenue for feedback on it'
16:43:33 <adamw> and viking can propose any changes to the process he thinks should happen on his own behalf, for fesco to discuss
16:43:55 <adamw> Viking-Ice: matt's suggestion? and what would the ticket for QA look like?
16:44:32 <Viking-Ice> regarding the program manager this should fall under the QA community member triager/ reporter merged thus being put back in the hands of the community under task we should be performing
16:45:07 <roshi> how is that proposal going Viking-Ice?
16:45:56 <roshi> I think QA being involved in attempting to help reporters keep relevant bugs alive is a good thing for the EOL process - and that can easily be done with a wiki page with up-to-date instructions
16:45:58 <jreznik> Viking-Ice: EOL is cross-functional process and always will be
16:46:15 <adamw> we've been on this for 35 minutes, guys
16:46:36 <roshi> that allows for Viking-Ice's merger proposal and QA involvement where it makes sense for EOL
16:46:36 <jreznik> and if you Volunteer to run that scripts two times per year, do it :)
16:46:38 <Viking-Ice> jreznik, cross functional or not it still belongs with us and we reach out to -devel if when it becomes necessary
16:46:43 <adamw> i'm not sure we're moving anywhere, and it looks a lot like viking has an opinion that no-one else entirely shares
16:46:58 * roshi will write up the wiki page if that's amenable to people
16:47:07 <adamw> roshi: write up what wiki page?
16:47:51 <Viking-Ice> jreznik, I used to have a track ticket containing stuff needed to be done at the beginning and end of each release cycle, then someone had a great idea within RH hired a QA community leader for the QA community which then deleted that ticket
16:47:55 <roshi> updated page pointing people to a QA contact in the EOL message (suggested it a while back in the discussion)
16:48:14 <adamw> ah, missed that.
16:48:23 <adamw> this would be an edit to the EOL SOP page, then.
16:48:29 <roshi> as I see it
16:48:33 <adamw> er, rather, https://fedoraproject.org/wiki/BugZappers/HouseKeeping#End_of_Life_.28EOL.29
16:48:38 <roshi> but I'm new to all this :)
16:49:22 <Viking-Ice> adamw, no worries give it to FESCO and the program manager we invent another process to handle this with resurrection of the triage process
16:49:51 <jreznik> Viking-Ice: that's cool - I still use that HouseKeeping wiki
16:50:00 <adamw> proposed #agreed We will update the FESCo ticket with a note that QA as a whole is not opposed to the current process, so long as we can contribute suggested improvements to the bug closing notices, etc
16:50:10 <Viking-Ice> disagree
16:50:20 <kparal> ack
16:50:32 <tflink> ack
16:50:38 <adamw> #info viking-ice's suggestions that QA should own the process and perhaps drop the closing of bugs on EOL releases is noted but not supported by a consensus
16:50:41 <Viking-Ice> I'll respond myself since the so called RH cant keep this within the community
16:50:59 <Viking-Ice> adamw, I did not officially propose that
16:51:09 <Viking-Ice> I responded to kparal request what I would do
16:51:16 <jreznik> Viking-Ice: it is within community
16:51:21 <adamw> hence 'suggestion' and 'perhaps', rather than 'proposal'.
16:51:25 <roshi> what's not within the community?
16:51:39 <Viking-Ice> jreznik, not within the QA community it's within FESCO
16:51:57 <jreznik> Viking-Ice: and what's FESCO? it's OT now :)
16:51:59 <Viking-Ice> this belongs with us
16:52:39 <adamw> i think you made your argument clear, viking-ice, it's just that afaict no-one *agrees* with it. so i'm trying to move on.
16:52:41 <jreznik> it's coordinated effort between QA and FESCO
16:53:08 <Viking-Ice> I'm not saying we should not make the change suggested but the offical home for this process belongs to us if not I need an list from you yourself or fesco on what does so I can prepare proposal and changes in the QA community with that
16:53:29 * cmurf still doesn't understand the problem, other than his coffee cup is empty
16:53:46 <jreznik> cmurf: same here, just I'm going to have another cup of tea
16:53:57 <adamw> Viking-Ice: i think it would be fine for your proposal to change the triage process to involve the EOL stuff if you like.
16:54:01 <cmurf> I wouldn't want QA to own this because I'm unwilling to say what person or personality in QA should then do that work
16:54:08 <adamw> Viking-Ice: we can always come back to the topic as a part of that, no decision ever has to be a final one.
16:54:11 <Viking-Ice> adamw,  add a request from FESCO and the program manager what they think belongs in the QA community so we can just iron it out then and there
16:54:21 <Viking-Ice> s/from/to
16:54:37 <adamw> i don't think there's anything to gain by asking people to set out hard limits like that without a practical problem to solve
16:54:41 <Viking-Ice> and we can adjust our community of what they think belongs there or not
16:54:55 <Viking-Ice> and any proposal that follows
16:54:56 <adamw> i think you should design your triage proposal however you think it ought to work best, and then everyone can discuss it from there
16:55:12 <Viking-Ice> adamw, I cut out the bits like this
16:55:24 <Viking-Ice> and rework it ( again)
16:55:48 <jreznik> guys, I have to run, my brother is awaiting me
16:55:54 <adamw> it doesn't have to follow the precise contours of who's currently responsible for what - if it makes sense as part of your proposal to make EOL process owned by QA, and we like your proposal, then we can just do that
16:55:58 <adamw> thanks jreznik
16:56:11 * cmurf waves
16:56:13 <Viking-Ice> adamw, oh then you would be fine with it
16:56:14 <Viking-Ice> bullshit
16:56:28 <Viking-Ice> you either think it belongs with us now or you dont
16:56:28 <cmurf> umm
16:56:45 <Viking-Ice> anyway I need to get some fresh air
16:57:00 <adamw> Viking-Ice: not...really. right now the program manager is doing it and that's working fine, so i don't see any point of wasting time and energy to have someone else do it if it doesn't actually improve the process in any way
16:57:15 <adamw> if there's actually some kind of concrete improvement to be gained from the change, that would be a different question
16:57:24 <adamw> but so far you haven't been willing to suggest one
16:57:43 <cmurf> sounds like rearranging the loungey chairs at the local swimming pool
16:58:01 <adamw> we've run for like 40 minutes and there still isn't a completely clear consensus on this, so i guess i'll just try to post a note to the ticket reflecting the discussion, and viking can add his own note\
16:58:13 <adamw> #info adamw will attempt to summarize the discussion for a fesco ticket note
16:58:18 <adamw> #undo
16:58:18 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x2f9fc390>
16:58:41 <adamw> #action adamw to summarize the discussion for a fesco ticket note on https://fedorahosted.org/fesco/ticket/1198
16:58:50 <cmurf> summarize it with stick figures...
16:58:54 <adamw> we're kinda out of time for the t-shirt topic, but...
16:58:59 <adamw> cmurf: being eaten by a t-rex? :)
16:59:05 <cmurf> ya
16:59:09 <adamw> #topic 10 year anniversary t-shirt
16:59:24 <adamw> so it seems some people got their t-shirts already, so i'm not sure we still have time to change the list, but i'll ask about that
16:59:34 <adamw> did anyone have any major concerns about the current list or missing people or anything?
16:59:50 <danofsatx> I want one, but I'm not sure I'm qualified (that's not the right word, but my vocabulary is limited due to lack of coffee)
17:01:20 <yachironi> does anyone involved in the project can have the t-shirt  ?
17:01:26 <cmurf> RFE zodbot - 10 minute timer on #topics with a warning that says to the effect of "this topic has consumed 16% of the meeting time, is it really worth spending more? now?"
17:01:51 <adamw> yachironi: I was asked for "So are we able to list QA people that contributed in a very laudable way along this ten years?"
17:02:16 <adamw> cmurf: having seen the result of FESCo's similar procedure i don't think it'd help much. you just add a side argument about the timing. :)
17:02:32 <adamw> yachironi: so...it was pretty open ended :/
17:03:01 <cmurf> ok well maybe zodbot needs more attitude
17:03:14 <yachironi> and how could we judge that contribution ?
17:03:34 <adamw> yachironi: there are lots of possible ways, i explained how i came up with the list so far in my post
17:04:14 <adamw> welp, we're over time now, so we can continue discussing on the list, i guess
17:04:18 <adamw> #topic open floor
17:04:22 <adamw> anything really important for open floor?
17:04:50 <danofsatx> f21 blockers?
17:04:56 * tflink is trying to find a channel for the qadevel meeting
17:05:06 <adamw> danofsatx: what about 'em?
17:05:19 <tflink> apparently nobody else got the message that fedocal is the master schedule, or I got a message that doesn't exist
17:05:27 <adamw> tflink: i'll shut this down in a minute...if no-one yelled yet, means this channel's probably free till the next hour
17:05:46 <tflink> yeah, but given what happened last week, I'm not sure 1 hour is enough
17:06:04 <tflink> I was thinking about just using #fedora-blockerreview
17:06:28 <danofsatx> sorry, had to take a phone call
17:07:00 <danofsatx> ok, I was just wondering if we're following normal blocking procedures right now since we're nowhere near alpha
17:07:17 <adamw> basically, yep, it's fine to propose blockers
17:07:22 <adamw> we usually start reviewing them a week or so before tc1
17:07:55 <adamw> #info it's fine to propose blockers for f21 already
17:07:57 <danofsatx> ok. selinux is taking a beating so far, as well as nouveau
17:08:11 <adamw> your selinux bug got closed as notabug, you might want to try a relabel.
17:08:45 <adamw> OK, thanks for coming folks, qa-devel meeting is next.....somewhere
17:09:02 <adamw> #endmeeting