From Fedora Project Wiki
< BugZappers | Meetings
Bug Triage Meeting :: 2009-06-23
Agenda: https://www.redhat.com/archives/fedora-test-list/2009-June/msg00629.html
Attendees
- tk009 (79)
- alindebe (67)
- mcepl (51)
- adamw (28)
- pjones (18)
- comphappy (18)
- poelcat (13)
- arxs (8)
- denise (7)
- SMParrish_ (2)
- azneita (2)
- smooge (1)
- M_J_G (1)
- mpreston (1)
- rjune_wrk (0)
Meeting Recap
- topic - Triage Metrics - Update on the FAS integration and overall status.
comphappy was not able to attend the meeting, he will try to give an update later today.
- topic - Kernel Triage - Discuss the feedback from Chuck Ebbert on kernel triage.
Chuck asked one specific question in his email: If there might be a different way to indicate a bug's been triaged rather than simply setting it to ASSIGNED? During the meeting on some of the available options were discussed, none were agreed upon. We will continue this in the mailing list. - this topic is also related to anaconda, and with members of the anaconda team present at the meeting we took the opportunity to discuss how we can better assist them.
alindebe provided information on the anaconda team's workflow here: http://fedoraproject.org/wiki/Anaconda/AnacondaBugWorkflow and requested that triagers wanting to help with anaconda learn this work flow and work within it. Also see : http://fedoraproject.org/wiki/Anaconda/BugReporting Also a request that triagers communicate and confirm with the anaconda team on #anaconda before setting anything to assigned. BugZappers will follow these instructions if they triage anaconda bugs.
Thank you alindebe, denise and pjones for attending.
- topic - Component list update for the F12 cycle - Update on status.
This was an action item from last weeks meeting. No discussion during the meeting. After the meeting arxs volunteered to create a draft of a revised components list based on information from Critical_Path_Packages_Proposal
- Action Item - arxs will create a draft of a revised components list and update on progress next week.
IRC Transcript
| tk009 | #startmeeting - BugZappers Meeting | 15:00 |
|---|---|---|
| arxs | * hello | 15:00 |
| mpreston | present | 15:00 |
| tk009 | hello arxs | 15:00 |
| * SMParrish_ here | 15:00 | |
| * adamw raises a limb | 15:00 | |
| tk009 | and all =) | 15:00 |
| adamw | rjune should be around too? | 15:00 |
| tk009 | #chair adamw rjune_wrk | 15:01 |
| adamw | ah, he has a work meeting i think. | 15:01 |
| tk009 | he wasn't sure if he could make it | 15:01 |
| tk009 | I don't see comphappy | 15:02 |
| tk009 | #topic - Triage Metrics - Update on the FAS integration and overall status. | 15:02 |
| tk009 | adamw do you know anything about the status | 15:03 |
| tk009 | last time I saw he was going to update you last wednesday | 15:03 |
| adamw | not since last meeting, iirc | 15:03 |
| adamw | let me check if we talked and i lost it :) | 15:03 |
| adamw | just a sec | 15:03 |
| tk009 | =) | 15:03 |
| tk009 | they don't see to be updating | 15:03 |
| tk009 | does anyone else notce that? | 15:03 |
| adamw | oh yay :) | 15:04 |
| arxs | right, and if you force to changed the timeframe, some 404 poped-up | 15:04 |
| adamw | comphappy: we're on your topic - can you give us an update on the triage metric system status? | 15:04 |
| mcepl | me | 15:05 |
| mcepl | sorry | 15:06 |
| mcepl | /me | 15:06 |
| * mcepl has add something to the text. | 15:06 | |
| comphappy | Got up late last nights version is sitting on laptop | 15:06 |
| adamw | comphappy: what was the problem with it not updating any more, again? i remember you explained that to me but i forget the details | 15:07 |
| * tk009 thinks comphappy might not be fully awake yet | 15:09 | |
| adamw | or just having connection trouble | 15:10 |
| adamw | maybe we should continue and we can come back later if he returns :) | 15:10 |
| tk009 | should we come back to it? | 15:10 |
| tk009 | kk | 15:10 |
| tk009 | next up | 15:10 |
| tk009 | #topic - Kernel Triage - Discuss the feedback from Chuck Ebbert on kernel triage. | 15:11 |
| adamw | hi smooge btw | 15:11 |
| smooge | good morning | 15:11 |
| adamw | alindebe: are you around btw? jlaska said you may be | 15:11 |
| tk009 | we kind of already started talking about this in #fedora-bugzappers | 15:11 |
| alindebe | yep | 15:11 |
| adamw | i have to run in a minute | 15:11 |
| adamw | alindebe (andy lindebergh) is the anaconda triager, we're hoping to try and link her work in a bit more to the bugzappers group - thanks for coming to the meeting, andy | 15:12 |
| alindebe | no problem | 15:12 |
| tk009 | yes thank you for coming | 15:12 |
| adamw | and that ties in with this topic too...anaconda and kernel triage. we got an email back from chuck of the kernel team on that question | 15:12 |
| tk009 | adamw without rjune_wrk here is there anything yo uwanted to add to the current topic | 15:13 |
| adamw | which should serve as a good point to start a discussion about a process that both we and the kernel team can be happy with | 15:13 |
| adamw | yeah, chuck asked one specific question | 15:13 |
| adamw | which i think is something andy may well be interested in too... | 15:13 |
| adamw | he was asking if there might be a different way to indicate a bug's been triaged rather than simply setting it to ASSIGNED | 15:13 |
| adamw | because kernel team likes to use ASSIGNED in another way...i think this is possibly a legitimate request, as ASSIGNED doesn't really _mean_ triaged, and it's one i've heard from other people too | 15:14 |
| alindebe | As does anaconda | 15:14 |
| adamw | so it would be good to have that up for discussion and see what people think | 15:14 |
| arxs | like in the past, add the "triaged" keyword maybe? | 15:14 |
| SMParrish_ | How about a triaged keyword or flag | 15:14 |
| adamw | yeah that was my thought too | 15:15 |
| tk009 | a flag would be best | 15:15 |
| alindebe | eeeh. | 15:15 |
| adamw | it doesn't seem to fit the flag workflow? who would set triaged? and who would set triaged+ ? | 15:15 |
| tk009 | that way we dont run over a bug we've already seen | 15:15 |
| mcepl | adamw, alindebe: couldn't kernel and anaconda switch to ASSIGNED/ON_DEV system? Just asking ... | 15:15 |
| tk009 | mcepl | 15:16 |
| alindebe | Doesn't make sense | 15:16 |
| tk009 | yum said no to that | 15:16 |
| tk009 | we need something that works for everyone | 15:16 |
| mcepl | alindebe: please explain; really don't want to make it difficult, but it will be difficult for us, so I would love to know | 15:16 |
| adamw | i've gotta run now | 15:16 |
| tk009 | or as close to everyone as possible | 15:16 |
| adamw | but i'll read the log later | 15:16 |
| adamw | and we can discuss further on list also | 15:16 |
| tk009 | be well brother | 15:16 |
| adamw | thanks guys! | 15:16 |
| mcepl | adamw: bye | 15:16 |
| arxs | tk009: i think a flag is better thant a keyword, since the keywork is uses to reflect a blocker | 15:16 |
| alindebe | mcepl: Quite simply, because it would be a huge change in the way we already do things and would require a big readjustment | 15:17 |
| alindebe | see: http://fedoraproject.org/wiki/Anaconda/BugReporting | 15:17 |
| alindebe | and: http://fedoraproject.org/wiki/Anaconda/AnacondaBugWorkflow | 15:18 |
| tk009 | alindebe: how do you know you've a given bug? how do you mark that? | 15:18 |
| alindebe | what do you mean? | 15:18 |
| tk009 | triaged a given bug* | 15:18 |
| mcepl | alindebe: sorry, I don't see from that page anything about NEW, ASSIGNED, etc. states | 15:18 |
| alindebe | mcepl: See the second page | 15:18 |
| mcepl | oh sorry | 15:18 |
| * poelcat joins | 15:18 | |
| tk009 | hello poelcat | 15:19 |
| arxs | hi poelcat | 15:19 |
| alindebe | tk009: We don't, really, because it's not easy or obvious or even helpful, in some cases | 15:19 |
| mcepl | alindebe: OK, how is your workflow different from the deafult if you would make one huge mass-change ASSIGNED->ON_DEV? | 15:20 |
| alindebe | I don't know much about other packages, but anaconda bugs are hard. It's not always clear what log file, if any, is needed, it's not always clear if the developers can reproduce the problem themselves or if they're reliant on the reporter, it's not always clear whether something is user or hardware error | 15:20 |
| mcepl | alindebe: really, trying to understand | 15:20 |
| poelcat | can summarize what we are trying to figure out? | 15:20 |
| alindebe | mcepl: Well, firstly it makes less intuitive sense. I can see ASSIGNED being useful on packages which have one maintainer, because it *is* assigned to a person, but anaconda has 9. | 15:20 |
| poelcat | s/can/can someone | 15:20 |
| arxs | poelcat: triage of anaconda and kernel bugs | 15:21 |
| mcepl | yeah, sure, but we try to minimize changes in Bugzilla, so the terminology is not the best. | 15:21 |
| alindebe | Marking it as ASSIGNED when there *isn't* somebody assigned to work on it seems... pointless? | 15:21 |
| mcepl | alindebe: take a look at BugZappers/BugStatusWorkFlow | 15:21 |
| alindebe | I've seen it | 15:21 |
| mcepl | ASSIGNED to developers generally? Would it make sense? | 15:21 |
| mcepl | I know it's stretching the language. | 15:21 |
| alindebe | not really. Developers don't pay attention to bugs not given to them | 15:21 |
| mcepl | but does it matter that much? | 15:22 |
| mcepl | well, and "bug given to them" would be ON_DEV | 15:22 |
| alindebe | not that | 15:22 |
| mcepl | why? please explain | 15:22 |
| alindebe | most of them only pay attention to bugs which actually have their names in the assignee field. | 15:22 |
| alindebe | So, marking something as ASSIGNED... why? | 15:22 |
| alindebe | it seems like an extraneous ste[p | 15:23 |
| alindebe | *step | 15:23 |
| pjones | the ON_DEV state really doesn't make any sense to most developers, AFAICS. | 15:23 |
| mcepl | alindebe: hehe, just working on upgrade to my greasemonkey script for semi-automatic changing of assignees http://mcepl.fedorapeople.org/tmp/sshot-newDefAssigneeButton.png :) | 15:23 |
| pjones | (it only really made any sense in the situation it was introduced for -- web development with a shared "development" server you could push to.) | 15:23 |
| mcepl | pjones: would it be that difficult to explain meaning of two keywords? | 15:23 |
| poelcat | mcepl: what is the overall problem we are trying to solve? | 15:23 |
| pjones | mcepl: the difficult part is that having the two keywords doesn't make any sense | 15:24 |
| tk009 | how to triage bug for anaconda, kernel | 15:24 |
| pjones | mcepl: if it's been assigned, it should be in "assigned". If it hasn't, it shouldn't be. Why have two assigned states, the more obvious of which doesn't mean assigned? | 15:24 |
| mcepl | to move all components to one workflow, so that we don't have to modify our tools, study materials, etc. for two components (albeit important ones) | 15:24 |
| tk009 | without using assifned | 15:24 |
| tk009 | yet some way to say this was triaged | 15:24 |
| mcepl | pjones: beacuse you have two assigned states already ... as I understand it | 15:24 |
| poelcat | tk009: why are *we* trying to figure that out if those teams have an established workflow that works for them? | 15:24 |
| alindebe | Again, I don't know how it works with other components, but with anaconda, people pay attention to bugs assigned directly to them, not to the general bug list. | 15:25 |
| mcepl | poelcat: ok, giving up, whatever; | 15:25 |
| alindebe | *I* pay attention to the general list to deal with it, and having bugs in both NEW and ASSIGNED to look at... | 15:25 |
| alindebe | I just honestly don't see the point | 15:25 |
| tk009 | well the kernel guys said they didn't have a workflow | 15:25 |
| tk009 | which is how this started | 15:25 |
| alindebe | It's an extra step that doesn't add anything, as far as I can tell | 15:25 |
| tk009 | other teams have asked that we not assign | 15:26 |
| mcepl | alindebe: well, you would at least know which bugs are triaged, i.e. ready to be assigned to somebody particular; but as I said, I don't want to stop peace negotiations with you folks. | 15:26 |
| mcepl | so whatever | 15:26 |
| alindebe | mcepl: We don't use triage, though | 15:26 |
| alindebe | or, not in that order | 15:26 |
| comphappy | Um so why can the bug not be assigned to the actual person? | 15:26 |
| poelcat | alindebe: how does it get done? at the end of F11 there were 200 bugs notting had to go through | 15:26 |
| * mcepl apparently doesn't understand the point of this talk, so goes back to his shell | 15:26 | |
| alindebe | poelcat: what specifically? | 15:26 |
| pjones | mcepl: that definition of "triaged" seems completely superfluous... | 15:26 |
| alindebe | mcepl: Really, triage gets done in the opposite order | 15:27 |
| pjones | mcepl: seriously, if it hasn't been assigned to an individual, it /hasn't been triaged/. | 15:27 |
| alindebe | anaconda bugs can be *hard* to triage sometimes, so they go to the right developer who then knows what to ask | 15:27 |
| poelcat | alindebe: from the outside it appeared that a lot of bugs hadn't been triaged and weren't in a "known" state which is why notting went through them all | 15:27 |
| tk009 | I think that is what we are working on here | 15:27 |
| comphappy | I thought the idea was to get the bug to the person who would fix it | 15:27 |
| tk009 | making sure blockers dont go unseen again | 15:28 |
| tk009 | if we can help it | 15:28 |
| alindebe | poelcat: yeah, some of them weren't. Some of them were legit bugs that just hadn't gotten commented on yet. | 15:28 |
| denise | but with that many bugs and 9 developers, it was inevitable that some were not going to get handled instantly | 15:28 |
| alindebe | mcepl: Y'know, thinking about it, "triage" for anaconda really means, "figuring out who the right assignee is and assigning the bug to them". And along with that goes ASSIGNED | 15:29 |
| alindebe | So the difference is really what is needed for triage rather than the flow itself | 15:29 |
| comphappy | Are those 9 peoples jobs defined enough that say ext4 install bug can be assigned to one person | 15:29 |
| mcepl | alindebe: so you never need to ask reporter anything, no NEEDINFO before ASSIGNED happens ever? (for example) | 15:30 |
| alindebe | comphappy: to some extent, see http://fedoraproject.org/wiki/Anaconda/AnacondaBugWorkflow | 15:30 |
| alindebe | (in the ASSIGNED section) | 15:30 |
| mcepl | you never got PEBKAC (thinking about it, maybe not) | 15:30 |
| mcepl | ? | 15:30 |
| pjones | mcepl: when that happens, it should be in NEW with NEEDINFO set... | 15:30 |
| alindebe | mcepl: sometimes it is obvious which things are needed | 15:30 |
| alindebe | (and I gave a general list in the workflow) | 15:31 |
| comphappy | Then when triageing a bug why can it not be ASSIGNED to one person | 15:31 |
| alindebe | comphappy: It can, as long as you're assigning it to a person | 15:31 |
| mcepl | pjones: of course, and that's my point, ASSIGNED means in the default terminology, that all this cleaning up, and repackaging is done, and the bug is ready to be assigned to somebody. | 15:31 |
| alindebe | comphappy: Though, really, I recommend NOT just assigning it, but talking to the developer on IRC first | 15:31 |
| * mcepl just really shut up | 15:31 | |
| pjones | mcepl: but that doesn't make any sense | 15:32 |
| pjones | mcepl: it's in the bloody past tense | 15:32 |
| alindebe | sometimes bugs which look like they're x are really y, and the developer will be able to see that | 15:32 |
| comphappy | Yes but that is our workfloow | 15:32 |
| alindebe | comphappy: not ours | 15:32 |
| tk009 | everyone please be calm | 15:32 |
| poelcat | i think our overall goal here be to make sure we have identified all the important open bugs for the release under devel | 15:32 |
| pjones | yes but that workflow makes developers want to throw rocks at you. | 15:32 |
| alindebe | mcepl: I don't want to silence you, I really don't. | 15:33 |
| comphappy | Pjones: i am a developer and i like ot | 15:33 |
| alindebe | mcepl: I think my biggest complaint with the bugzapper workflow is that sometimes people have posted "triaged" in a bug and moved it to ASSIGNED without actually having done any triage | 15:33 |
| poelcat | alindebe: that seems like a fair compliant... seems like we should address those directly as they happen | 15:34 |
| comphappy | The idea it to get bugs to the person who will fix it and request NEEDINFO if it is needed | 15:34 |
| tk009 | agree poelcat | 15:34 |
| mcepl | pjones: alindebe: well, my problem and I try to discuss with you again and again, is that we have effectively two components (albeit, maybe the biggest ones) which are their own separate univers and where nobody dearts to go, so there is not much help possible. If you like it that way, OK, but I don't know it that's the plan. | 15:34 |
| tk009 | we cant fix what we dont know about | 15:34 |
| poelcat | alindebe: otherwise we can scale or grow people helping | 15:34 |
| denise | the anaconda bugs are difficult to triage - there is often additional information to collect, and it is unclear who the correct developer would be. | 15:35 |
| alindebe | mcepl: Does having a written workflow for anaconda help? | 15:35 |
| denise | so I asked alindebe to document our process | 15:35 |
| denise | which she did | 15:35 |
| mcepl | alindebe: and about ... of course, everybody screws up sometimes, that's the reason why we urge bug triagers to work with maintainers (or in cases of our two, with current bug triagers) to learn the folkways there. | 15:35 |
| mcepl | alindebe: sure, it does. | 15:36 |
| alindebe | I would be totally okay with somebody looking at a bug, saying "okay, this is partitioning, which requires storage.log and should go to dlehman". But very often, it's not clear if that's *actually* the bug, which is why I recommend pinging the developer on IRC and checking with them first. | 15:36 |
| poelcat | alindebe: denise do you feel that currently documented process works and has enough people to do it effectively? | 15:36 |
| mcepl | and of course, there is always the question, how much could volunteer bug triager help ... e.g., for Xorg bugs there is always the problem that not everybody has all those graphics cards available. Maybe anaconda is not good component for volunteer bug triagers at all? | 15:37 |
| comphappy | alindebe: I agree they dhould talk to then but jow does that inyerfear with our work flow | 15:37 |
| alindebe | mcepl: Sometimes it is, but half our bugs are hardware-dependent that *we* don't even have the hardware for | 15:38 |
| pjones | mcepl: there are still things a *knowledgeable* volunteer triager can do with your Xorg example, and I would expect that having the hardware isn't really something a triager would ever need. | 15:38 |
| alindebe | (okay, I'm exaggerating with half) | 15:38 |
| denise | poelcat, I'd love to have bug-zappers helping alindebe if they are ok with the anaconda process, but if not, it will be an additional burden for the developers and we cant afford that | 15:38 |
| alindebe | comphappy: anaconda has never used that workflow | 15:38 |
| mcepl | pjones: of course (I cannot properly triage half of the bugs myself) | 15:38 |
| pjones | mcepl: really, a triager there would need to be checking for things like: having information about package versions, having adequate information about the hardware, having adequate information about config files and such, ... | 15:38 |
| comphappy | alindebe: Lets not say we don't want to use it because it is not what we do | 15:39 |
| mcepl | pjones: and I can imagine not everybody has spare SAN/NAS to test installation over it :) | 15:39 |
| alindebe | mcepl: I wouldn't recommend anaconda to a novice triager. It's complex. | 15:39 |
| alindebe | comphappy: It's not what we do, and it never has been. Changing would disrupt me, and the developers | 15:39 |
| pjones | mcepl: none of that stuff is something that requires having the hardware, but much of it *does* require some sophistication. | 15:39 |
| pjones | mcepl: and again, testing the setup isn't really what we need triagers for. | 15:40 |
| mcepl | well, I tell you a secret, good triaging of any component is complex; it took me good year to get at least some understanding what to do about Xorg bugs and quite often I still feel like a newbie. | 15:40 |
| pjones | I'm not disagreeing with that at all. | 15:40 |
| mcepl | pjones: well, or other way around, what do you understand trige to be? | 15:40 |
| arxs | some here for triage of NetworkManager | 15:40 |
| denise | yes, thats why we asked alindebe to do a brain-dump on anaconda | 15:40 |
| * poelcat notes we have 19 minutes left... what do we hope to resolve by the end of the meeting? | 15:41 | |
| pjones | mcepl: making sure that there's adequate information in the bug that it can be reasonably worked on by a developer, and making sure it's assigned to that developer. | 15:41 |
| comphappy | alindebe: We need to work as a whole project | 15:41 |
| alindebe | comphappy: Why? | 15:41 |
| mcepl | poelcat: right, anything else on the agenda? | 15:41 |
| tk009 | yes one item | 15:41 |
| alindebe | comphappy: anaconda has been doing fine not being a part of bugzappers | 15:41 |
| * poelcat isn't running the meeting :) | 15:41 | |
| tk009 | which is why I let this go | 15:41 |
| tk009 | we all agree we want to help | 15:42 |
| comphappy | alindebe: This is fedora | 15:42 |
| mcepl | pjones: OK, which is IMHO exactly what we expected ASSIGNED bug should be. | 15:42 |
| pjones | mcepl: sure, except that's not what you were saying earlier -- I want ASSIGNED to actually have a developer's name on it. | 15:42 |
| mcepl | alindebe: of course, and if you want to stay it that way, I have no problem with that. But why then we are tlaking here? | 15:42 |
| alindebe | mcepl: I was asked to? | 15:43 |
| alindebe | And I would like help | 15:43 |
| tk009 | ok we can continue this on the mail list and in next weeks meeting. | 15:43 |
| alindebe | but | 15:43 |
| tk009 | you are helping alindebe | 15:43 |
| tk009 | jsut being here | 15:43 |
| tk009 | I didn't mean to cut you off | 15:43 |
| tk009 | please say what yo uwanted to alindebe | 15:44 |
| alindebe | Just that, I would love having help. But I'm worried that people just jumping in without understanding how weird anaconda and its bugs can really be would be chaotic at best. | 15:45 |
| pjones | (and I don't know why ON_DEV exists at all in environment without a dev->staging->production methodology.) | 15:45 |
| alindebe | So | 15:45 |
| tk009 | we wont jsut jump in | 15:45 |
| tk009 | that is why we are talking now | 15:45 |
| alindebe | if people would be willing to read the anaconda workflow, check out bugs, figure out what *they* think is going on, and then talk to the developer | 15:45 |
| alindebe | to get a handle on anaconda and its bugs | 15:45 |
| tk009 | that is a fair request | 15:46 |
| alindebe | I'd be more comfortable with, in the future, just going to it | 15:46 |
| azneita | i'm reading it now and i find it workable | 15:46 |
| alindebe | *I'm* still wary of assigning bugs without checking first | 15:46 |
| azneita | though i'm not really a sophisticated triager yet | 15:46 |
| mcepl | that is, but if you want to attract as many quality bug triagers as possible, then you probably have to lower the bar as much as possible, but that's really getting off topic here. | 15:47 |
| comphappy | From a metrics point of view I can only tayler to one workflow | 15:47 |
| alindebe | comphappy: So don't triage anaconda | 15:47 |
| comphappy | alindebe: I am not I am talking metrics | 15:47 |
| tk009 | clam please | 15:47 |
| tk009 | we will work together | 15:47 |
| alindebe | If people can get to the point where they can see a bug, correctly identify the problem, ask for the right info and assign to the right developer, I'm fine with that | 15:48 |
| mcepl | tk009: I think we are pretty claim *this time* ;-) | 15:48 |
| tk009 | I am not sure =P | 15:48 |
| alindebe | but while adjusting, I'd really, really prefer if they checked on IRC with the person before sending them bugs that don't belong | 15:48 |
| tk009 | then that is what we will do | 15:48 |
| tk009 | no muss no fuss | 15:48 |
| alindebe | lovely :) | 15:49 |
| mcepl | OK, so let's make conclusion that we will try to attract as many anaconda volunteers as possible but we will warn them sterly, that they have to learn before committing to the component and talk with developers. | 15:49 |
| comphappy | If the correct dev cannot be identified I don't assign it to them in our workflow | 15:49 |
| mcepl | alindebe: BTW, sorry my ignorance, is there #fedora-anaconda channel? | 15:49 |
| alindebe | mcepl: #anaconda | 15:49 |
| denise | if you guys have questions, we can hang out on bugzappers and answer | 15:49 |
| mcepl | thanks | 15:49 |
| tk009 | thank you denise | 15:50 |
| alindebe | comphappy: If the correct developer can't be identified, it should be left in NEW | 15:50 |
| tk009 | now I will cut everyone off... sorry | 15:50 |
| mcepl | tk009: what do you think abot my conclusion? | 15:50 |
| comphappy | Yes that is what I do | 15:50 |
| tk009 | last item and 10 minutes left | 15:50 |
| mcepl | tk009: OK, go ahead | 15:51 |
| tk009 | #topic - Component list update for the F12 cycle - Update on status. | 15:51 |
| tk009 | this was an action of mine | 15:51 |
| tk009 | after talking to jds2001 and f13 | 15:51 |
| tk009 | they advised using critical components path they were working on as par of FAD | 15:52 |
| tk009 | I should have the link but I am slack and don't atm | 15:52 |
| mcepl | FAD? | 15:53 |
| tk009 | Fedora activity day | 15:53 |
| mcepl | oh, I see | 15:53 |
| tk009 | the big brains got together | 15:53 |
| tk009 | came up with some good stuff | 15:53 |
| tk009 | as that is a work in progress I wanted to know how we should go forward with updating our components page | 15:55 |
| tk009 | it y fault not having the link but there is little there at the moment anyway | 15:56 |
| tk009 | any thoughts | 15:56 |
| tk009 | with time running out | 15:56 |
| tk009 | *crickets* | 15:57 |
| tk009 | other for the mailing list I guess | 15:57 |
| tk009 | anyone have anything they want to say before I end the meeting? | 15:58 |
| tk009 | okay then see you all in #fedora-bugzappers | 15:58 |
| arxs | i yust wait if the meeting is done and ask on the bugzappers channel :) | 15:58 |
| comphappy | I have a major update to the metrics I was playing with last night | 15:59 |
| comphappy | I have a meeting tonight but might be up by next morning | 15:59 |
| tk009 | we can talk more in the bz channel | 15:59 |
| M_J_G | Does the anaconda discussion apply to the kernel component as well (topic was kernel...)? | 15:59 |
| tk009 | #endmeeting | 15:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!