15:00:10 <jlaska> #startmeeting Fedora QA Meeting
15:00:10 <zodbot> Meeting started Mon May 10 15:00:10 2010 UTC.  The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:10 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:14 <jlaska> #meetingname fedora-qa
15:00:14 <zodbot> The meeting name has been set to 'fedora-qa'
15:00:22 <jlaska> #topic Gathering critmass
15:01:57 <jlaska> this will make for a quick meeting :)
15:02:06 * kparal arrives
15:02:06 <jlaska> ah, kparal welcome
15:02:24 <jlaska> adamw: wwoods: jskladan: robatino: maxamillion
15:02:57 <kparal> jskladan seems to be still somewhere out
15:02:57 <adamw> yo
15:03:08 <jlaska> kparal: okay
15:03:21 <jlaska> lemme check if wwoods is around
15:04:10 <jlaska> not in yet
15:04:30 <jlaska> okay, let's get this party started, wwoods and jskladan can join mid-meeting
15:04:35 <etank> jlaska: quick meeting? that sounds promising :)
15:04:42 <jlaska> etank: hey, welcome! :
15:04:55 <jlaska> so yes ... short list of topics for today ... http://lists.fedoraproject.org/pipermail/test/2010-May/090788.html
15:05:45 <jlaska> so let's do quick review from last week
15:06:17 <jlaska> #topic Preview meeting follow-up
15:06:28 <jlaska> #info jlaska to migrate approved FAS 'qa' members into 'proventesters'
15:06:51 <jlaska> this task is complete
15:07:03 <jlaska> so now all approved members of 'qa' are now also approved 'proventesters'
15:07:11 <jlaska> the next item was ...
15:07:19 <jlaska> #info jlaska to request bodhi change to require 'proventesters' feedback for critpath
15:07:48 <jlaska> I have requested an update to bodhi (see https://fedorahosted.org/bodhi/ticket/424)
15:07:54 <adamw> 'for f12 and earlier' i suppose
15:08:05 <jlaska> lmacken quickly responded and has a fix in bodhi for this ... the fix has not yet been deployed
15:08:59 <jlaska> adamw: does bodhi currently rely on QA feedback on critpath packages for F12 too?
15:09:27 <adamw> oh wait never mind, was misparsing
15:09:49 <jlaska> okay, that's all I've got from last week
15:10:05 <jlaska> I'll need to catch up w/ lmacken once F-13 testing calms down to get a sense for when the deployment will go live
15:10:24 <jlaska> we'll also kick the tires on further defining the proventesters workflow then
15:10:44 * jlaska got a txt from wwoods, he's delayed this morning
15:10:49 <jlaska> okay, now for the big show ...
15:10:55 <jlaska> #topic Fedora 13 RC#2 test status
15:11:09 * kparal adds fireworks
15:11:18 <jlaska> #info upcoming milestone - 2010-05-11 - Fedora 13 Final Go/No-Go Meeting (20:00 EST)
15:11:28 <jlaska> #info upcoming milestone - 2010-05-12 - Fedora 13 Final Release Readiness Meeting
15:11:48 <jlaska> kparal: lots of starburts please! :)
15:12:02 <jlaska> adamw: I misread the schedule, seems #4 blocker meeting was last Wed, not last Friday
15:12:16 <jlaska> robatino: pointed this out last week, but I initially misread the schedule
15:12:33 <adamw> ah, well, never mind
15:12:58 <jlaska> want to hold a mini-blocker review of the current F13Blocker bugs now?
15:13:11 <jlaska> otherwise, we can chase these down individually outside of the meeting
15:13:34 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=590466
15:14:04 <jlaska> did we lose bugbot?
15:14:22 <kparal> is it not only in #fedora-qa?
15:14:24 <adamw> sure, let's do a mini-review
15:14:48 <adamw> there's some confusion about exact cause for this, but anyway, as I posted, i don't consider that a blocker. it can be fixed in an update.
15:14:49 <jlaska> adamw and mgarrett have been talking through /topic issue
15:15:17 <jlaska> nice to see someone testing on a macbook air :
15:15:28 <jlaska> but yes, I'm +1 with that assessment
15:16:21 <jlaska> I don't think Oxf13 is around yet for an additional vote
15:16:49 <jlaska> adamw: how to you intend to proceed ... leave on the list pending feedback from RelEng, or remove from blocker now?
15:17:08 <jlaska> #info confusion as to the exact cause for this bug
15:17:08 <adamw> i figured we could leave all the nominees on to air at the go/no-go meeting, but i don't mind if we want to demote them now
15:17:59 <jlaska> anything for a faster go/no-go meeting :)
15:18:14 <adamw> okay, knock it off then
15:18:27 <jlaska> okay, I'll update the bz after the meeting
15:18:44 <adamw> i've just done it
15:18:47 <jlaska> #agreed QA agreed that 590466 does not impact the release criteria and can be resolved in a future update
15:18:53 <jlaska> adamw: fast fingers strikes again!
15:18:58 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=590640
15:19:20 <jlaska> kparal: this is one you encountered earlier today ... what's your estimated impact on this issue?
15:20:00 <kparal> jlaska: well, I have seen it only when installing from NFS, and only from our local Brno mirror
15:20:08 <kparal> installing from my own mirror worked well
15:20:40 <kparal> the impact may be very low
15:21:08 <jlaska> clumens looked into this issue, and was perplexed at what might cause the issue
15:21:19 <adamw> seems a bit of an unknown quantity
15:21:27 <adamw> and it's not super-easy to set up different NFS configs to test with :/
15:21:31 <jlaska> kparal: I remember you uncovered some odd NFS access issues with the brno mirror while testing NFS repos in F12
15:21:36 <adamw> can we get any more brainpower on it?
15:21:58 <jlaska> clumens looked into it, I can ask him to summarize ... or see if dlehman might have other ideas
15:22:02 <kparal> I'll work with clumens on resolving it now, hopefully it's just some local mirror problem
15:22:50 <jlaska> #info fails when testing with RHT Brno Fedora NFS mirror, but works when installing from local nfs exported DVD mount
15:23:04 <jlaska> #info unclear user impact, kparal will discuss further w/ clumens for insight
15:23:28 <jlaska> if we can't pinpoint this one further, and no one else is able to hit the same conditions ... should we remove this from the list?
15:23:40 <adamw> i think we should leave it for now
15:23:46 <adamw> at least see if we can get better data before tomorrow
15:23:51 <adamw> it worries me a little bit
15:24:32 <jlaska> #agree 590640 - unclear on impact to release criteria, leave on the list pending additional information
15:24:41 <jlaska> #agreed 590640 - unclear on impact to release criteria, leave on the list pending additional information
15:24:44 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=590661
15:25:17 <jlaska> adamw: this is your addition to the list?
15:25:28 <jlaska> sorry no, mether added this
15:25:42 <robatino> i suspect but am not sure this behaved the same in F12
15:26:13 <Oxf13> I'm here now, but for another meeting.
15:26:13 <adamw> mether thinks otherwise
15:26:17 <adamw> i can probably try and test it
15:26:18 <jlaska> Oxf13: welcome
15:26:29 <adamw> though i'm not sure i actually have a windows CD handy here
15:26:43 <jlaska> I can reinstall F-12 on a system that still has a windows partition
15:26:49 <Oxf13> so this one you can work around by holding shift
15:26:53 <jlaska> right
15:27:03 <Oxf13> which is pretty similar to having to hold something to get the windows boot loader menu
15:27:04 <jlaska> to clarify, this doesn't block the release criteria
15:27:05 <jlaska> ?
15:27:11 <adamw> it's arguable
15:27:17 <Oxf13> and depending on the bug, we might be able to fix this with post-release updates
15:27:21 <Oxf13> but we might not.
15:27:31 <adamw> "The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working "
15:27:33 <jlaska> adamw: is this a scenario where the intended behavior is unclear?
15:27:34 <Oxf13> if this was the only thing left on the list, I'd be hard pressed to slip for it
15:27:52 <adamw> Oxf13: that's kind of my feeling. it sucks a lot and i'd love to fix it, but it's hard to do a week slip for it
15:27:58 <jlaska> adamw: hmm, I'm not sure it impacts that criteria
15:28:07 <Oxf13> IIRC we were supposed to notice a chain-load and thus have a timeout
15:28:09 <jlaska> is the method for accessing the bootloader screen documented?
15:28:11 <adamw> yeah, like i said, arguable. _technically_, the criterion is satisfied
15:28:16 <mether> adamw, is there a simple workaround or do the user have to edit grub.conf?
15:28:19 <Oxf13> and I'm not sure if that's a grub feature, or an anaconda feature
15:28:32 <robatino> grub.conf can be edited graphically with system-config-boot
15:28:32 <Oxf13> mether: the simple work around is to hold shift while booting
15:28:34 * jlaska has another meeting in 1.5 minutes
15:28:35 <adamw> but my intent when i wrote the criterion was more or less 'it should behave sanely when installing alongside windows', and this is fairly obvious dumb behaviour
15:28:37 <jlaska> #chair kparal adamw
15:28:37 <zodbot> Current chairs: adamw jlaska kparal
15:28:53 <kparal> Oxf13: unfortunatelly Shift does not work on some PCs correctly, bios reports stuck key and halts
15:29:03 <Oxf13> kparal: sure, if you hold it from boot on
15:29:12 <Oxf13> kparal: you may have to tap it, or hold it from a later boot point
15:29:14 <mether> adamw, I would argue that the listed criteria makes the bug a blocker
15:29:17 <Oxf13> just like trying to access the windows boot loader
15:29:18 <adamw> Oxf13: right, which gets finicky.
15:29:22 <Oxf13> or the apple boot loader
15:29:22 <jlaska> does someone have a link to documentation for how to access grub menu?
15:29:32 <adamw> jlaska: sec
15:29:46 <Oxf13> there should be plenty given we went to a 0 timeout a couple releases ago
15:30:45 <jlaska> #info debatable whether this impacts the release criteria
15:30:56 <robatino> system-config-boot is installed by default in a graphical install, it can be used to change the timeout
15:31:02 <jlaska> #info current dual-boot criteria states -- "The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working "
15:31:15 <adamw> Oxf13: i'm not convinced this behaved the same in f12, i'd really like to check that. remember, we found out the telnet similar bug was a regression from f12.
15:31:21 <jlaska> let's get testing on that
15:31:31 <jlaska> #help Confirm multi-OS bootloader configuration when installing F12
15:31:41 <adamw> i can't find any documentation of this in f12 or f13 release notes or f12 user guide or any common bugs page
15:31:48 <Oxf13> adamw: I don't believe it behaved the same in F12
15:31:58 <Oxf13> adamw: at least in dualboot scenario
15:32:03 <adamw> oh, i see, just general documentation for getting into bootloader
15:32:07 <Oxf13> outside of dual boot we indeed had a 0 second timeout for grub
15:32:08 <adamw> i'm not sure we ever actually wrote anything down
15:32:15 <adamw> probably a question for the docs team, though.
15:32:28 <Oxf13> well, outside of dual boot and serial
15:32:28 <adamw> i'm sure i never put it in commonbugs, though.
15:32:40 <Oxf13> because 0 second timeout isn't a bug
15:32:41 <jlaska> okay, so what's left on this
15:32:42 <Oxf13> it's a feature
15:32:49 <adamw> i think we should discuss this at go/no-go tomorrow
15:32:51 <jlaska> more testing ... and possible documentation of this behavior change?
15:32:54 <adamw> since it's clearly a tricky one to make a call on
15:33:00 <jlaska> present findings @ go/no_go meeting tomorrow?
15:33:05 <adamw> and yes, check if this is a regression from f12, and definitely document it if we don't slip for it
15:33:11 <jlaska> okay ...
15:33:27 <jlaska> #action help testing dual-boot behavior in F12
15:33:39 <jlaska> #action identify if any bootloader config documentation exists
15:33:54 * adamw feels dumb, as he noticed this when he installed f13 on this system two weeks ago but never really thought about yelling about it
15:33:55 <adamw> sigh
15:33:56 <jlaska> #agreed 590661 - remains on the list, pending additional information to be presented @ go/no_go
15:34:18 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=590666
15:34:49 <jlaska> this is the last bug on the list
15:34:54 <Oxf13> I have more.
15:34:57 <jlaska> Oxf13: okay
15:35:08 <jlaska> adamw: kparal: you have #chair ... /me dual-meeting
15:35:20 <kparal> adamw: please take this if you can
15:35:36 <Oxf13> "take this" ?
15:35:43 <kparal> the chair
15:35:46 <Oxf13> ah
15:36:21 <adamw> uh
15:36:27 <adamw> let's see
15:36:59 <adamw> bastien nominated this and the lid issue, apparently under the impression we could 'fix it in gold', after I chatted to him
15:37:13 <adamw> i explained there's no possibility of that, either we ship rc2 or slip, and he was okay with dropping this one as a blocker too
15:37:19 <adamw> but of course we can decide we want to slip for it.
15:37:39 <adamw> i believe the impact is basically that you can't do tethering with a Bluetooth phone via DUN (which is an F13 feature), until NetworkManager gets fixed
15:37:55 <adamw> obviously this is quite easy to fix with an update, but it _is_ an F13 feature we're going to ship completely broken.
15:38:01 <adamw> so, that's the scenario...thoughts?
15:38:08 <Oxf13> is it all phones, or just specific ones?
15:38:19 <Oxf13> or all bluetooth phone connectivity or just a few?
15:38:35 <adamw> it's specific to tethering (using the phone as a modem) via Bluetooth  DUN
15:38:49 <adamw> it shouldn't affect other things you can do with a phone via bluetooth (transferring files and whatnot)
15:39:19 <adamw> and I believe it doesn't affect Bluetooth PAN tethering (that's another way of tethering via Bluetooth, there's two mechanisms, most phones just support one or the other), though i don't think we've directly tested that
15:39:31 <adamw> i *think* it affects all phones, but not 100% sure; dcbw should know, of course
15:40:30 <adamw> dan's not around at present it seems, i can ask for a more precise impact assessment in the bug
15:41:10 <jlaska> was it already mentioned what the release criteria impacted was?
15:41:51 <Oxf13> I don't think it impacts release criteria
15:41:58 <Oxf13> it's just that DUN was a feature
15:42:10 <Oxf13> which means that there isn't a regression from 12
15:42:28 <adamw> i mean, we could theoretically argue it breaks the critpath if your only internet connection is a cellphone and your only way to tether with it is bluetooth, but that's rather farfetched
15:42:53 <adamw> so it's mostly just the feature thing.
15:43:25 <Oxf13> yeah
15:43:31 <adamw> i'm probably okay with just document+fix in an update for this, really.
15:43:32 <Oxf13> and I'm ok with fixing this in updates
15:44:53 <jlaska> +1
15:45:29 <adamw> okay, let's demote it then
15:45:33 <adamw> i'll take care of that
15:45:48 <adamw> #agreed 590666 isn't blockery enough, we can document + fix with an update
15:45:56 <adamw> #topic YOUR_BUG_HERE
15:45:59 <adamw> so, oxf13?
15:47:55 <adamw> you said you had something to add
15:49:07 * kparal pinging Oxf13\
15:49:17 * adamw pings oxf13 with the giant hammer o' pain
15:49:27 <Oxf13> sorry, in a second meeting
15:49:44 <Oxf13> I got a report that our live images, at least the desktop one, doesn't have kernel-firmware on it, and as such many devices don't work
15:49:49 <Oxf13> no bug yet, somebody shoudl file one
15:49:57 <Oxf13> but this I do believe is just a config change, but may have space concerns
15:50:04 <adamw> ouch, that is something i'd want to respin for
15:50:15 <Oxf13> although I don't have kernel-firmware installed here., just a tic
15:50:17 <adamw> Size        : 8165344
15:50:20 <adamw> that's 8MB right?
15:50:25 <kparal> yep
15:50:43 <Oxf13> hrm, I have "linux-firmware"
15:50:46 <adamw> that'd give kde spin a few probs, but kde team did identify some packages we can lose from that without having trouble
15:50:47 <Oxf13> and a bunch of individual firmware files.
15:50:58 <Oxf13> this is just one report though, not confirmed
15:51:18 <Oxf13> this person was complaining about intel wireless not working, which I think is managed in a different -firmware package
15:51:31 <adamw> okay, so we need more info on this
15:51:37 <adamw> what firmware packages do we have, which of them are on the live images
15:51:56 <adamw> anyone can boot the desktop live quick and take a look?
15:52:06 <Oxf13> and it looks like a ton of firmware goes into the live images.
15:52:39 <Oxf13> actually I'd rather have the reporter do some investigation, because from the look of the package set, it should be fine
15:52:43 <adamw> okay
15:52:43 * kparal booting live image
15:52:48 <adamw> where's the report here?
15:52:48 <Oxf13> so the reporter may ahve jumped to the wrong conclusion
15:52:57 <Oxf13> there isn't, it was sent to me as a facebook email.  *sigh*
15:53:00 <adamw> heh
15:53:11 <adamw> next up, the Twitter bug report
15:53:14 <adamw> 'it duznt work LOL'
15:53:50 <kparal> so, do you want to know something from live image?
15:53:59 <adamw> kparal: a quick rpm -qa | grep firmware maybe
15:54:08 <Oxf13> linux-firmware is on the live image too
15:54:17 <Oxf13> adamw: I already got that
15:54:19 <adamw> ah
15:54:21 <Oxf13> I have the logs from the compose.
15:54:26 <adamw> intel firmwares should be iwl-*-firmware i think
15:54:28 <Oxf13> there is plenty of firmware, this reporter is on crack
15:54:31 <adamw> iwl*-firmware
15:54:41 <adamw> and ipw*-firmware
15:55:12 <kparal> adamw: http://fpaste.org/yWgt/
15:55:25 <Oxf13> I think I'm calling this a non-issue
15:55:29 <kparal> fc12 package, interesting
15:55:31 <Oxf13> until I get more feedback from reporter
15:55:37 * Viking-Ice sneaks in late..
15:55:39 <Oxf13> kparal: firmware doesn't change that often.
15:55:54 <adamw> that sure looks like all the intel firmware's there.
15:56:08 * kparal could have sorted it
15:56:16 <adamw> and all the other things i recognize as major wireless firmware, at a glance
15:56:26 <adamw> kparal: yeah, never mind though =)
15:56:40 <adamw> Oxf13: is it the same on KDE spin?
15:57:02 <Oxf13> yes
15:57:07 * jlaska back from meeting
15:57:12 <Oxf13> the firmware stuff likely comes in from the fedora-live-base
15:57:16 <adamw> then i agree, non-issue
15:57:24 <adamw> tell your reporter to lay off the crack pipe =)
15:57:33 <jlaska> so #agreed on this?
15:57:38 <Oxf13> I'm still curious as to why his intel wifi didn't come up, but it's certainly not because of a missing firmware package
15:57:45 <adamw> Oxf13: yeah.
15:57:56 <adamw> #agreed the report oxf13 received about missing firmware on live images appears to be crack
15:58:11 <adamw> anyone else have a potential blocker issue to bring up?
15:58:24 <Oxf13> there are a number of spin-kickstart changes that went in over the weekend
15:58:37 <Oxf13> one of which touches on fedora-live-base, which would mean every livecd I've made would have to be re-spun
15:58:53 <Oxf13> I need to review the change and discuss it with the developer to see what's going on here.
15:59:04 <Oxf13> I'm quite a bit disturbed at all the late changes to spin-kickstarts
15:59:29 <jlaska> Oxf13: could that git repo benefit from release specific branches?
15:59:41 <adamw> that does seem silly. perhaps we should have a freeze on spin-kickstarts close to RC time.
15:59:43 <Oxf13> and to make moblin work, they need an updated package or two, which should only exist on the moblin spin (and the everything repo) so tagging those isn't a big deal.
15:59:53 <Oxf13> adamw: we do, the problem is lack of testing until RC time
16:00:00 <adamw> ah :)
16:00:01 <Oxf13> to be fair, I announced "get your spins working" rather late
16:00:51 <jlaska> Anyone have any non-bug discuss topics today?
16:01:37 <kparal> jlaska: summer of code
16:01:38 <adamw> #topic open floor
16:01:48 <adamw> #topic open floor: summer of code
16:01:50 <adamw> go for it, kparal
16:02:19 <kparal> ok
16:02:33 <kparal> as you may be know, there's Fedora's Summer Coding 2010: http://fedoraproject.org/wiki/Summer_Coding_2010
16:02:51 <kparal> there are already quite some ideas proposed: http://fedoraproject.org/wiki/Summer_Coding_2010_ideas
16:03:19 <kparal> our QA team created a few proposals themselves: https://fedoraproject.org/wiki/QA:Summer_of_Code_Ideas
16:03:39 * jlaska has to flesh out a few more ideas
16:03:59 <kparal> we would act as a mentors for students implementing those ideas
16:04:02 <kparal> the problem is we don't know how many resources this effort would need
16:04:26 <kparal> so, it really needs someone devoted and enthusiastic for this matter :)
16:04:38 <kparal> a lot of our proposals don't have any mentor
16:04:50 * Viking-Ice got one after kparal finishes
16:05:08 <adamw> so we'd like mentors and possibly students for the QA ideas?
16:05:09 <kparal> so if there is someone, who would like to mentor some of them (or propose some other idea from QA world), that would be fantastic
16:05:33 <kparal> yes, we need to find mentors amongst ourselves
16:05:39 <kparal> and then find students :)
16:05:54 <kparal> or the students should rather find us
16:06:04 <kparal> we would blog about the opportunities etc
16:06:18 <kparal> the deadline for ideas is May 13th
16:06:34 <kparal> and then another week for student applications
16:06:41 <adamw> that's three days, for the temporally vague =)
16:06:55 <kparal> so, anyone got really really interested? :)
16:07:28 <kparal> it would mean creating a detailed description for a chosen idea or creating your own
16:07:36 * adamw just wants to finish f13 release then crawl into a corner and die quietly
16:07:37 <kparal> and then mentoring a student over holidays
16:07:51 <kparal> (July, August)
16:08:11 <jlaska> anyone have experience mentoring (or as a student) on a summer of code project?
16:08:21 <kparal> good question, thanks jlaska
16:09:20 <adamw> nope
16:09:21 <jlaska> #help if you have experience (as a student or mentor) with Summer of code, please contact the QA team
16:10:37 <kparal> well, seems like no response to me...
16:10:55 <Oxf13> I have no time to spend on it this summer
16:11:08 * jlaska just unsure what is required ... would love to hear back from someone who participated in such an event in the past
16:11:13 <adamw> sorry, i'm sort of interested but also frazzled from f13 cycle and behind on other things, so it's hard to get motivated to go and look at this now
16:12:22 <kparal> alright. if we don't find a voluteer for mentoring, then I think it will have to wait for some other time
16:12:31 <adamw> you can put a call out on the list
16:12:54 <jlaska> on a positive note, we now have a place to start collecting project ideas for anyone interested in getting involved in Fedora QA
16:13:13 <kparal> #link https://fedoraproject.org/wiki/QA:Summer_of_Code_Ideas
16:14:32 <jlaska> Shall we move on to Viking-Ice's discussion topic?
16:14:41 <Viking-Ice> Ok.. I think we need to know which packages we ship contain dead or little to no active upstream and perhaps warn users on install time and let reporters and bugzappers know about those. I do believe we are wasting of everybody's time dealing with theses packages..
16:15:12 <jlaska> #topic open floor: reporting on upstream activity
16:15:27 <jlaska> Viking-Ice: how do you measure upstream activity?
16:15:34 <adamw> sounds more like a development topic to me...
16:16:01 <adamw> i'd quite like something like this too, but it's quite icky to automate, as there's almost as many organization systems for upstream projects as there are upstream projects
16:16:35 <Viking-Ice> jlaska: commits $ time .
16:17:11 <Viking-Ice> adamw: packagers burden to keep track on..
16:17:54 <Viking-Ice> packagers know ( or atleast should know ) if upstream is dead or not
16:18:00 <jlaska> it's a clever idea, seems worth a proposal that outlines the scope of the problem, severel methods for reporting on upstream health ... and circulating around devel@ ?
16:18:44 <jlaska> it would seem hard to device an accurate heuristic that would work ... but it's an interesting idea
16:19:06 <Viking-Ice> Well we actually need also to get some bugzilla activity stats got go with it..
16:19:25 <kparal> maybe just bugzilla could allow to mark some components as "with dead upstream" and particular maintainer could trigger that setting?
16:19:28 <Viking-Ice> How much resource are we spending in dealing with dead upstream
16:19:32 <kparal> and then it would be shown to bug reporters
16:20:03 <jlaska> Viking-Ice: yeah, not a bad project idea ... just needs someone to define the problem space and pull together some recommended solutions for review?
16:20:25 <jlaska> Viking-Ice: were you volunteering, or just looking for feedback on the idea?
16:20:53 <Viking-Ice> kparal: I think this needs to be flag at install time so if a end user hits a bug he can be assured there's no point in reporting it
16:21:25 <Viking-Ice> Vikings-Ice: just in feed back stage at the moment..
16:21:44 <jlaska> Viking-Ice: okay
16:21:55 <jlaska> if there's nothing else for today ... let's close out the meeting
16:21:59 <jlaska> (1 minute from #endmeeting)
16:22:18 <Viking-Ice> If this is a generally considered a good idea for #future to work on..
16:22:32 <adamw> it'd certainly be good to have it, yep.
16:22:58 <jlaska> yeah, is this a common request from maintainers of dead upstream projects?
16:23:08 <jlaska> good discussion to take to the list
16:23:10 <jlaska> list(s)
16:23:29 <jlaska> endmeeting extended ... closing in 30 seconds
16:23:44 <Viking-Ice> this is a packagers burden so let's wait for other things to cool down first ;)
16:23:58 <Viking-Ice> on "the" list first
16:24:14 <jlaska> sounds like a plan
16:24:20 <jlaska> okay folks ... thanks for your time
16:24:26 <jlaska> kparal: adamw: thanks for the #chair assistance
16:24:29 <jlaska> #endmeeting