16:00:42 <jlaska> #startmeeting Fedora QA Meeting
16:00:42 <zodbot> Meeting started Mon Nov 23 16:00:42 2009 UTC.  The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:42 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:56 <adamw> morning
16:01:16 <jlaska> #topic gathering critical mass
16:01:31 <jlaska> hmm, I forget which tag gives the meeting a specific title
16:01:34 <jlaska> #meetingtitle qa
16:01:58 * kparal is here
16:02:02 * tk009 is here
16:02:06 * jeff_hann here
16:02:23 <jlaska> adamw: kparal tk009 jeff_hann - welcome :)
16:02:37 * Viking-Ice pops up..
16:02:48 * poelcat here
16:02:48 * wwoods aliiiiive
16:02:59 * Oxf13 
16:03:02 <Oxf13> lucky to be alive
16:03:06 * jlaska tips hat to Viking-Ice, poelcat, wwoods and Oxf13
16:04:00 <jlaska> okay, let's get started then
16:04:18 * jlaska walking through proposed agenda https://www.redhat.com/archives/fedora-test-list/2009-November/msg00989.html
16:04:28 <jlaska> #topic Previous meeting follow-up
16:04:44 <jlaska> *  jlaska will propose Common_F12_Bugs after meeting for bug#530541
16:04:45 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=530541 medium, low, ---, skvidal, CLOSED ERRATA, Free space check on /boot not thorough enough
16:05:15 <jlaska> well, this is done ... thanks of course to adamw for his mastery of wiki documentation!
16:05:26 <jlaska> you can see what came out of this at ...
16:05:27 <jlaska> https://fedoraproject.org/wiki/Common_F12_bugs#preupgrade-boot
16:05:39 <jlaska> and some re-organization done to ...
16:05:40 <jlaska> https://fedoraproject.org/wiki/How_to_use_PreUpgrade
16:05:52 <adamw> np
16:05:58 <jlaska> so thanks adamw and wwoods for the guidance there :)
16:06:04 <jlaska> next up ... somewhat related ...
16:06:07 <jlaska> *  preupgrade test updates
16:06:39 <jlaska> for those following along with the home game ... rhe is helping by updating the existing preupgrade test cases to ensure we're catching this behavior
16:06:47 <jlaska> For details, checkout the trac ticket ...
16:06:48 <jlaska> https://fedorahosted.org/fedora-qa/ticket/30
16:07:06 <wwoods> oh, that's "updates to the preupgrade tests" not "updated preupgrade packages in updates-testing"
16:07:26 <jlaska> wwoods: yeah, you got it
16:07:47 <jlaska> Hurry has helped cleanup the existing cases ... and with some guidance from kparal, a new case should be coming to target the /boot behavior
16:08:28 <jlaska> that'll probably finish up in a week, but just wanted to let folks know where it was
16:08:34 <jlaska> next up ...
16:08:35 <jlaska> *  jlaska to send request for retrospective feedback to fedora-test-list@
16:08:52 <jlaska> as you can probably tell, I've not managed to task this last week
16:08:57 * jlaska wears the cone of shame
16:09:38 <jlaska> I'm hoping to get this out this week of course ... so we can start the F12 retrospective and F13 planning process
16:09:40 <adamw> bad jlaska
16:09:53 <jlaska> indeed!
16:10:04 <jlaska> okay, that's all I had in the minutes from last week
16:10:17 <jlaska> I know folks have been busy, are there any other items to follow-up on that I missed?
16:10:23 * poelcat was wondering about having a release wide retrospective at FUDCon
16:10:41 <poelcat> would that be appealing to people or would they rather use our time there on something else?
16:10:41 <jlaska> poelcat: ooh, not a bad idea
16:11:14 <poelcat> it's easy to say "let's do ____ at FUDCon" but the time always goes fast!
16:11:23 <jlaska> definitely
16:12:04 <jlaska> well, I'm not opposed to it ... I've not figured out a great plan for processing the retrospective feedback ... other than documenting it on the wiki, and asking folks to think about areas they'd like to tackle to address the pain points
16:12:15 <jlaska> so, I'm open to different approaches
16:13:02 <jlaska> we can bounce around ideas on that after the meeting if you like
16:13:08 <poelcat> okay
16:13:10 <poelcat> carry on :)
16:13:17 <jlaska> and if no one responds to he mail ... I guess that helps answer it :)
16:13:21 <jlaska> s/he/the/
16:14:02 <jlaska> okay ... swim suits on please ... let's dive in ...
16:14:08 <jlaska> #topic Security test plan
16:14:17 <Viking-Ice> This is something that each spin SIG needs to decided and adjust to their target audience and or the purpose of the spin.
16:14:25 <Viking-Ice> You can not impose the same rules on Desktop vs workstation/server deployment.
16:14:35 <Viking-Ice> The recent pk-fiasco was blown out of proportion and is a typical example for an incompetent admin who used and deploy an image who's target audience was home desktop end user ( Which I believe all the live *DE spins are as in being the latest *DE technology preview for the home desktop end user ) in a multiuser corporate/enterprise environment.
16:15:01 <poelcat> jlaska: can you give a little background by what you mean on a security test plan?
16:15:04 <adamw> Viking-Ice: PackageKit is on every default Fedora installation.
16:15:04 <Viking-Ice> I have no clue to who releng target audience is with the dvd img but i'm pretty sure that's not workstation/server deployment.  if it is it should follow what's documented/recommended on CSI ( https://fedorahosted.org/csi ).
16:15:07 <jlaska> poelcat: sure
16:15:14 <adamw> Viking-Ice: and that's not on-topic for us anyway.
16:15:23 <jlaska> so ... not really interested in churning up the waters on this front
16:15:31 <wwoods> no, I think it's on-topic to a certain extent;
16:15:40 <jlaska> it's been done plenty already and it seems the issues is being worked
16:15:51 <jlaska> what I wanted thoughts on from the group was something spot blogged about
16:15:52 <wwoods> the proposed security test plan includes a bunch of test cases tailor-made for a corporate workstation/server deployment
16:16:05 <wwoods> which is inappropriate for the board-defined use cases for the default spin
16:16:09 <wwoods> and for most of our other desktop spins
16:16:25 <wwoods> I think we can agree that the plan - as with all test plans - needs to be tailored to the needs of the spin
16:16:34 <adamw> where is 'the proposed security test plan'?
16:16:38 <wwoods> I think it also points out the need for a Server/Workstation spin.
16:16:40 <jlaska> http://spot.livejournal.com/312216.html
16:16:51 <jlaska> adamw: 2 parts to this ... what spot posted is certainly not the final product
16:17:07 <jlaska> Viking-Ice: and wwoods correctly note that there may be SIG specific test cases/areas for the tplan
16:17:10 <adamw> all of that seems perfectly sensible for _any_ multi-user setup. nothing corporate.
16:17:20 <adamw> if i were running a family PC that's pretty much what I'd want.
16:17:43 * spot notes that there are additional revisions to that which need to be made
16:17:47 <jlaska> I think we can certainly build into the plan a way to call out SIG specific tests
16:17:58 <jlaska> spot: yeah, I was reading the comments and going to ask where your "master copy" was
16:18:01 <poelcat> jlaska: so prior to final, QA would go through the list and verify each of them?
16:18:10 <jlaska> poelcat: so that's the thinking ...
16:18:19 <spot> jlaska: i was updating the post as the master copy initially, but i got busy and couldn't keep up
16:18:23 <jlaska> first ... someone would propose a test plan that touches on the content spot highlights
16:18:47 <spot> jlaska: i'll update it now
16:19:00 * adamw notes that most of those complaining about the PK issue were not corporate users, they were people with _home_ multi-user systems
16:19:06 <jlaska> once we have content we are all reasonably comfortable with and is something the team can manage ... I'd look to get this on the schedule for testing somehow
16:19:06 <wwoods> re-reading the list of stuff spot's got.. I think I agree with adamw, those items - and that definition of "unprivileged" - are very reasonable
16:19:11 <adamw> well, apart from the ones who were just complaining because they had nothing better to do.
16:19:37 <wwoods> and there are certainly things in the comments that people who want spins with stronger default policies might like to write test cases for
16:19:37 <adamw> but yeah, i find spot's list very reasonable and simple and a great place to start.
16:19:56 <jlaska> anyone interested in taking a stab at some initial content here?
16:20:10 <adamw> i'm not sure we want to move too fast
16:20:24 <adamw> logically we should start designing test plans once the parameters are actually set
16:20:28 <jlaska> adamw: what would you envision as the next steps?
16:20:31 <wwoods> and much respect to spot for harnessing an angry mob to create something useful
16:20:44 <adamw> we can't really draw up a test plan to check a security policy until there's a security policy
16:20:51 <adamw> right now there's a blog post with bullet points
16:20:58 <adamw> there's rather a gap from one to t'other :)
16:21:01 <jlaska> adamw: yes, fair point
16:21:20 <Viking-Ice> which leaves what base sec policy for desktop and another for workstation/server ?
16:21:27 <adamw> i know everyone's all crazy enthusiastic about this right now (heh)...but there's six months to the next release
16:21:29 <jlaska> adamw: I'd like to capitalize on spot's work here ... so the end result I'm hoping we can get to is a documented repeatable series of steps anyone can pitch in on
16:21:53 <wwoods> adamw: uh, yes, but there's 8 weeks to F13 feature freeze
16:22:01 <poelcat> lol
16:22:04 * poelcat was waiting for that
16:22:07 <jlaska> :)
16:22:12 <adamw> wwoods: please put that statistic down and back away slowly ;)
16:22:15 <wwoods> hey, this dead horse ain't gonna beat itself
16:22:45 <adamw> there's several squishy areas here that worry me that we're not going to address ourselves
16:23:03 <jlaska> adamw: cool, let's call those out
16:23:05 <adamw> basically what qa's going to need to have is a set of test cases to test each item of the security policy which make up a 'security test plan'
16:23:15 <adamw> but the thing is - what exactly would we be testing?
16:23:29 <adamw> there's however-many-zillion apps in the repos
16:23:38 <adamw> and we can't be absolutely sure which of them potentially allow any of these things to happen
16:23:50 <adamw> well, we probably can, but it requires someone to do some spade work
16:23:58 <Oxf13> right
16:23:59 <jlaska> which is why I raise it here
16:24:09 <wwoods> I assume the policy would define some stuff - like a list of actions that unprivileged users must not be able to accomplish without an admin password
16:24:18 <adamw> is anyone on development side planning to do an audit to produce a comprehensive list of apps that use elevated privileges? is there going to be a policy for flagging up apps which do so in future?
16:24:19 <jlaska> first, wanted to get some scope for this issue ... so this is helping
16:24:31 <wwoods> the policy needs to outline *specific, testable* items
16:24:39 <Oxf13> basically you're going to have to learn what mechanisms are used to elevate privs, such as PolicyKit, and then monitor packages that include policy files
16:24:44 <jlaska> adamw: I wouldn't be opposed to that ... but I'm not looking for version 1.0 to be the worlds most exhaustive comprehensive plan
16:24:54 <pjones> Oxf13: learning?  but I hate learning!
16:24:56 <jlaska> I'm looking for _something_ to start with and build on for each future release
16:25:00 <Viking-Ice> is it not up to Fedora security to come up with the base security policy for desktop and workstation/server which we can then adjust create test plans for to make sure spins that fall under either category follow ?
16:25:12 <adamw> wwoods: but unless we have some mechanism to produce a reliable list of the apps that can touch items of security policy in any way, we have to test everything in the distro for each security policy provision
16:25:21 <wwoods> Viking-Ice: yeah, good point, but we can probably give guidance
16:25:24 <Oxf13> Viking-Ice: that's a nice way of passing the buck.
16:25:32 <adamw> or make a list ourselves, which doesn't seem a) like our responsibility and b) like something we'd do very well
16:25:34 <Oxf13> there's absolutely room for cooperation
16:25:39 <wwoods> adamw: ah, but we do - there are only a few ways to elevate privileges
16:25:50 <Viking-Ice> we can not blindly create test cases based on what ever we think mean that crew is the expert after all..
16:25:51 <adamw> no, i think viking is right. our job is to test the policy, not to define it.
16:25:57 <wwoods> and this is an area we can probably request help on
16:26:04 <adamw> wwoods: that's exactly what i'm saying :)
16:26:25 <jlaska> #info part#1 of this effort should involve defining a policy
16:26:39 <spot> jlaska: updated
16:26:41 <wwoods> ah, I understand - we can't do it, so we should be *requesting help* outlining that stuff
16:27:00 <adamw> so i think we need a couple of things before we can sensible do any security policy testing: a security policy, and one that has a provision for treating security-sensitive apps sensitively.
16:27:10 <jlaska> #info the QA team can support the policy by creating test documentation (plans/cases) and providing test results
16:27:19 <wwoods> (for values of "can't" equal to "can, but don't necessarily have expertise and will need help and guidance &c")
16:27:24 <adamw> then we would have a reasonable degree of confidence in what it is we're supposed to be testing, and the set of packages across which we need to test it.
16:27:51 <jlaska> adamw: seems like a sensible approach
16:28:11 <jlaska> spot: thank you
16:28:14 <adamw> (i don't know about you but i don't want to spend the rest of my life checking if supertuxkart can change the system clock :>)
16:28:28 <jlaska> at this point, I just care about critpath
16:28:41 <adamw> that doesn't make sense, though
16:28:45 <jlaska> we can embrace extend as needed ... or ensure that the process supports that
16:28:49 <adamw> _any_ app that can screw over your security model is 'critpath'
16:28:50 <Oxf13> erm.
16:29:04 <adamw> the critpath concept is only valid for application _brokenness_, not security
16:29:10 <Oxf13> if supertux doesn't include a PolicyKit policy file, a link to consolehelper, or a suid binary, we don't care about it
16:29:16 <Oxf13> we can easily narrow down the set of packages we do care about
16:29:33 <adamw> Oxf13: right. which is why i want an Official List of applications which can do privilege escalation, and some kind of policy for what we do with new ones
16:29:37 <wwoods> yeah, what Oxf13 said - it's *very* easy to detect the things needed to *attempt* elevated privilege
16:29:53 <spot> or, alternately, the testing can check a package for the prerequisites and if found, test
16:30:06 <Oxf13> adamw: that's reasonable, but I'd do s/applications/methods/
16:30:06 <jlaska> spot: yeah that's fair too
16:30:06 <poelcat> who can create an initial list of packages?
16:30:08 <wwoods> and, yeah, rpmguard should throw hell of red flags for anything with new security policy / suid binaries
16:30:21 <spot> as it is possible for a package to grow suid/consolehelper/policykit with an update
16:30:25 <Oxf13> adamw: since suid is a method, not a package.
16:30:47 <adamw> true.
16:31:05 <Oxf13> spot: right, this absolutely falls under post-build checking
16:31:05 <adamw> there's a wrinkle there, which is - how do we know what packages call an suid binary from a different package?
16:31:10 <Oxf13> and red flag throwing.
16:31:10 <kparal> in rpmguard the suid check is already. we can add policy files check
16:31:25 <jlaska> okay ... so ... next steps here?
16:31:33 <jlaska> (rather ... first steps)
16:31:38 <adamw> i'd like to know what's going on already
16:31:39 <Oxf13> adamw: that's not much of a concern, since the user could call the suid binary
16:31:44 <adamw> it seems like others may know more than me
16:31:46 <adamw> Oxf13: good point
16:31:54 <Viking-Ice> Is it not best to wait for what the security teams comes up with then adjust create/come up with and adjust test cases accordingly dont see much point in discussing the "how" until then..
16:31:59 <tibbs> Forgive the interruption, but please note that I've tried for the better part of a year to get some security review of a package with suid binaries I was reviewing.  I could never get any response.
16:32:03 <adamw> is there some kind of official effort to develop a security policy? is spot running it?
16:32:03 <Oxf13> jlaska: step 1 should be getting help to define the set of methods which priv escalation can happen
16:32:12 <jlaska> adamw: what's going on already?  can you be more specific?
16:32:15 <wwoods> tibbs: well that sucks. who've you been asking?
16:32:16 <adamw> jlaska: see above
16:32:30 <jlaska> adamw: ah gotcha ...
16:32:34 * spot is not running any sort of official effort at this time
16:32:40 <Oxf13> tibbs: yeah, full fledged security audits aren't cheap, and likely won't be done in Fedora land :/
16:32:41 <tibbs> fedora-devel and fedora-security-list.
16:33:03 <Oxf13> I think all QA can reasonably do is identify the software that requires such an audit, and catch changes.
16:33:13 <jlaska> possibly
16:33:26 <wwoods> Oxf13: a semantic nit but that seems like it'd be part of the preamble to security policy - "this policy applies to any package which can elevate privileges. These packages can be found by ..."
16:33:54 <adamw> i think the first step is simple then - determine if we're actually planning to _have_ a security policy
16:33:55 <Viking-Ice> and what security bases should QA follow when doing such an audit?
16:34:07 <jlaska> okay ... so, this is certainly something people have a lot of thoughts on, which is great
16:34:09 <adamw> perhaps encourage it by pointing out that we can't do any meaningful security testing without one
16:34:10 <Oxf13> wwoods: ok, not sure how that contradicts anything I've said
16:34:45 <wwoods> it doesn't, just trying to, uh, simplify the plan?
16:34:51 <adamw> if we assume that a security policy is actually going to emerge at some point, the second step is the policy/process for security-sensitive-packages
16:34:58 <adamw> after that, we can come up with test cases.
16:35:00 <jlaska> okay ... let's start to wrap-up this topic
16:35:02 <Oxf13> Viking-Ice: honestly I think step1 is just identify the software which can elevate privileges.  Auditing to come later by those who know how to audit.
16:35:03 <adamw> (all imo of course)
16:35:29 <adamw> i'd propose an official-from-the-qa-team mail to -devel-list summarizing this discussion
16:35:34 <Oxf13> jlaska: proposal:  Work with various teams to identify the methods in which software can elevate privileges.
16:36:03 <Oxf13> jlaska: (continued): step 2 would be to work on tests to discover these methods used by packages, in order to identify software that needs auditing.
16:36:06 <adamw> i.e. pointing out the importance of having a security policy, and the parallel necessity for a list/policy for security-sensitive packages, and go from there
16:36:22 <Oxf13> jlaska: so that when the security policy lands, we'll be ready with discoverability
16:37:46 <Viking-Ice> adamw: both the -devel and security list
16:37:56 <jlaska> is anyone in the meeting interested in representing QA to bring this discussion to -devel-list and -security-list ?
16:38:34 <adamw> i would if you like
16:38:40 <adamw> together with oxf13 representing releng i guess?
16:38:43 <Oxf13> I"m sure I'll participate
16:38:53 <Oxf13> I'm not signing up to lead anything else right now though (:
16:39:24 * adamw is not your guy for writing any actual tools to discover security-critical packages etc
16:39:25 <jlaska> now if this turns out to be a 5000 more involved than lets create a set of steps we can document and repeatably/reliably execute ... we can reconsider
16:39:35 <jlaska> adamw: I don't want any tools at this point
16:39:39 <adamw> but definitely your guy for over-long hectoring email discussions =)
16:39:52 <Oxf13> I think right now we need to focus on discovery
16:40:04 <wwoods> I'll happily help with code to detect privlege escalation in packages
16:40:06 <Oxf13> that will lead to more data about what kind of tools we need
16:40:12 <jlaska> alrighty, adamw if you'd like to start by putting some feelers out here ... that would be delicious
16:40:16 <adamw> Oxf13: i agree that's a basic pre-requisite, along with the commitment to develop some kind of sensible policy
16:40:23 <wwoods> I know kparal will want to put that in rpmguard
16:40:25 <adamw> Oxf13: if there's not going to be a policy it's kind of wasted effort
16:40:35 <wwoods> but I dunno if we're at that point yet
16:40:38 <adamw> but let's leap that hurdle when we get to it.
16:40:47 <Oxf13> adamw: yeah, policy is important, but we can get from discovery to tools for discovering sensitive packages, long before we have a policy about what to /do/ with them.
16:40:48 <jlaska> adamw: you want to tackle this week, or shall I leave it on for next week?
16:41:05 <adamw> Oxf13: sure, it's just the commitment to there _being_ a policy that i'd like to see first, not the actual policy
16:41:12 <adamw> jlaska: i can send something out this week for sure
16:41:16 * jlaska notes it may be a short week for US folks
16:41:18 <adamw> is anyone here subscribed to -security-list already?
16:41:29 <adamw> i'm not, just want to know if there's been any discussion on this already
16:41:54 <jlaska> #action adamw to initiate discussion w/ -devel-list and -security-list on creating a security policy that QA can plan around
16:41:59 <jlaska> adamw: I'm not ... will subscribe now
16:42:24 <jlaska> so ... let's at least see where this project would take us
16:42:44 <adamw> i think with a clear policy and a list of sensitive packages it'd be relatively simply
16:42:46 <adamw> simple*
16:42:56 <adamw> 'check and make sure nothing from List A does any of the stuff in List B'
16:42:57 <jlaska> requirements sure make writing tests easier!
16:43:00 <adamw> which is good. i like simple.
16:43:14 <jlaska> okay ... let's move on to the next topic
16:43:32 <jlaska> thanks for the discussion/clarification on the security approach
16:43:37 <jlaska> #topic Enhancing Release Criteria
16:43:58 <jlaska> for this topic, I don't really want to discuss the details of the proposed criteria on IRC
16:44:22 <jlaska> more just to recognize that a proposal is out there ... and perhaps some points that will be good for QA to help further define
16:44:42 <jlaska> poelcat: were there any points I missed that you'd like feedback on?
16:45:21 <jlaska> for the logs ...
16:45:35 <jlaska> #info announcement - https://www.redhat.com/archives/fedora-test-list/2009-November/msg00926.html
16:45:38 <poelcat> i think its all in the email
16:46:01 <adamw> this is going to be pretty key to future releases so poelcat would love feedback
16:46:20 <poelcat> also trying to set a better stage for more info that might come from the target audience discussion
16:47:09 <poelcat> my hope was to have discussion on the mailing list
16:47:13 <poelcat> until fudcon
16:47:30 <poelcat> and then at fudcon hammer out the dents and formalize something we can use for Fedora 13
16:47:43 <poelcat> is that realisitc?
16:48:01 <jlaska> I would think so ... but I guess it depends on the feedback that comes in
16:48:05 <adamw> sounds good to me
16:48:07 <Viking-Ice> This proposal sounds sane to me so I got nothing to suggest for improvement or add to the current :|
16:48:48 <wwoods> For the record, I'd like to say that the Release Criteria were originally created just by writing down whatever unwritten common-sense tests and policies we already had, and maybe a couple "it'd be nice if.." ones
16:49:05 <jlaska> sounds like the security policy! :)
16:49:32 <wwoods> none of it was cast in stone and I'm really happy to see that it's finally getting some proper thought behind it
16:49:36 <jlaska> wwoods: actually, I think what was there is the basis/foundation for what poelcat has created
16:49:47 <wwoods> so thanks, poelcat
16:50:10 <poelcat> wwoods: you're welcome
16:50:15 <poelcat> you gave us a good start ;)
16:50:17 <poelcat> :)
16:50:31 <jlaska> wwoods: if there are any specific criteria from the previous page that you felt "I wish I we'd change it to ...", that'd be good feedback to have
16:50:33 <poelcat> the ";)" was accidental
16:51:11 <poelcat> that's all i've got
16:51:22 <wwoods> yeah I don't have any specific suggestions - and I'm happy that the awkward MUST/SHOULD convention was dropped
16:51:25 <wwoods> heh
16:51:29 <jlaska> alright cool, so please take a moment to review poelcat's mail
16:51:33 <adamw> yeah, that confused a lot of people.
16:51:39 <jlaska> if you hate it ... feel free to reply to the list
16:51:46 <jlaska> and of course, if you like it ... please do the same :)
16:52:33 <Viking-Ice> Well if you hate it reply to the list with what you think might be better...
16:52:40 <jlaska> Viking-Ice: right on!
16:52:51 <jlaska> Okay, let's change gears to our regularly scheduled AutoQA update ...
16:52:57 <jlaska> #topic AutoQA Update
16:53:05 <jlaska> wwoods: kparal: who wants to go first?
16:53:24 <kparal> wwoods is the one with the big changes
16:53:30 <wwoods> heh
16:53:32 <kparal> go on
16:53:49 <wwoods> okay, so: I merged the autoqa git branch I'd been working on
16:54:01 <wwoods> this branch brings in the new autoqa python library
16:54:17 <wwoods> which has shared repoinfo code for the watcher scripts and utility functions/classes for tests
16:54:43 <wwoods> and the new post-koji-build hook
16:55:01 <wwoods> which is still fairly experimental, but we have it running a simple 'rpmlint' test on every new build that comes out of koji
16:55:17 <wwoods> (I'd give a link here, but we don't yet have a public autotest instance, alas)
16:55:48 <wwoods> AFAICT it's still working, though - it's run 275 tests since I turned on the cron job on.. thursday?
16:56:19 <jlaska> wwoods: they seem to be still processing, sweet
16:56:27 <wwoods> (note to anyone who reads the git logs: I keep writing 'rpmdiff' when I mean 'rpmlint', please ignore that)
16:56:45 <wwoods> so that basically closes out the goals we had for the autotest 0.3 milestone
16:56:56 <wwoods> errr, sorry: *autoqa* 0.3
16:57:04 * adamw hands wwoods a coffee
16:57:05 <jlaska> heh, too many auto's :)
16:57:05 <kparal> too many similar names :)
16:57:50 <wwoods> there's a couple things we're planning to work on at FUDCon - primarily a hackfest on a solid depcheck test
16:58:01 <wwoods> to keep us from ever having broken deps in the repos
16:58:10 <wwoods> that will require a new post-bodhi-update hook
16:58:33 <wwoods> so - yes, those things are on the roadmap, but first we're prepping stuff for FUDCon
16:58:56 <wwoods> I think primarily we want to try to solidify the post-koji-build hook,
16:59:17 <wwoods> think of some possible ways to make it easy for package maintainers to add post-build tests,
16:59:34 <wwoods> and get rpmguard up and running
16:59:54 * jlaska wonders if kparal can remotely participate in the hackfest
17:00:03 <jlaska> the TZ's might not cooperate though
17:00:09 <wwoods> I'd hope so, but.. yeah
17:00:13 <kparal> I have to look at it
17:00:20 <jlaska> perhaps a morning session
17:01:02 <kparal> how about the local testing feature, wwoods?
17:01:10 <wwoods> oh! yes!
17:01:33 <wwoods> yeah - that's required for maintainers to be able to work on post-build tests
17:01:51 <wwoods> do we have a trac ticket for that? I forget
17:02:19 <kparal> I believe we have several, and a mailing-list thread :)
17:02:44 <jlaska> I can't find the specific ticket for that right now, but it might be hiding
17:02:58 <kparal> maybe this one: https://fedorahosted.org/autoqa/ticket/52
17:03:15 <jlaska> aha ... it's not yet bound to a milestone
17:03:27 <wwoods> ah that's why I keep missing it.
17:03:30 <jlaska> kparal: but that's the one
17:03:50 <wwoods> we might think about a FUDCon milestone for stuff we need before that
17:03:52 <kparal> ok, let's attach it to the milestone then
17:04:18 <jlaska> either stuff to do before FUDCon ... or maybe things we can get help with @ FUDCon?
17:05:58 <jlaska> wwoods: lots of updates ... anything else on your radar or at risk?
17:06:42 <wwoods> jlaska: nothing springs to mind
17:07:00 <jlaska> kparal: how about with you?
17:07:22 <kparal> alright, when I was waiting for wwoods' big merge (52 commits ahead), I was trying to improve wiki documentation. So I created a new AutoQA front page, which should work as a guidepost - different kinds of user can choose interesting stuff for them and go to a link for details.
17:07:38 <kparal> The previous content was moved to "AutoQA architecture" page. there's the post: https://fedorahosted.org/pipermail/autoqa-devel/2009-November/000023.html
17:08:01 <kparal> but don't look at the front page much in detail, it's going to change soon. after my changes jlaska worked on an improved version: https://fedoraproject.org/wiki/User:Jlaska/Draft so it's possible it will replace the current version soon
17:08:45 <kparal> this week I plan to work on integration of rpmguard into autoqa, now when finally everything seems to be ready
17:09:48 <kparal> that would be it I guess
17:10:05 <jlaska> cool, I'm excited to see rpmguard in action
17:10:28 <kparal> I hope we are going to see some :)
17:11:02 <jlaska> wwoods: kparal:  thanks for the updates
17:11:09 <wwoods> we'll need to figure out what to do with the output (mail it to package owners/autoqa-results?) and what to do when there's a change that should block the package
17:11:21 <wwoods> but that can wait until after the test is working
17:11:56 <jlaska> okay ... let's move to open discussion
17:12:06 <jlaska> #topic Open discussion - <your topic here>
17:12:21 <Oxf13> FUDCON!
17:12:25 <jlaska> anything not covered in the meeting today that someone would like to discuss?
17:12:33 <Viking-Ice> Does any one know what the targeted audience is with the dvd img and is?
17:12:39 <Oxf13> I think we need to get qa/releng up on the stage and walk people through the future of Fedora development
17:12:43 <Viking-Ice> that documented somewhere?
17:13:03 <jlaska> #topic Open discussion - FUDCon
17:13:11 <Oxf13> Outlining no frozen rawhide, autoqa, autosigning, new milestones, how all these puzzle pieces are supposed to fit together
17:13:23 <Oxf13> maybe even throw in the future SCM and message bus for flavor
17:13:41 <wwoods> mmm, futureflavor
17:13:54 <jlaska> Viking-Ice: I'll jump to your topic next ...
17:13:55 <adamw> will there be jetpacks?
17:13:59 <adamw> oh, please let there be jetpacks
17:14:11 <jwb> Oxf13, is that going to be recorded at all?
17:14:22 <Oxf13> jwb: hopefully we can get this one recorded
17:14:33 <jwb> would be nice.  i'd like to review since i won't be there
17:14:36 <Oxf13> I'll take the lead on this
17:15:15 <jlaska> #info Oxf13 proposed a FUDCon discussion on the future of FEdora development process including NFR, AutoQA, autosigning, milestones and jet packs
17:15:45 <adamw> yaaaay
17:15:45 <jlaska> #topic Open discussion - dvd img target audience
17:16:21 <kparal> what exactly is the question?
17:16:35 <Viking-Ice> Who's the dvd img target audience
17:16:48 <Viking-Ice> sysadmins end users ?
17:16:50 <jlaska> according to the install guide ... http://docs.fedoraproject.org/install-guide/f12/en-US/html/ch-new-users.html#sn-which-files
17:16:59 <jlaska> "If you have plenty of time, a fast Internet connection, and wish a broader choice of software on the install media, download the full DVD version"
17:17:48 <wwoods> so where's the link to that fedora-advisory-board discussion
17:17:49 <kparal> well if I have slow internet or no internet, I would burn Fedora DVD at my friends/buy it and I would have much more programs available
17:18:14 <jlaska> wwoods: the target audience discussion?
17:18:19 <wwoods> ah: http://lwn.net/Articles/358865/
17:18:41 <kparal> they are not mentioning DVD there, just generally
17:18:49 <Oxf13> at this point, the DVD has multiple target audiences
17:18:52 <wwoods> so there's that, but yeah, that doesn't specifically talk about the DVD
17:19:02 <wwoods> yeah. the DVD is problematic.
17:19:03 <Oxf13> gnome desktop users, KDE desktop users, developers, and server admins
17:19:16 <jlaska> Viking-Ice: where were you thinking of going with this?  Or what were you wanting to hilight?
17:19:30 <adamw> i don't think we have a story for the default dvd install
17:20:10 <Oxf13> default DVD install is fairly similiar to the Desktop live image
17:20:17 <wwoods> the stories for the various spins / Live images is easier, since they're (theoretically) targeted
17:20:18 <Viking-Ice> More or less to establish if would be the recommended img for workstation/server install and the default pkg install set is targeted that way..
17:20:36 <Viking-Ice> but not to the home end user..
17:20:40 * poelcat wonders if  we could eliminate the DVD and CD  and just have the LiveCD
17:20:42 <wwoods> the default pkg install set for the DVD is roughly the same as the Desktop LiveCD
17:21:26 <poelcat> just brainstorming... no idea what the consequences would be
17:21:43 * Viking-Ice wonders if we cant eliminate optical media support altogether...
17:22:00 <wwoods> definitely can't eliminate optical media. not yet, anyway.
17:22:03 <kparal> well I know some people that are really burning linux dvds just because they want to use linux offline
17:22:31 <Oxf13> poelcat: probably not until we solve upgrade from Live images
17:22:32 <jlaska> this is an interesting discussion, but is this in the right venue?
17:22:33 <Viking-Ice> usb key's ftw.
17:22:45 <Oxf13> yeah, I really don't think this is QAs problem
17:22:54 <poelcat> Oxf13: it could reduce their problems :)
17:22:59 <jlaska> where is the appropriate place to raise concerns here?
17:23:21 <jlaska> I think this goes back to what adamw has said ... that we'd fully benefit from added clarity here
17:23:21 <Oxf13> well, Fedora Board has been beating the target audience drum, so probably there
17:23:44 <poelcat> jlaska: post to f-a-b
17:23:54 <jlaska> poelcat: Oxf13: gotcha
17:24:36 <jlaska> Viking-Ice: I guess there we have it
17:25:09 <jlaska> okay ... if no other topics, let's call it a meeting
17:25:15 <jlaska> #topic Open discussion
17:25:28 * jlaska sets the timer @ 60 seconds
17:26:34 <jlaska> okay folks ... thanks for your time
17:26:38 <jlaska> #endmeeting