16:02:33 <poelcat> #startmeeting Fedora 14 Beta Blocker Meeting
16:02:33 <zodbot> Meeting started Fri Sep 10 16:02:33 2010 UTC.  The chair is poelcat. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:51 <poelcat> #topic roll call
16:02:54 <poelcat> who do we have today?
16:02:58 <jlaska> hello :)
16:04:03 <poelcat> adamw and any folks from devel?
16:04:16 * nirik is busy, but lurking.
16:04:20 <adamw> oh, it's this time already?
16:04:21 * jlaska looking for Oxf13
16:04:29 * adamw here
16:04:51 * jsmith is here
16:05:37 <poelcat> #info attendees nirik adamw jlaska poelcat jsmith
16:05:45 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=608992
16:05:57 <buggbot> Bug 608992: medium, low, ---, dhuff, NEW, Add "Boot system with basic video driver" option at the initial screen
16:06:37 <adamw> i updated this one yesterday
16:06:40 <poelcat> it's approved, looks like we're just waiting?
16:06:48 <poelcat> anything to discuss?
16:06:54 <adamw> yeah, waiting for the new build
16:07:00 <adamw> not really, i'll try and make sure this one goes ahead soon
16:07:01 * jlaska didn't hear back from huff, but I saw that Bruno offered to do the build
16:07:25 <poelcat> #action https://bugzilla.redhat.com/show_bug.cgi?id=608992 waiting for a new build, needs to happen soon
16:07:25 <jsmith> OK... sounds great to me
16:07:27 <buggbot> Bug 608992: medium, low, ---, dhuff, NEW, Add "Boot system with basic video driver" option at the initial screen
16:07:34 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=621027
16:07:44 <buggbot> Bug 621027: medium, low, ---, tcallawa, NEW, Graphical screen in anaconda shows F-13
16:08:08 <poelcat> no update since last meeting
16:08:11 <jlaska> My follow-up from last week is inprogress here
16:08:27 <jlaska> new criteria should be added shortly (likely this afternoon) to accomodate this as a Beta blocker
16:08:29 <adamw> mizmo's in -devel
16:08:31 <adamw> we can try and pull her in
16:08:42 <jlaska> perhaps we should ch ... what the good man adamw said! :D
16:08:59 <poelcat> jlaska: i thought the criteria you proposed only applied to alpha and final ?
16:09:24 <jlaska> poelcat: they do, but this issue would fit into the Alpha criteria
16:09:36 <jlaska> lemme check the wording again
16:09:45 <poelcat> but we're discussing beta
16:09:46 <jsmith> I thought at Alpha we decided that this wasn't an alpha thing, but a beta blocker instead?
16:09:53 <poelcat> lol
16:09:54 * jsmith is one confused caveman today
16:10:00 <jlaska> F-14-Alpha - "The default Fedora artwork used must either refer to the current
16:10:04 <adamw> anything that's an alpha blocker is also a beta blocker
16:10:04 <jlaska> Fedora release under development (Fedora 14), or reference an interim
16:10:06 <jlaska> release milestone (e.g. Alpha or Beta).  If a release version number is
16:10:10 <jlaska> used, it must match the current Fedora release under development."
16:10:10 <jlaska> poelcat: Beta includes ... yes that
16:10:11 <adamw> and anything that's an alpha or beta blocker is also a final blocker
16:10:37 <adamw> the first beta criterion is "All Fedora 14 Alpha Release Criteria must be met "
16:10:54 <poelcat> okay
16:10:59 <poelcat> what is proposed next #action ?
16:11:12 <jlaska> let's see if mizmo can join
16:11:16 <adamw> she says she's busy
16:11:17 <jlaska> oh, she's busy
16:11:38 <jlaska> so action is to follow-up with someone from design-team, noting that the change deadline is 2010-09-14?
16:11:44 <adamw> i've asked her to update the bug when she's less busy
16:11:47 <adamw> sounds reasonable, yes
16:11:53 <jlaska> rockin
16:12:13 <poelcat> #chair jlaska adamw
16:12:13 <zodbot> Current chairs: adamw jlaska poelcat
16:12:53 <poelcat> #action https://bugzilla.redhat.com/show_bug.cgi?id=621027 asking mizmo to update the bug and remind design team of change deadline on 2010-09-14
16:13:08 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=628239
16:14:26 <jlaska> I can also add some test feedback to this using the TC1 images
16:14:43 <jsmith> I think that's what we need on this one -- more feedback
16:14:45 <adamw> cool. yeah, we still need to test this one
16:15:15 <adamw> sorry i didn't get to it yet :(
16:15:45 <poelcat> so we're still debugging?
16:16:22 <jsmith> That's what it sounds like
16:16:23 <jlaska> I'm confused
16:16:25 <adamw> mostly we want to verify the bug exists as described, then we can figure out where it needs fixing
16:16:26 <jlaska> it's still in NEW
16:16:29 <jlaska> okay
16:16:31 <jlaska> adamw: thanks
16:16:42 <bcl> I have hardware, but it is my main desktop. I can take a look at it with the Beta TC1 this afternoon.
16:16:53 <jlaska> bcl: hey there :)
16:18:13 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=628239 need to continue debugging before we can figure out where it needs to be fixed
16:18:37 <adamw> sounds good
16:18:48 <poelcat> do we need more heat/urgency on this bug?
16:19:01 <adamw> i'm not too worried as it's likely to be a fairly simple fix
16:19:08 <adamw> probably a one or two-liner in anaconda
16:19:14 <adamw> but we should definitely take care of it for next week.
16:19:15 <jlaska> bcl ^^ ?
16:19:22 <poelcat> good to know :)
16:19:39 <adamw> i think any of us in qa could probably do a lot of the shovel work on this one, it's not *too* complex an issue
16:20:05 <poelcat> #action https://bugzilla.redhat.com/show_bug.cgi?id=628239 need to continue debugging before we can figure out where it needs to be fixed
16:20:22 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=629719
16:20:30 <bcl> I never predict the extent of potential change :)
16:20:38 <adamw> heh
16:21:00 <bcl> But on the surface it doesn't look terrible
16:21:25 <jlaska> bcl: thanks
16:21:33 <bcl> np
16:21:50 <jlaska> so ... #topic bug is certainly a bug ... but unfortunate as it sounds like we won't get much more failure information
16:22:25 <jsmith> Yeah...
16:22:25 <jlaska> BIOS RAID testing will be included in current TC1 test run, so we'll have some idea whether this bug is device specific, or affects all BIOS RAID
16:23:07 <adamw> i have BIOS RAID on this laptop but can't really afford to reinstall it right now unfortunately
16:23:49 <jlaska> poof, and he appears!
16:24:18 <adamw> no, i was here already
16:24:26 * dlehman resists the urge to turn and run
16:24:32 <jlaska> adamw: heh
16:24:33 <poelcat> which bug are we on?
16:24:41 <jlaska> # topic
16:25:11 <poelcat> okay, i wasn't sure if we had gone back to discussing the previous one
16:25:17 <adamw> i think this is still clearly a blocker but in danger of being closed as INSUFFICIENT_DATA if we can't reproduce in tc1 testing
16:25:29 <jlaska> dlehman: anything insanely obvious looking at the traceback ?
16:25:34 <jlaska> dlehman: https://bugzilla.redhat.com/show_bug.cgi?id=629719#c0
16:25:36 <buggbot> Bug 629719: medium, medium, ---, anaconda-maint-list, NEW, FormatCreateError: ('invalid device specification', '/dev/md127p3')
16:25:40 <dlehman> right. I think it involves his biosraid getting resynced
16:26:28 <dlehman> the only thing I have so far is a theory that the resync is leading to some kind of deadlock which is preventing parted from writing the partitions to disk/os
16:26:45 <jlaska> but hard to know without the data
16:27:05 <dlehman> right
16:27:10 <jlaska> poelcat: I think adamw correctled summed up the next steps then
16:27:15 <jlaska> _ correctly_
16:27:57 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=629719 attempting to reproduce. If we cannot do so with TC1 testing will close INSUFFICIENT_DATA
16:28:00 <poelcat> ack/nak ?
16:28:15 <buggbot> Bug 629719: medium, medium, ---, anaconda-maint-list, NEW, FormatCreateError: ('invalid device specification', '/dev/md127p3')
16:28:15 <jsmith> ACK
16:28:24 <jlaska> ACK
16:28:30 <adamw> yo
16:28:36 <poelcat> #action https://bugzilla.redhat.com/show_bug.cgi?id=629719 attempting to reproduce. If we cannot do so with TC1 testing will close INSUFFICIENT_DATA
16:28:41 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=630490
16:29:27 <poelcat> maintainer knows what's wrong, no indiciation on a timeframe for a fix
16:29:30 <poelcat> does anyone else know?
16:29:43 <poelcat> know = timeframe for a fix
16:29:59 * jlaska looking
16:30:04 <adamw> lennart usually deals with issues quite fast
16:30:33 <adamw> but if we accept this we should mention the change deadline in the comment
16:30:42 <jlaska> he's around now if needed I believe
16:30:46 <jsmith> He's in -devel
16:30:47 <adamw> note this is not an AcceptedBlocker yet, it's a newly proposed one we need to evaluate
16:30:59 <adamw> he's always logged in but often takes some time to respond to IRC, note
16:31:11 <jsmith> It sounds to me like something we should probably accept, though.
16:32:10 <jlaska> hard to say, very little info other than the steps to reproduce
16:32:15 <adamw> it doesn't hit any of our existing criteria afaik, but i'd agree it's quite blocker-y.
16:32:23 <adamw> jlaska: what it basically means is that it's very hard to *really* disable any service
16:32:31 <jlaska> right
16:33:03 <adamw> bus activation is one of the features of systemd, it means if something tries to talk to the app associated with a given service, that service gets started
16:33:16 <jsmith> Which isn't always what you want :-(
16:33:19 <adamw> apparently, explicitly turning a service off with systemctl disable isn't stopping this
16:33:31 <jlaska> okay, I see
16:33:36 <adamw> (though it's not 100% clear from the report whether this is a general issue or something specific to NM)
16:33:41 <jlaska> wasn't sure if this was specific to the reporters setup/configuration/system etc...
16:34:14 <adamw> i doubt it is
16:34:18 <adamw> given the nature of the issue
16:34:52 <jlaska> so how to proceed, leave on the list, and note the change deadline
16:35:22 <adamw> the criteria issue is a bit icky. anyone have a great criterion proposal?
16:35:55 <jlaska> well ... can we tie this to the feature somehow
16:36:03 <jlaska> instead of getting specific about how systemd should work?
16:36:33 <jsmith> "A systems administrator should be able to disable a service such that it doesn't start up automatically"
16:36:36 <adamw> that just turns it into a bigger problem we already know about: we haven't really integrated the feature and blocker processes :)
16:36:38 <jsmith> Is that too general?
16:37:02 <jlaska> adamw: true
16:37:23 <adamw> jsmith: it's possibly a little vaguely phrased, this may be one where we have to get legalistic on the language...it may be best to follow it up on the list
16:37:38 <jsmith> Definitely one for the list
16:38:09 <adamw> this feels to me like it could get messy, so yeah, let's say we want to accept it as a blocker but it will require a new criterion or some process improvement, and we should follow up on the list
16:38:23 <jsmith> WORKSFORME
16:38:50 <mezcalero> adamw: i am here now
16:39:12 <jlaska> mezcalero: welcome!
16:39:21 <mezcalero> jlaska: thanks
16:39:56 <adamw> hi lennart
16:40:18 <adamw> we're mostly done with the #topic bug now, but can you confirm that it's as stated - it will affect all bus-activated services?
16:40:47 <mezcalero> oh jeez i hate copy paste on the n900
16:41:38 <adamw> mezcalero the uber-geek
16:41:58 <mezcalero> adamw: well, it affects all of them
16:42:01 <adamw> it's the bug about networkmanager getting started by bus activation even if you do 'systemctl disable NetworkManager.service'
16:42:06 <mezcalero> but that's not really a prob i think for most of them
16:42:16 <mezcalero> after all bus services used to be always enabled
16:42:32 <mezcalero> the new prob is NM and Avahi which didn't use to be bus-activatble but now are
16:42:40 <mezcalero> adamw: but if have a fix ready for this one
16:42:43 <adamw> so this is probably the most problematic case in practice
16:42:44 <mezcalero> and it's almost commited
16:42:45 <adamw> ?
16:42:47 <adamw> great
16:42:49 <mezcalero> it's a oneliner
16:43:02 <mezcalero> well, the bug is a problem only for avahi and NM
16:43:08 <adamw> ok
16:43:13 <mezcalero> because those are the only ones that got converted to bus activation
16:43:28 <adamw> cool
16:43:36 <adamw> if you could commit the fix asap that'd be very useful
16:43:44 <mezcalero> not from the tram ;-)
16:43:47 <adamw> obviously :)
16:43:57 <adamw> just asap as in 'in the next day or two;
16:44:00 <adamw> '
16:44:22 <mezcalero> yepp, tonight
16:44:25 <adamw> cool
16:44:40 <adamw> poelcat: do we have any more systemd bugs coming up or can we let lennart go?
16:44:52 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=630490 fix is in hand, maintainer expects to build new package tonight
16:45:00 <buggbot> Bug 630490: medium, low, ---, lpoetter, NEW, disabled units still get bus activated
16:45:03 <poelcat> adamw: let me look
16:45:15 <adamw> ACK on the action
16:45:28 <jsmith> ACK
16:45:30 <jlaska> +1
16:45:36 <poelcat> #action https://bugzilla.redhat.com/show_bug.cgi?id=630490 fix is in hand, maintainer expects to build new package tonight
16:45:42 <poelcat> we have 2 more systemd bugs
16:45:48 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=630781
16:46:01 <buggbot> Bug 630781: high, low, ---, kernel-maint, NEW, systemd hangs on "Clocksource tsc unstable" error and causes the system to freeze after cpu-scaling detection
16:46:11 <adamw> this doesn't appear to be a systemd bug at all
16:46:26 <poelcat> adamw: that is the current component
16:46:30 <adamw> oh wait
16:46:32 * adamw misremembered
16:46:47 <adamw> it probably is one
16:47:09 <adamw> okay, i remember now...as lennart's last comment indicates we really don't have enough info on this yet
16:47:32 <adamw> essentially all we know right now is that for some reason the reporter's system doesn't boot, we don't have any real handle on the reason.
16:48:09 <poelcat> adamw: should this bug be accepted as a blocker?
16:48:20 <adamw> poelcat: i don't think we can say yet
16:48:34 <adamw> we need to know the cause of the hang to determine if it's a one-system outlier or some kind of more worrying bug
16:48:53 <adamw> mezcalero: agree?
16:49:50 * mezcalero reads backlog
16:50:03 <poelcat> adamw: what are proposed next action(s) then?
16:50:30 <adamw> poelcat: well, ask reporter for more info, but lennart already did that; all we can really do is mention deadlines to try and inject a sense of urgency :D
16:50:43 <adamw> keep it on the F14Beta list for now but don't tag as AcceptedBlocker
16:51:03 <poelcat> adamw: if we don't have info by what point would we punt on it if we haven't had any other reports?
16:51:16 * jlaska suggested next week
16:51:23 <jlaska> s/ed/s/ :)
16:51:32 <adamw> we usually kick it around for two or three meetings before doing that
16:51:36 <adamw> yeah, next week sounds reasonable
16:51:50 <mezcalero> so, this bug could be systemd butt aalso might not actually be a systemd but
16:51:54 <mezcalero> bug
16:52:03 <jsmith> OK
16:52:17 <adamw> right, as i said, all we know is, something ain't working =)
16:52:19 <mezcalero> and it might be completely unrelated
16:52:24 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=630781 really need more information from reporter; if no further information or similiar reports by next week, will consider dropping
16:52:31 <poelcat> ack/nak/patch
16:52:33 <adamw> ack
16:53:03 <mezcalero> i think the reason it got assigned to sytemd is because that's the fashionable thing that might break
16:53:13 <jsmith> ACK
16:53:24 <poelcat> #action https://bugzilla.redhat.com/show_bug.cgi?id=630781 really need more information from reporter; if no further information or similiar reports by next week, will consider dropping
16:53:32 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=631620
16:53:38 <buggbot> Bug 630781: high, low, ---, kernel-maint, NEW, systemd hangs on "Clocksource tsc unstable" error and causes the system to freeze after cpu-scaling detection
16:53:41 <buggbot> Bug 631620: medium, low, ---, lpoetter, NEW, ordering cycles exist (+ breaking them deletes wrong services)
16:53:59 <mezcalero> not necessarily because it really has anything todo with
16:54:55 <mezcalero> for the hal/kde cycle i have discussed a fix today with kay
16:55:49 <mezcalero> we'll just avoid the whole ordering mess and make hal bus activatable. while that might appear a big change i don't think it actually is
16:56:15 <mezcalero> i.e. ubuntu ships hal bus activatable since two releases
16:56:32 <adamw> is this bug perhaps getting confused because the bug about hal not starting up correctly under systemd is affecting people?
16:56:43 * adamw can't get much of a handle on the exact bug here from the comments
16:56:52 * jlaska still reading
16:56:56 <mezcalero> so i am planning to upload hal with the necessary changes this WE
16:57:29 <mezcalero> this fix will require no code changes and does more than fixing this bug
16:57:43 <adamw> what is the change, exactly? a hal config option?
16:57:48 <mezcalero> but it is desriable anway and by side-effect should fix this bug too
16:58:20 <mezcalero> placing a dbus bus activation file and a native systemd .service file in the rpm
16:58:24 <mezcalero> that's all
16:58:38 <mezcalero> it would then only be started on demand
16:58:59 <adamw> for something like hal that seems pretty reasonable
16:59:03 <mezcalero> i.e our halsectomyfor gnome would benefit from that
16:59:13 <mezcalero> and kde would continue to work
16:59:35 <adamw> any worries about the approach from the devel side?
16:59:53 <mezcalero> and again, hal is bus activated in ubuntu, and has been for a while, so this should be fairly well tested already
17:00:34 <mezcalero> and given that hal is awfully slow the gnome users among us should rejoice by this fix
17:00:58 <adamw> i was asking the rest of the meeting =) it seems good to me
17:01:08 <jlaska> any testing you'd want before this fix is in?
17:01:20 <jlaska> or just everyone jump on it when the updated packages are available
17:02:26 <mezcalero> well, testing by one or two kde users would be good
17:02:44 <mezcalero> but i dont think this change would require a lot of testing
17:02:45 * nirik reads up. Notes that Xfce still uses hal as well.
17:03:04 <jlaska> nirik: good point
17:03:16 <mezcalero> but of course i am a hopeless optimist ;-)
17:03:16 <jlaska> any other considerations for xfce, lxde?
17:03:23 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=631620 fix and new packages anticipated this weekend, needs testing by kde, xfce and other desktops depending on HAL
17:03:27 <buggbot> Bug 631620: medium, low, ---, lpoetter, NEW, ordering cycles exist (+ breaking them deletes wrong services)
17:03:33 <poelcat> ack/nak/patch
17:03:35 <adamw> lemme see...is it possible for things to access hal by a method *other* than dbus? i.e. could something want to use hal in a way that wouldn't trigger it to be started by bus activation?
17:03:44 <nirik> I have not noticed any problems... hal is runnign here, xfce4-battery-manager works fine...
17:03:46 <mezcalero> poelcat: sounds good
17:03:58 <nirik> poelcat: sounds good here.
17:04:26 <mezcalero> adamw: no, only dbus, and ubuntu never had probs with this
17:04:36 <mezcalero> adamw: afaik at least
17:04:38 <adamw> mezcalero: ok
17:04:41 <adamw> ack then
17:05:05 <poelcat> #action https://bugzilla.redhat.com/show_bug.cgi?id=631620 fix and new packages anticipated this weekend, needs testing by kde, xfce and other desktops depending on HAL
17:05:06 <mezcalero> adamw: if you want to be extra sure it might make sense to browse through launchpad or so
17:05:20 <buggbot> Bug 631620: medium, low, ---, lpoetter, NEW, ordering cycles exist (+ breaking them deletes wrong services)
17:05:25 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=632489
17:06:09 <jlaska> yay, tc1 bugs
17:06:42 <jlaska> clumens indicates this might be part of a known pycurl issue?
17:06:53 <jlaska> dlehman: bcl: any thoughts from you guys?
17:07:28 <mezcalero> anything left to discuss regards systemd? my attention require any longer?
17:07:34 <bcl> looking...
17:07:35 <mezcalero> required
17:07:37 <adamw> i think that's it for systemd...
17:07:43 <mezcalero> awesome
17:08:11 <adamw> someone just reported 632489 to -devel btw
17:08:13 <jlaska> rhe correctly links to the appropriate criteria affected "The installer must be able to use the HTTP, FTP and NFS remote package
17:08:17 <jlaska> source options"
17:08:20 <adamw> so obviously it's not a one-off =)
17:08:25 <adamw> seems like a clear blocker to me
17:08:42 <jlaska> yeah
17:09:21 <dlehman> agreed
17:09:31 <jsmith> ACK
17:10:25 <bcl> no additional thoughts on it here.
17:10:31 <jlaska> bcl: okay, thanks
17:10:34 <poelcat> what are the next actions for this bug?
17:11:04 <jlaska> remind about the change deadline and then I think it's in rvykydal's hands?
17:11:30 <adamw> poelcat: anaconda team to fix it :D
17:11:49 <adamw> jlaska: change deadline doesn't really apply to blocker bugs, though of course the earlier the fix the better
17:12:03 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=632489 accepted as a blocker, fixed needed no later than 2010-09-14
17:12:06 <adamw> the 'deadline' for blockers is basically two days before go/no-go
17:12:21 <poelcat> adamw: we cant compose the beta rc with open blocker bugs
17:12:28 <adamw> oh right, srry
17:12:45 * adamw always misses something
17:12:59 <jlaska> adamw: good to know you're still human :)
17:13:07 <poelcat> ack/nak/patch to proposed action?
17:13:25 <poelcat> one more to go! :)
17:13:30 <adamw> ack
17:13:57 <jlaska> ack
17:14:11 <poelcat> #action https://bugzilla.redhat.com/show_bug.cgi?id=632489 accepted as a blocker, fixed needed no later than 2010-09-14
17:14:12 <buggbot> Bug 632489: medium, low, ---, rvykydal, NEW, Fail to read package metadata after specifying repo=
17:14:18 <poelcat> #topic https://bugzilla.redhat.com/show_bug.cgi?id=632510
17:14:32 <buggbot> Bug 632510: medium, low, ---, anaconda-maint-list, NEW, Installer exited abnormally when starting network in rescue mode
17:15:27 * jlaska reads
17:15:56 <jlaska> yeah, seems like a cut'n'dry blocker per criteria listed by rhe
17:15:59 <jlaska> #  The rescue mode of the installer must be able to detect and mount (read-write and read-only) LVM, encrypted, and RAID (BIOS, hardware, and software) installations
17:16:13 <adamw> it's not quite cut and dry as the criterion doesn't actually specify network functionality.
17:16:20 <adamw> and you don't need to be on the network to do any of those things.
17:16:32 <adamw> but i'm not going to hate us if we futz that a bit. :D
17:16:52 <jsmith> I think it's a blocker
17:17:07 <jsmith> I think people expect to be able to configure network connections from rescue mode
17:17:39 <adamw> jsmith: then we should amend the criterion to state that, strictly.
17:17:44 <adamw> but i'm happy to go with that plan.
17:18:22 * jlaska thinks
17:18:49 <poelcat> thoughts from devel on timeline for a fix?
17:19:48 <jlaska> adamw: you're right, we don't mention networking with regards to rescue mode.  We gathered at some point that would get pulled in for consideration.
17:20:00 <jlaska> dlehman: bcl: any thoughts around a timeline for #topic bug?
17:22:33 <bcl> should be easy, looks like the import is wrong
17:22:41 <jlaska> bcl: okay, thanks
17:23:29 <jlaska> whether we should include rescue-mode + networking as Beta release criteria ... I'd propose we handle out of meeting
17:23:30 <poelcat> proposed #action https://bugzilla.redhat.com/show_bug.cgi?id=632510 accepted blocker; need to ammend blocker criteria to be more specific, devel believes it's an easy fix they expect to make soon
17:23:39 <poelcat> ack/nak/patch
17:23:50 <jlaska> should we conclude that rescue-mode and networking isn't a requirement for beta ... we can circle back and adjust the bz
17:23:57 <adamw> ack
17:24:22 <dlehman> bcl: just needs changed to from textw.netconfig_text import .... ?
17:24:30 <dlehman> s/from//
17:25:16 <jlaska> ack
17:25:26 * adamw has to run, thanks everyone
17:25:40 <poelcat> #action https://bugzilla.redhat.com/show_bug.cgi?id=632510 accepted blocker; need to ammend blocker criteria to be more specific, devel believes it's an easy fix they expect to make soon
17:25:41 <jlaska> adamw: thank you, have a good evening :)
17:25:44 <poelcat> #topic open discussion
17:26:02 <Camberwell> can I just say Hi to everyone, I'v just joined the triage group
17:26:18 <jlaska> #action jlaska to propose adjusting beta release criteria to accomodate rescue-mode + networking (see 632510)
17:26:30 <jlaska> Camberwell: Hi and welcome :)
17:26:40 <Camberwell> thank you
17:27:21 <poelcat> anything else to discuss before we close?
17:27:29 <jlaska> nothing from me, thanks poelcat
17:27:32 <Camberwell> i'm looking for someone to just walk me through a couple, I'm a quick learner i'll fly solo pretty quickly
17:29:11 <Camberwell> i havn't even been aproved yet anyway, so when ever really
17:29:38 * poelcat closing meeting in 60 seconds
17:29:56 <jlaska> Camberwell: no worries, we should be able to get you started.  Discussing some of the onboarding and how to get started is part of the approval process
17:30:42 <jlaska> Camberwell: have you walked through the sign-up procedure yet, that's the best place to start -- https://fedoraproject.org/wiki/BugZappers/Joining#How_to_Sign_Up
17:30:53 <jlaska> Camberwell: we can talk more out of meeting
17:31:11 <Camberwell> thats ok, I'v read the checklist and stuff for triaging on the bugzappers page, i'll just need someone to show me the best tools for the job and stuff
17:31:17 <Camberwell> yeah cool
17:31:26 <poelcat> thanks everyone!
17:31:28 <poelcat> #endmeeting