16:01:41 <jlaska> #startmeeting Fedora QA Meeting
16:01:42 <zodbot> Meeting started Mon Feb  1 16:01:41 2010 UTC.  The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:44 <jlaska> #meetingname qa
16:01:44 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:46 <zodbot> The meeting name has been set to 'qa'
16:01:53 <jlaska> #topic Gathering
16:02:42 <adamw> yo
16:02:57 <jlaska> adamw: happy monday :)
16:03:18 <jlaska> who else can we convince to join us for a meeting?
16:03:28 * kparal convinced
16:03:31 <adamw> yeah, yeah, keep it short, whatever, i have important cellphone hacking to do :P
16:03:38 <jlaska> I can see that! :P
16:03:52 <jlaska> adamw: you must join the meeting using one of those phones
16:03:53 <kparal> adamw: you are a blogging superman :)
16:04:04 * maxamillion is here
16:04:11 <adamw> jlaska: gimme 2 minutes and i will
16:04:13 <jlaska> hi kparal, maxamillion
16:04:22 <jlaska> adamw: uh oh ... that wasn't meant as a dare :)
16:05:11 <jlaska> who else we have?  wwoods Viking-Ice tk009 ?
16:06:13 <jlaska> alright, let's get started and hopefully they can join in
16:06:17 <jlaska> #topic previous meeting follow-up
16:06:34 <jlaska> #info jlaska to add bugzilla shared query links to Common_Bugs wiki page
16:07:02 <jlaska> #info beland added the links to the F-13 page already ... https://fedoraproject.org/wiki/Common_F13_bugs
16:08:15 <jlaska> The only other thing that occured to me was perhaps updating our IRC RSS feeds that zodbot tracks
16:08:48 * nirik can do that later today if you let me know what to change it to/etc.
16:08:51 <jlaska> I'll take an action item to grab the blocker bug RSS feeds and see if nirik can update zodbot to watch those links
16:09:09 <jlaska> nirik: thanks!
16:09:18 <nirik> no problem.
16:09:30 <jlaska> #action request zodbot tracking for updated F-13 QA RSS feeds (blocker bugs, common_bugs? etc...)
16:09:36 * adamw now meetingggggg on his phone :)
16:09:40 <nirik> I noticed the other day it spewed something about the f12 blockers... meant to look at it.
16:09:56 <jlaska> nirik: we can probably replace the F-13 ones with the new feeds?
16:10:06 <jlaska> adamw: you're nuts :)
16:10:12 <jlaska> okay, next up I have ...
16:10:13 <adamw> Pic available if proof desired!
16:10:19 <jlaska> #info wwoods and kparal to talk about design ideas
16:10:20 <nirik> f12 you mean? yeah. I think currently it's announcing any change to the f12 blocker
16:10:29 <jlaska> I think this came out of the AutoQA discussion last week
16:10:49 <jlaska> nirik: yeah, sorry ... replace the F-12 ones with the newer F-13 feeds
16:11:17 <jlaska> kparal: wwoods: do you have insight as to what was being tracked by this action item?
16:11:56 <kparal> jlaska: I believe it meant we should have consulted the future results database design?
16:12:12 <kparal> jlaska: which we didn't :/
16:12:22 <adamw> http://www.happyassassin.net/extras/irc_meeting.jpg
16:13:00 <kparal> adamw: nice!
16:13:05 <jlaska> kparal: ah right ... hmm, what are your thoughts there.  what is needed to do a good design review on that?
16:13:17 <jlaska> adamw: that's cute :)
16:13:54 <maxamillion> adamw: what irc client is that?
16:13:57 <jlaska> adamw: normally, I'd say this would impact your words/minute.  But I don't think it will :)
16:14:00 <adamw> maxamillion: andchat
16:14:13 <maxamillion> adamw: interesting ... I'll have to check it out
16:14:15 <maxamillion> :)
16:14:17 <adamw> jlaska: i'm cheating, i'm typing on my pc now :P
16:14:19 <wwoods> jlaska: yeah we were going to talk about design ideas for the results database
16:14:23 <kparal> jlaska: I believe several should get involved, so we don't make any oversights right in the design. maybe some people that already designed some koji parts could help us
16:14:40 <adamw> maxamillion: it vibrates for nick alerts - stop buzzing my knee :D
16:14:41 <maxamillion> adamw: when did you get an android device?
16:14:45 <maxamillion> LOL
16:14:48 <kparal> *several people
16:14:51 <adamw> maxamillion: > #fedora-qa let's not derail
16:14:57 <maxamillion> rgr, sorry
16:16:21 <jlaska> kparal: re: koji ... do you mean like lmacken?
16:16:39 <jlaska> perhaps a micro-FAD would be helpful to get the right folks involved
16:17:26 <kparal> jlaska: I don't know about lmacken, for e.g. dmach hinted me to look at his kobo library several times. https://fedorahosted.org/kobo/
16:17:38 <jlaska> kparal: aah right
16:17:48 <wwoods> ugh
16:17:56 <wwoods> xmlrpc with cookies? krb5?
16:17:57 <kparal> jlaska: it might be some inspiration for us, I think there is a hub part that store results
16:17:58 <jlaska> kparal: probably a good idea for us to outline what our needs are first?
16:18:02 <Oxf13> kobo looked waaaay to overengineered for the stuff I needed
16:18:17 <wwoods> kobo is a great idea for building RHEL-internal apps
16:18:33 <kparal> I haven't studied it yet
16:18:35 <wwoods> but very poorly suited to fedora needs
16:18:56 <kparal> just looking for places where we can gather some ideas about the results DB
16:19:21 <skvidal> ugh
16:19:23 <wwoods> yeah it's still worth looking at other things that are around
16:19:26 <kparal> jlaska: yes, we should brainstorm about the needs first
16:19:29 <skvidal> b/c we need ANOTHER implemention of rpm header parsing
16:19:47 <wwoods> but there's no reason the results db needs to be able to parse RPM headers
16:20:12 <kparal> don't dump it everyone, we can have a look at some specific parts, not use everything at once :)
16:20:13 <wwoods> honestly there's no reason it needs to be anything more than, say, a TG app, as far as I can see
16:20:29 <wwoods> but that's still a very very broad canvas for design
16:20:40 <jlaska> in the interest of time ... is there a next step to keep track of here?
16:20:59 <kparal> wwoods already has some expertiese with irb frontend, so I suppose he will be the leader in this area :)
16:21:17 <wwoods> I'd suggest we should outline some requirements and goals before we start looking at tools/implementations
16:21:27 <jlaska> that seems sensible
16:21:31 <kparal> the next step should be the brainstorming meeting for those of us concerned I think
16:21:36 <wwoods> kparal: agreed
16:21:54 <kparal> we just must not forget about it :)
16:22:12 <jlaska> would you like me to organize a gobby meeting this week to review?
16:22:34 <kparal> sounds good for me
16:22:52 <wwoods> sure
16:22:57 <jlaska> #action jlaska to organize a gobby meeting to begin requirements/goal definition for a results db
16:23:07 <jlaska> alright ... last follow-up item ...
16:23:21 <jlaska> #info adamw update on security policy
16:24:02 <jlaska> The info I have is Adam moved the discussion from test@l.fp.org to devel@l.fp.org (http://lists.fedoraproject.org/pipermail/devel/2010-January/129978.html)
16:24:12 <jlaska> adamw: any other updates?
16:24:49 <adamw> sorry!
16:25:00 <adamw> nope, that's it - i did that before the weekend so haven't read the responses yet
16:25:02 <jlaska> adamw: no TXT'ing while MTG :)
16:25:28 <adamw> i intend to follow the same process i did for test list
16:25:37 <jlaska> okay, should we keep this on the radar for next week?
16:25:44 <adamw> do a new draft from the current responses, then send that, keep cycling until no-one has anything to complain about :)
16:25:45 <adamw> sure
16:26:03 <jlaska> #info adamw will continue monitoring feedback (http://lists.fedoraproject.org/pipermail/devel/2010-January/129978.html) and propose updated drafts as needed
16:26:16 <jlaska> alright, let's dive in ...
16:26:21 <jlaska> #topic Release validation wiki updates
16:26:29 <jlaska> adamw: I've got you on the spot for this as well, can you cover for rhe?
16:26:49 <jlaska> Just wanted to give a quick update on the wiki changes you and rhe have been working on
16:27:05 <adamw> yup
16:27:17 <adamw> so far we've added the installation validation testing wiki page:
16:27:25 <adamw> #link https://fedoraproject.org/wiki/QA:Installation_validation_testing
16:27:39 <adamw> a desktop validation testing wiki page, which is still full of duct tape:
16:27:46 <adamw> https://fedoraproject.org/wiki/QA:Desktop_validation_testing
16:27:54 <adamw> and modified the QA/Join page to mention this testing:
16:28:09 <jlaska> heh, the many uses of duct tape :)
16:28:26 <adamw> https://fedoraproject.org/wiki/QA/Join#Release_validation
16:29:06 <jlaska> adamw: I wanted to ask, would you like to have the QA schedule changed to reference 'release validation' and not specifically 'install validation' so there is room for other efforts?
16:31:24 <jlaska> okay, we can come back to that if needed, lemme keep on going
16:31:32 <jlaska> nice wiki updates rhe and adamw :)
16:31:34 <adamw> jlaska: i think that would be a good change
16:31:52 <jlaska> adamw: okay, I'll ping get in touch with poelcat later this week then
16:32:15 <jlaska> #action jlaska to discuss updating QA schedule with poelstra to reflect new 'release validation' focus
16:32:18 <adamw> there will be other types of validation we could do in future; there's already a couple of criteria we can test that don't really come under installation or desktop
16:32:40 <jlaska> I'd love to get off my butt and do the QA release checklist
16:32:45 <jlaska> to include in that mix
16:33:19 <jlaska> adamw: anything else on the wiki front?
16:33:44 <adamw> um, nothing springs to mind
16:33:47 <adamw> was that a leading question? :)
16:33:56 <adamw> i didn't get around to updating commonbugs yet :(
16:34:06 <jlaska> no, not a leading question
16:34:32 <jlaska> alright, moving on to another quick update ...
16:34:37 <jlaska> #topic Rawhide Acceptance Testing
16:34:50 <jlaska> we had another RATS drop last Thursday
16:35:11 <jlaska> jkeating composed a tree for rats_install (see rell-eng ticket#3292).
16:35:40 <jlaska> I had to correct a few typos with the rats_install patches designed to support providing stage2= and repo= ... but all-in-all it worked well
16:35:51 <jlaska> #link https://fedoraproject.org/wiki/Test_Results:Fedora_13_Rawhide_Acceptance_Test_2
16:35:52 <Oxf13> did it pass?
16:36:05 <jlaska> Oxf13: well it passed, but there's a _but_
16:36:20 <jlaska> bug#559597 prevents initramfs creation ... so it won't boot without that fixed
16:36:47 <Oxf13> oh right
16:36:50 <jlaska> so one dracut-004-5 lands, we should be good
16:36:56 <Oxf13> but you can use the images with a later rawhide tree
16:37:00 <jlaska> at least for the automated portion of rats_install
16:37:08 <jlaska> Oxf13: right, the packages from a newer rawhide
16:37:17 <jlaska> I don't think we need to update the install images for this, right?
16:38:01 <jlaska> Oxf13: so how would you like to proceed ... want a ticket to update the 'last known good' ?
16:38:25 <Oxf13> jlaska: we probably shouldn't do that until the package tree has the right dracut level and we verify that
16:38:33 <jlaska> Oxf13: oh agreed
16:38:37 <Oxf13> this does bring up a good question though
16:38:54 <Oxf13> does "last known good" mean a set of images, a set of packages, or the combination of the two?
16:39:13 <jlaska> #info Oxf13 asked ... does "last known good" mean a set of images, a set of packages, or the combination of the two?
16:39:28 <jlaska> from a testing perspective ... it means images + packages
16:39:47 <jlaska> as soon as one changes, I think that adds a caveat to the 'last known good'
16:39:56 <Oxf13> I suppose for users it's useful to have images which we  expect to work, which can be tested against package sets which we're not sure of
16:40:18 <Oxf13> all releng would be tracking and providing symlinks to is the set of images
16:40:50 <jlaska> Oxf13: true, so this is intended to increase install reliability ... but is still open to rawhide package churn
16:40:56 <adamw> i think it's as simple as putting a rawhide date on the 'last known good' listing
16:41:04 <adamw> and a note that says it was known to work with that day's packages
16:41:12 <adamw> may work with other days, but we can't say for sure
16:41:31 <jlaska> agreed, I think we just need some wording around this so it's clear
16:42:09 * poelcat thought LKG was a fully installable source, including images so people did not have to go all the way back to F12 for a reliable starting place
16:42:24 <jlaska> think it's time to get some documentation down for this
16:42:30 <jlaska> any volunteers :)
16:43:03 <adamw> i can do it if you let me know roughly what's needed
16:43:31 <jlaska> adamw: given the questions here, I think defining what 'last known good' means
16:44:27 <jlaska> it's a term we use a lot, but sounds like there is still some confusion around what's included
16:45:09 <Oxf13> part of that was just working through the mechanics of actually doing it
16:45:15 <jlaska> true true
16:45:25 <Oxf13> it's far easier to store a small set of images, and then reference an existing tree of packages somewhere
16:45:36 <Oxf13> or let the images autopick the latest rawhide for more fun
16:45:39 <adamw> i think this is a case where we should do the mechanics and then i will write an explanation which sounds like we knew what we were doing all along =)
16:46:08 <jlaska> okay, in that case I think we're probably done then
16:46:19 <jlaska> Oxf13: are there other changes coming on the rel-eng side of building these?
16:46:35 <Oxf13> um...
16:46:41 <Oxf13> how do you mean?
16:47:12 <jlaska> how do we know when we're done with providing 'last known good'?
16:47:18 <jlaska> how can we [X] check it off
16:47:21 * adamw is the king of retrospective-justification-through-wikis
16:47:35 <jlaska> adamw: it's still 20/20 right? :)
16:47:56 <Oxf13> jlaska: in my head there is a simple webpage that is maintained by QA
16:48:13 <Oxf13> this webpage describes Last Known Good and the fact that rawhide no longer has images of it's own
16:48:30 <Oxf13> onthis page would be links to the install image files, and to the tree of packages it was found to be good with
16:48:38 <Oxf13> with instructions on how to combine the two into an install
16:48:58 <adamw> if you give me canonical locations for lng installer images and package tree i can totally make a wiki page for that.
16:49:08 <adamw> also, those instructions :D
16:49:09 <jlaska> Oxf13: ah that's helpful
16:49:09 <Oxf13> and finally notes that without picking a specific repo of packages, the images will attempt to install the latest repo of packages on the mirror system
16:49:19 <Oxf13> which has not been validated, and may not work
16:49:47 <jlaska> alright, adamw I'll be happy to work the details with you
16:50:06 <adamw> okay
16:50:07 <adamw> action it?
16:50:07 <jlaska> #info jlaska and adamw to work on drafting a 'last known good' wiki page
16:50:13 <jlaska> err ...
16:50:17 <jlaska> #action jlaska and adamw to work on drafting a 'last known good' wiki page
16:50:43 <jlaska> Oxf13: thanks ... will probably pick your brain again during the week
16:50:56 <Oxf13> no problem
16:50:59 <jlaska> okay ... time for AutoQA update!
16:51:02 * jlaska hits the gong
16:51:05 <jlaska> #topic AutoQA project update
16:51:13 <jlaska> #topic AutoQA project update - deps/conflicts prevention
16:51:30 <jlaska> wwoods: you want to kick things off for the AutoQA update?
16:51:54 <wwoods> sure
16:52:08 <wwoods> Friday afternoon I got a working yum-based prototype of the depcheck code
16:52:30 <wwoods> http://git.fedorahosted.org/git/?p=autoqa.git;a=blob;f=tests/depcheck/depcheck
16:52:35 <jlaska> saweet!
16:52:48 <wwoods> a mere 147 lines, even
16:53:15 <wwoods> I need to start creating test cases to make sure it works as expected
16:53:24 <wwoods> typical runtime is ~20s
16:53:32 <jlaska> wow, you really brought that down from the 60s
16:53:51 <wwoods> ~15s for leaf-node packages (e.g. something like hamster-applet)
16:54:07 <wwoods> ~19-20s for packages with lots of prov/req data (e.g. gcc)
16:54:16 <jlaska> that's pretty darned good
16:54:18 <wwoods> but "20s" is a safe estimate
16:54:35 <wwoods> probably it can be sped up further
16:54:43 <wwoods> but premature optimization is the root of all evil, and all that, so.. later
16:54:50 <jlaska> heh
16:55:00 * jlaska stuffs a few #info tags into the mix
16:55:08 <jlaska> #info Friday afternoon I got a working yum-based prototype of the depcheck code
16:55:13 <jlaska> #link http://git.fedorahosted.org/git/?p=autoqa.git;a=blob;f=tests/depcheck/depcheck
16:55:56 <jlaska> not that this is blocking your efforts, but I'm waiting for some feedback from jhutar, but rpmfluff should be an official fedora package soon
16:56:03 <wwoods> excellent
16:56:20 <wwoods> yeah I think I'd like to use rpmfluff etc. to generate test packages/repos
16:56:23 <wwoods> for the test cases
16:56:36 <jlaska> that'll be great to see
16:56:37 <wwoods> yum's test cases involve creating objects which *simulate* test packages/repos/etc.
16:57:17 <wwoods> not sure if that makes a significant difference
16:57:37 <jlaska> just having a testsuite at all for this I think will pay off in the long run
16:57:42 <wwoods> definitely.
16:57:43 <jlaska> given the complexity
16:57:50 <jlaska> nice work!
16:58:31 <jlaska> wwoods: anything else on the depcheck front?
16:58:40 <wwoods> no, I think that covers it
16:58:48 <jlaska> sweet, alright ... kparal's up next
16:59:01 <kparal> ok
16:59:02 <jlaska> #topic AutoQA project update - rpmguard and resultsdb
16:59:18 <kparal> so I have updated a few tickets regarding rpmguard
16:59:22 <kparal> first is https://fedorahosted.org/autoqa/ticket/113
16:59:24 <jlaska> take it away kparal
16:59:54 <kparal> when comparing the exactly same packages the rpmguard will now just skip the comparison and print a notice that they are the same
17:00:18 <kparal> that could save a little computing power
17:00:57 <jlaska> aha, nice ... that test run confused the heck out of me :)
17:00:58 <kparal> it was connected to our problem of comparing the same package unintentionally
17:01:34 <kparal> and second ticket connected to that is https://fedorahosted.org/autoqa/ticket/114
17:01:59 <kparal> before we compared the current package with the latest package from stable, updates or updates-testing
17:02:18 <kparal> now we compare only to stable and updates, as per discussion on autoqa-devel
17:02:36 <jlaska> nice to see all this stuff getting hashed out
17:02:44 <kparal> and also we compare to the latest *previous* package (so it should not happen to compare two equal packages)
17:03:35 <kparal> this also allows us to run the test any time in the future, even against older packages (in that time already in stable or updates, not in updates-candidate) and receive the same results
17:03:51 <jlaska> oh so if I ran that test again, it should be grabbing ... yup, you just answered it
17:03:58 <kparal> this can be beneficial when we find some problem in autoqa/rpmguard and need to re-run the test suite again
17:04:04 <jlaska> #info I have updated a few tickets regarding rpmguard
17:04:11 <jlaska> #link ttps://fedorahosted.org/autoqa/ticket/113
17:04:12 <jlaska> #link ttps://fedorahosted.org/autoqa/ticket/114
17:04:19 <jlaska> #link https://fedorahosted.org/autoqa/ticket/113
17:04:19 <jlaska> #link https://fedorahosted.org/autoqa/ticket/114
17:04:21 <adamw> side note on rpmguard: we should talk about the privesc stuff at some point, since that looks like it may turn into a Real Thing
17:04:36 * jlaska gets flagged for incorrect use of meetbot
17:04:54 <kparal> adamw: privesc?
17:05:39 <jlaska> #info adamw discussed possible rpmguard and privilege escalation coordination
17:05:45 <kparal> ah
17:05:48 <jlaska> kparal: that's the security policy Adam'w been working
17:05:58 <kparal> just didn't know the abbreviation :)
17:06:03 <Oxf13> jlaska: fyi, meetbot picks up links automatically, you don't have to #link them
17:06:10 <jlaska> Oxf13: ah, thx
17:06:35 <kparal> ok, that's all from me
17:07:02 <jlaska> kparal: also the results db discussion earlier, hopefully I can help get some of you and wwoods ideas on "paper" this week
17:07:26 <jlaska> kparal: thanks for the updates!
17:07:31 <kparal> e-paper = wiki :)
17:07:36 <jlaska> you got it
17:07:49 <jlaska> #topic AutoQA project update - install automation
17:08:23 <jlaska> #info Liam added a dvd_install.py script to the autoqa git repo last week
17:08:27 <jlaska> https://fedorahosted.org/pipermail/autoqa-devel/2010-January/000178.html
17:08:47 <jlaska> it raises some interesting questions for me on how we'll approach automating the install matrix
17:09:02 <jlaska> wwoods: if you have some time this week, I could use your input on that thread as well
17:09:22 <wwoods> jlaska: yeah I've been meaning to give that a closer look
17:09:43 <jlaska> ah thank you
17:10:08 <jlaska> you know the usual ... trying to figure out what path is the most sustainable and scalable for building new install tests :)
17:11:15 <jlaska> Liam has some more thoughts on the mailing list, I'll try to reply later today
17:11:25 <jlaska> so that's great news, hopefully more install tests to come soon
17:11:34 <jlaska> alright ... last up ...
17:11:39 <jlaska> #topic AutoQA projet update - packaging
17:11:55 <jlaska> #info Process akurtakov's feedback and remove all uncertain JAR files from the list
17:12:17 <jlaska> I've got the list down to as small as I can get it ... adamw suggested reaching out to GWT upstream for some additional feedback
17:12:31 <jlaska> so the plan this week is to Seek guidance from upstream GWT for ...
17:12:42 <jlaska> * Cases where multiple versions of a JAR are bundled
17:12:59 <jlaska> * Need for remaining bundled JARs? (see https://fedoraproject.org/wiki/User:Jlaska/gwt#Status_uncertain)
17:13:20 <jlaska> and ideally, I'd like to have one of the listed JPackage dependencies already started through the Fedora packaging process
17:13:31 <jlaska> https://fedoraproject.org/wiki/User:Jlaska/gwt#JPackage_Dependencies
17:14:04 <jlaska> aside from that ... I've been going through the gwt.spec and removing JAR files and linking them to their equivalents (and adding BuildRequires)
17:14:13 <jlaska> alright ... open discussion time
17:14:20 <jlaska> #topic Open discussion - <your topic here>
17:14:38 <jlaska> I'll close out the meeting in 2 minutes unless any topics come up
17:14:47 <kparal> ok, one topic from me
17:14:54 <jlaska> kparal: sure, what's up?
17:14:56 <kparal> package update acceptance test plan
17:15:08 <kparal> I just have a quick call for links :)
17:15:13 <jlaska> oh oh, right on
17:15:26 <jlaska> #topic Open discussion - Package Update Acceptance test plan
17:15:31 <jlaska> #info kparal put out a call for links
17:15:40 <jlaska> kparal: what sort of links are you looking for?
17:15:45 <kparal> I'm currently working on package update acceptance test plan, that means what should be our approach to decide if some package update is good or not
17:16:06 <kparal> I am currently looking into other distributions how they do it and trying to gather some inspiration
17:16:38 <kparal> if somebody is aware of some documented policies and have links for them, I will be very glad if you send them to me
17:17:04 <kparal> it is quite possible that I don't find everything that is available
17:17:12 <jlaska> kparal: I wonder if the MUST and SHOULD items could provide some insight - http://fedoraproject.org/wiki/Packaging:ReviewGuidelines
17:17:44 <kparal> yes, currently I have found mainly requirements for the initial review process
17:18:00 <kparal> but I haven't found many documents concerning package updates requirements
17:18:20 <adamw> i'm sure debian must have a policy
17:18:22 <jlaska> perhaps what wwoods is working on might be included in the mix?  the depscheck stuff
17:18:27 <kparal> it is possible that other distributions also don't have strict policies about that
17:18:46 <kparal> but - if you know about such a policy and have a link, please send it to me. thanks :)
17:19:04 <kparal> that was all from me, just a call for links
17:19:04 <adamw> kparal: http://wiki.mandriva.com/en/Policies/SoftwareMedia
17:19:12 <adamw> kparal: i wrote that for MDV back when I was there
17:19:14 <jlaska> Oxf13: you have any handy links?
17:19:23 <adamw> kparal: see the definitions for the 'updates' repositories
17:19:34 <kparal> adamw: thanks, will look at that
17:19:52 <adamw> kparal: also see http://wiki.mandriva.com/en/Policies/Support , the full policy for maintainers about updates
17:20:12 <adamw> kparal: that was written by vincent danen when he was at mandriva, he also now works at red hat so you could always poke him for thoughts :) look for vdanen
17:20:28 <kparal> adamw: great, thx
17:20:31 <Oxf13> jlaska: I don't
17:21:40 <jlaska> #topic Open discussion - <your topic here>
17:21:52 <jlaska> anything else to cover, if not let's close it out
17:22:15 <adamw> nothing frm me
17:22:46 <jlaska> alright gang, thanks for your time!
17:22:54 <jlaska> I'll follow-up to the list with minutes etc...
17:22:56 <jlaska> #endmeeting