16:05:27 <jaypipes> #startmeeting
16:05:28 <openstack> Meeting started Wed Oct 12 16:05:27 2011 UTC.  The chair is jaypipes. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:05:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:05:55 <jaypipes> #info if you are not in the QA team and want to be, please join https://launchpad.net/~openstack-qa-team
16:06:22 <jaypipes> #topic Status on unit test analysis and bug feedback
16:06:41 <jaypipes> nati2: care to give a status? I notice a bunch of bugs from you and your teammates :)
16:07:04 <jaypipes> patelna_: hi nayna
16:07:16 <patelna_> hey Jay
16:07:25 <jaypipes> patelna_: just started the meeting... current topic is status of unit test stuff. nati2 to provide status
16:07:46 <patelna_> great...Nachi joining
16:07:57 <nati2> Hi Jay , hold on please, I thought the meeting was on #openstack-qa  http://etherpad.openstack.org/openstack-qa.  I'm redirecting guys who joined to #openstack-qa
16:07:58 <patelna_> we're in the #openstack-QA channel
16:08:12 <jaypipes> patelna_: ah, no, this channel :)
16:08:21 <jaypipes> patelna_: this channel has the meetingbot and stuff...
16:08:34 <patelna_> Got it!!!! thanks
16:08:36 <nati2> yes, let's use this channel
16:08:51 <gigig> Hello Nayna and Jay
16:09:02 <jaypipes> gigig: morning/afternoon :)
16:09:08 <nati2> Hi gigi!
16:09:09 <patelna_> Hey Gigigi
16:09:10 <gigig> hi nachi :)
16:09:10 <jaypipes> ALL: we just started the meeting... current topic is status of unit test stuff. nati2 to provide status
16:09:31 <nati2> OK
16:09:53 <nati2> Nayna are you joining here?
16:10:04 <jaypipes> nati2: patelna_ is nayna
16:10:04 <KumarKR> hello folks
16:10:07 <patelna_> I am
16:10:07 <mtaylor> hey gigig. hey patelna_
16:10:17 <patelna_> Hey Monty
16:10:21 <nati2> hey monty
16:10:22 <gigig> hey monty
16:10:27 <mtaylor> hey nati2
16:10:30 <patelna_> Nachi = Patelna = nayna
16:10:36 <nati2> gotcha!
16:10:42 <patelna_> let's go...
16:10:55 <patelna_> please provide an update on Unit Test Coverage
16:11:06 <nati2> OK My team start analyzing code and adding unit test on it
16:11:19 <nati2> you can see coverage at https://jenkins.openstack.org/
16:11:32 <nati2> But our stuff is not merged yet.
16:12:08 <nati2> And also we added some blueprints and bugs
16:12:10 <nati2> https://blueprints.launchpad.net/openstack-qa/+spec/nova-exception-policy
16:12:44 <nati2> This buleprint is for exception and log handling
16:13:09 <nati2> Based on this policy, We added some bugs Related bugs
16:13:15 <nati2> sorry typo
16:13:17 <jaypipes> nati2: where are the branches that are proposed to nova for the QA bug fixes and test cases? I don't see any here: https://review.openstack.org/#q,status:open+project:openstack/nova,n,z
16:13:36 <venkater_> hey nati2 - I see results for Nova .. Is swift unit tests also run?
16:13:36 <nati2> I think it is not created yet.
16:14:15 <nati2> venkater_:  > Monty  Do you know about swift unit tests status?
16:14:52 <nati2> See related bugs on https://blueprints.launchpad.net/openstack-qa/+spec/nova-exception-policy.
16:14:56 <mtaylor> swift unit tests are run as part of gating the swift trunk
16:15:29 <nati2> We also add input value validation blueprints. https://blueprints.launchpad.net/openstack-qa/+spec/nova-input-value-validation-policy
16:15:39 <mtaylor> and coverage job for swift is: https://jenkins.openstack.org/view/Swift/job/swift-coverage/
16:15:46 <nati2> And manager api policy https://blueprints.launchpad.net/openstack-qa/+spec/nova-manager-api-policy
16:15:57 <nati2> thanks mtaylor
16:16:29 <nati2> There are more 10 bugs reported in my lab (but it is Japanese now, I'll translate it today :) )
16:16:46 <gigig> haha
16:16:52 <nati2> Would you please comment and question about blueprints and bugs ?
16:17:01 <jaypipes> nati2: ok, good. yes, I'd like to see those blueprints containing more details...
16:17:01 <nati2> It it all from me.
16:17:23 <nati2> gotcha. I'll add examples and more details
16:17:30 <dwalleck> Hi, Daryl from Rack QE. The blueprint for API input validation sounds more like addition of input validation, not the testing of it. Is that correct?
16:17:44 <jaypipes> nati2: well, not the exception blueprint :) that one is great!
16:17:55 <nati2> gotcha : jaypipes
16:18:07 <jaypipes> nati2: see dwalleck's ? above
16:18:12 <nati2> dwalleck: I think it is in scope of QA
16:18:31 <dwalleck> nati2: In scope for us to add it? Or test it?
16:18:41 <nati2> Because the code must support irregular case.
16:18:49 <nati2> I suppose the scope of QA is not only test
16:18:54 <dwalleck> Testing it certainly. I didn't know it would be our blueprints to actually add the validation
16:19:18 <nati2> We should specify unclear specs also.
16:19:21 <patelna> QA scope is to consolidate and add tests as well
16:19:30 <gigig> agreed
16:19:31 <wwkeyboard> I would think the quality assurance team would tackle anything that helps assure the quality of the project
16:19:45 <nati2> wwkeyboard: ++
16:19:54 <wwkeyboard> input validation and exception handling would be part of that.
16:19:55 <dwalleck> Okay, just making sure
16:20:05 <wwkeyboard> As well as code quality and database design.
16:20:12 <patelna> for Diablo-4 QA is catching up with the coverage
16:20:31 <nati2> Yes I agreee
16:20:49 <nati2> Statement coverage is one of mesurement
16:21:05 <nati2> Most important thing is to solve unclear specs
16:21:13 <gigig> how are we measuring test coverage or rather tracking it
16:21:16 <patelna> agree
16:21:24 <nati2> and specs are based on coding policies
16:21:28 <wwkeyboard> nati2: I agree, thats why I fear coverage as a metric.
16:21:41 <dwalleck> Right, I just didn't understand that it was the responsibility of the group was not just to test validation, but add to it and improve code quality
16:21:43 <nati2> wwkeyboard: agreed
16:22:10 <nati2> dwalleck: gotcha! thanks for your point. It make clear of the mission of this team :)
16:22:26 <mtaylor> gigig: https://jenkins.openstack.org/view/Nova/job/nova-coverage/?
16:22:28 <mtaylor> #link https://jenkins.openstack.org/view/Nova/job/nova-coverage/?
16:22:42 <jaypipes> I would agree with above... checking the consistency of the spec vs. the actual behaviour is certainly in QA's purview
16:22:43 <gigig> mtaylor: thanks :)
16:22:45 <mtaylor> #info coverage is tracked per-build in jenkins
16:22:47 <wwkeyboard> When filing these bugs are you making sure to inspect the supporting tests as well? The missing coverage may signal other insufficient tests.
16:23:07 <mtaylor> ooh! why is the nova coverage job failing...
16:23:24 <nati2> There are some coding policies (pep8 etc), however I think coding policies should support irregular cases such as exceptions or irregular input value.
16:23:32 <nati2> mtaylor: tanks
16:23:57 <nati2> wwkeyboard: Yes absolutly. Coverage is also important.
16:24:14 <wwkeyboard> nati2: good, thank you
16:24:28 <nati2> see we already added for that. https://blueprints.launchpad.net/openstack-qa/+spec/nova-unit-compute
16:24:36 <nati2> Low coverage is one of kind of bugs
16:24:45 <KumarKR> Agree, we need to verify a) are we building the right product and b) is the product built right? Wondering, if  we have product owners to particpate in checking consistency of specs.
16:24:59 <nati2> KumarKR++
16:25:15 <KumarKR> :-)
16:25:28 <nati2> At first, I think we should share what's our thought
16:25:45 <nati2> So would you please share your teams plan as a blueprints and bugs
16:25:59 <nati2> Blueprint is spec such as exception policies
16:26:06 <nati2> BugReport is instance of it.
16:26:39 <jaypipes> KumarKR: well, first things first, we need to identify places where the spec doesn't even exist ;)
16:26:52 <gigig> jaypipes: applause
16:26:57 <nati2> jaypipes++
16:27:04 <KumarKR> agree. i need to dive into this sooner :-)
16:27:05 <patelna> totally agree...we need dev to help us as well
16:27:29 <patelna> we should start with API coverage first
16:27:30 <jaypipes> a good example of that is the Glance "spec" for the 1.0 API. It, well, leaves a lot to be desired...
16:27:46 <wwkeyboard> What are we considering the 'spec'? The api spec?
16:27:53 <wwkeyboard> Or the unit tests?
16:28:04 <jaypipes> wwkeyboard: yes. anything here: http://docs.openstack.org/api/
16:28:35 <gigig> jaypipes: can we talk about the api framework we will consolidate to since we have 7?
16:28:49 <nati2> gigig:  7 ?
16:29:00 <jaypipes> wwkeyboard: so, there are "approved" specs, like the 1.1 Compute API spec, "in progress" specs (like the Glance v1 API), and "proposed" specs, like the 2.0 Images API spec being developed.
16:29:02 <gigig> jaypipes: there are a few out there nachi :)
16:29:22 <westmaas> nati2: think she's talking about the tests in openstack-integration-tests
16:29:24 <wwkeyboard> jaypipes: OK, do we want to try and include executable examples within those specs?
16:29:28 <jaypipes> gigig: you're talking about the 7 *test* frameworks :)
16:29:31 <nati2> westmaas: gotcha
16:29:35 <patelna> I think there are 2 separate tasks we need to start with (a) API full coverage/add Test Cases for gaps (b) Agree on API framework
16:29:40 <gigig> jaypipes: Yes
16:29:46 <gigig> westmaas: ty gabe
16:29:47 <nati2> patelna: agreed
16:29:49 <jaypipes> gigig: yep, we'll get to that in a sec
16:29:58 <gigig> jaypipes: cool
16:30:05 <jaypipes> first things first though, I'd like to get some resolution on the following:
16:30:42 <venkater_> idea: we can have blueprint review session . Either by email notification or phone call
16:30:43 <jaypipes> If nati2's team is doing these traceability matrices, is nati2's team also responsible for submitting bug reports from those and developing new tests cases or improving poor-=quality test cases?
16:30:45 <nati2> Oh, I wanna make sure this. My team's primary focus is Diablo maintenance (backport). How about yours?
16:31:10 <jaypipes> nati2: and Nova-only for your team... we should be specific.
16:31:22 <nati2> jaypipes: Thanks yes
16:31:47 <jaypipes> alright, then I propose the following:
16:32:10 <jaypipes> #vote nati2 and team continue to do the unit test analysis, submitting of bug reports and additional unit tests.
16:32:15 <nati2> jaypipes: Yes our team is responsible to add unit test (Sorry It may not all of modules)
16:32:27 <jaypipes> #vote nati2 and team continue to do the unit test analysis, submitting of bug reports and additional unit tests for NOVA
16:32:37 <jaypipes> type #agreed if that is good with you.
16:32:44 <gigig> #agreed
16:32:46 <westmaas> #agreed
16:32:46 <nati2> #agreed
16:32:47 <dwalleck> #agreed
16:32:54 <wwkeyboard> #agreed
16:32:56 <patelna> We should help Nachi
16:33:14 <patelna> he is the owner...but this is a big task
16:33:15 <venkater_> Yes.
16:33:16 <jaypipes> patelna: ok. can I count on you to arrange resources from HP where nati2 needs assistance?
16:33:24 <patelna> Yes
16:33:28 <nati2> Thanks. We may not support all modules (such as LDAP or something)
16:33:35 <jaypipes> patelna: or perhaps around Glance and Keystone, since nati2's team is focued on Nova?
16:33:47 <jaypipes> more help the better IMHO
16:33:52 <nati2> It sounds great
16:34:10 <gigig> jaypipes: we can help here too
16:34:11 <patelna> Ravi - can you take Glance
16:34:20 <nati2> Or Middium or large tests
16:34:20 <patelna> Keystone - we can ask Kim to lead this
16:34:25 <venkater_> Yes . Nayna
16:34:28 <jaypipes> k...
16:34:49 <jaypipes> #action patelna to find resources to help small/unit test analysis and coverage for Keystone and Glance
16:35:10 <jaypipes> #action jaypipes to assist patelna in getting resources familiar with Gerrit/Git reviewing and Launchpad
16:35:14 <jaypipes> ok. now, I think we can move on to discuss integration tests. OK with everyone?
16:35:31 <nati2> Cool Jay+
16:35:32 <patelna> #agree
16:35:36 <nati2> #agreed
16:35:39 <jaypipes> OK
16:35:42 <gigig> patelna: let me know if you need help on the last item
16:35:48 <gigig> and yes lets move on
16:35:52 <patelna> Yes ...will do
16:35:53 <jaypipes> #topic Action items around unified integration test suite
16:35:59 <KumarKR> #agree
16:36:28 <westmaas> wwkeyboard and I would like to propose a unified way to run the tests in openstack-integration-tests, I think we can get a bp in by tomorrow if that is acceptable.
16:36:31 <jaypipes> So, right now, the only test suite currently included in https://github.com/openstack/openstack-integration-tests is Kong
16:36:32 <nati2> Rohit is starting about analize 7 test frameworks. (Sorry he can not come here today)
16:36:45 <jaypipes> westmaas: yep, getting to that... one sec.
16:36:55 * westmaas shushes
16:37:02 <gigig> haha
16:37:10 <nati2> It sounds great to have a blueprint for that
16:37:14 <jaypipes> westmaas and I have been compiling info on the various suites: http://wiki.openstack.org/openstack-integration-test-suites
16:37:31 <nati2> westmaas++ jaypipes++
16:37:40 <jaypipes> clearly we have a lot of work ahead of us in bringing the "good stuff" from the non-Kong test suites into the main project
16:37:49 <dwalleck> Is there a plan to come up with a universal design and architecture for testing? Or just to merge the tests together so they can run?
16:38:11 <venkater_> Is there a notification if new blueprint is added to the docs/wiki?
16:38:18 <wwkeyboard> dwalleck: We hope to come up with one.
16:38:21 <patelna> we need to decide on one framework
16:38:25 <jaypipes> westmaas: I'd like to propose that we have 1 person take the lead on developing the "unified test runner" and 1+ people taking the lead for each non-Kong test suite to bring it into the main project
16:38:29 <mtaylor> dwalleck: I would like universal design/architecture
16:38:31 <nati2> I think test scenario is also important
16:38:32 <westmaas> dwalleck: a plan for a plan :) think we need a tiny bit more analysis first.
16:38:34 <gigig> patelna: ++
16:38:43 <westmaas> jaypipes: sounds good.
16:38:45 <jaypipes> venkater_: no, and that is really annoyinhgk I know.
16:38:49 <dwalleck> But before we start going forward with testing? It seems like coming with up with a design before going forward with development would be best
16:38:49 <wwkeyboard> jaypipes: sounds good
16:39:05 <wwkeyboard> I would add to that that we have someone in charge of looking for duplication & missing tests.
16:39:16 <jaypipes> OK, now, is there anyone that would like to volunteer to be the LEAD for the unified test *runner*?
16:39:24 <mtaylor> jaypipes: as long as when we say "test runner" we don't mean "re-write nose"
16:39:30 <dwalleck> I just want to make sure whatever we built is maintainable and scalable
16:39:38 <westmaas> I'm happy to lead that, if someone else wants it, no worries.
16:39:48 <dwalleck> Is there a reason we can't just use nose?
16:39:48 <jaypipes> mtaylor: no, we mean "take the best pieces of the existing things and make it a single way to run tests"
16:39:51 <dwalleck> I would be also
16:39:57 <mtaylor> jaypipes: just being clear
16:40:02 <nati2> westmaas++    Rohit will help you :)
16:40:07 <jaypipes> dwalleck: the big one is it is not multi-threaded/processed
16:40:16 <wwkeyboard> +1 for westmaas
16:40:18 <jaypipes> dwalleck: whereas DTest is.
16:40:27 <patelna> +1 for westmass
16:40:33 <dwalleck> jaypipes: Actually there is a multithreaded plugin for nose
16:41:09 <jaypipes> dwalleck: hmm, great to know. :) Perhaps you can work with westmaas to come up with the best runner?
16:41:28 <westmaas> dwalleck: I will work closely with you
16:41:31 <dwalleck> Sure, sounds good
16:41:42 <jaypipes> westmaas: seems like you are the lead for the test runner piece.
16:41:57 <westmaas> alright
16:42:12 <jaypipes> #action westmaas will lead the effort to create a singular best-practice test runner
16:42:53 <nati2> cool
16:43:01 <gigig> shall we put a timeline on this since we need to get consolidated sooner than later?
16:43:07 <patelna> awesome!!!!
16:43:08 <jaypipes> Alright, now I believe that one of the first things we need to do (other than start work on the test runner) is to actually GET the other test suites into the openstack-integrated-tests project...
16:43:13 <westmaas> will ping the list with a bp that specifies requirements to look for input on those requirements within a day.
16:43:24 <gigig> westmaas: great
16:43:26 <jaypipes> I can volunteer to do that drudge work...
16:43:40 <patelna> I add ask Donald Ngo from my team to be included in this group as well
16:43:48 <wwkeyboard> jaypipes: the importing of the other tests?
16:43:56 <jaypipes> drudge work == copy-pasting the code from Backfire/Stacktester/Zodiac/Novasmoketests/etc into the openstack-integrated-tests project
16:43:59 <jaypipes> wwkeyboard: yep
16:44:06 <gigig> jaypipes: applause
16:44:13 <wwkeyboard> if you do that I'll start looking for duplicates & missing tests
16:44:18 <jaypipes> HOWEVER... doing so will be pointless if work continues in those other projects...
16:44:18 <dwalleck> But all these tests are so different in design. How is that going to work?
16:44:37 <wwkeyboard> westmaas suggested we really need to talk about directory structure as well.
16:44:41 <jaypipes> dwalleck: some are different, but MANY are virtually identical :)
16:44:53 <wwkeyboard> And I think we need to decide on a client(s) to access OS with
16:45:05 <westmaas> wwkeyboard: I think rohit is also analyzing and looking for dupes
16:45:16 <patelna> the dir structure should follow the same code path/release/versioning
16:45:16 <dwalleck> Well, it's more than directory structure. Some use novaclient, some directly call httplib, some have intermediate interfaces
16:45:22 <wwkeyboard> westmaas: I will ping him
16:45:32 <jaypipes> wwkeyboard: the directory structure I proposed at the summit unconference was a directory named for each of the original test suites, so we can just bring them all into the project, then start the process of merging them into a /tests directory and a /runner directory,
16:45:33 <dwalleck> We really need to think about sustainability when doing this
16:45:33 <nati2> wwkeyboard: yes rohit will help
16:45:48 <jaypipes> patelna: could you elaborate on that suggestion?
16:46:13 <nati2> dwalleck: sustainability?
16:46:24 <jaypipes> dwalleck: we agreed at the summit that there is value in running BOTH httlib2 AND novaclient-based client tests
16:46:26 <patelna> so for diablo unit tests it should be checked in the same branch
16:46:34 <dwalleck> If we have several different architectures within the same suite, is will be painful to maintain
16:46:34 <jaypipes> patelna: ah, I see now
16:46:57 <gigig> agree with Patelna
16:47:02 <nati2> dwalleck: I got it
16:47:03 <dwalleck> But novaclient tests should really be a different suite or at least sub-part, but seperate from other tests
16:47:04 <patelna> for essex we should have a place holder for test dir structure...
16:47:14 <wwkeyboard> dwalleck: what do you mean by architectures?
16:47:22 <westmaas> dwalleck: agreed.  at the conference we agreed there is value to each approach we just need a sane way to approach them and organize them.
16:47:29 <westmaas> dwalleck: I'm slow, what you just said.
16:47:30 <dwalleck> If we continue just calling httplib2 directly from tests, that won't scale like we need it to
16:48:09 <gigig> all i have to step away for a phone screen  -  *waves*
16:48:27 <dwalleck> wwkeyboard: As in a design for the framework. For example, I made an intermediate layer between requests and the tests so that if the structure of requests changes, there's easy places to fix issues like that
16:48:27 <wwkeyboard> My fear with using a single client like novaclient is that a bug in the spec that is written into the API can be duplicated in the client.
16:48:36 <patelna> yes...even architecture framework + tests needs to be check'd into Git rightly
16:48:51 <wwkeyboard> dwalleck: thats what I was calling the client, I agree with you
16:49:04 <jaypipes> Hey all, what do you all think of this? http://paste.openstack.org/show/2689/
16:49:39 <jaypipes> where the top directory structure is what we do initially, just to get stuff in there, and the bottom directory structure is the endgoal...
16:49:42 <nati2> Ah,,  looks good to me.  Test must support multiple clients
16:49:53 <wwkeyboard> I would rather the version be at the top level, it would make it easier to remove when we depreciate something.
16:49:54 <nati2> So there are client directory
16:50:18 <jaypipes> wwkeyboard: sure, that makes sense too.
16:50:19 <patelna> that is a gd idea
16:50:42 <nati2> yes it is good idea
16:50:49 <jaypipes> patelna: version at top level instead of under component?
16:50:54 <jaypipes> westmaas: thoughts?
16:50:58 <jaypipes> dwalleck: thoughts?
16:51:04 <patelna> yes...at top level
16:51:05 <venkater_> it looks good . client -> type of client. How about version? when we support multiple version?
16:51:12 <wwkeyboard> Then when we move versions all we have to do is 'cp' the old version'
16:51:21 <wwkeyboard> and a diff will tell you about what has changed.
16:51:26 <patelna> yes...
16:51:36 <westmaas> jaypipes: lets start there, and then see where we go.
16:51:37 <wwkeyboard> But that might be to primitive, idk
16:51:50 <nati2> :wwkeyboard it sounds cool
16:51:53 <dwalleck> Well, my only concern is that I still see it broken down by original test project. Would it make more sense to break it down by something like novaclient tests and non-novaclient tests?
16:52:03 <westmaas> dwalleck: that's the before
16:52:21 <jaypipes> venkater_: diffferenltly versioned clients could just be different python modules under /client/httplib2/ ...
16:52:26 <dwalleck> Ahh, I see now. Nevermind! :-)
16:52:28 <westmaas> we will get rid of those as they get merged in
16:52:29 <jaypipes> dwalleck: :)
16:52:39 <jaypipes> well, as was mentioned, we can always change it later...
16:52:46 <jaypipes> alrighty, then..
16:53:14 <jaypipes> #action jaypipes to grab all other test suites code and put into openstack-integrated-tests project, each in its own subdirectory.
16:53:27 <nati2> jaypipes++
16:53:43 <patelna> jaypipes ++
16:54:06 <jaypipes> OK, those were the two big status things I wanted to chat about and get agreement on. Does anyone have any feedback from the summit or issues you'd like to discuss?
16:54:07 <westmaas> jaypipes: stacktester is already merged in with kong in the repo, just fyi
16:54:16 <jaypipes> westmaas: ah, good to know. thx!
16:54:24 <jaypipes> #topic Open Discussion
16:54:29 <nati2> I wanna discuss about diablo branches
16:54:34 <patelna> me 2
16:54:40 <nati2> Which branch I should request merge?
16:54:52 <jaypipes> nati2: we need to create them first :)
16:55:01 <nati2> And also I know about status of fixes team
16:55:02 <jaypipes> nati2: I'll send an email to the PTLs about it.
16:55:08 <KenWhite-RAX> Sorry, I'm a little slow here, but basically all the different frameworks ( kong, backfire, etc) get checked in to one location then merged. THEN duplicate tests are removed and then we check code coverage?
16:55:35 <wwkeyboard> KenWhite-RAX: The duplicates should be removed as they are merged.
16:55:42 <jaypipes> KenWhite-RAX: code coverage is more unit tests... these are functional integration tests...
16:55:42 <patelna> Daviey -- what is his role for the maintenace branch?
16:55:51 <nati2> jaypipes: Cool. However I suppose it is responsibility of fixes team.
16:56:04 <jaypipes> nati2: well, that is true enough.
16:56:15 <jaypipes> nati2: do we have that fixes team even created on Launchpad yet?
16:56:19 <KenWhite-RAX> Right right sorry, mixing my apples and oranges
16:56:39 <nati2> Muu I think fixes and qa team must be merged
16:56:39 <dwalleck> Yeah, I was curious about that. So why do we call it an integration suite instead of a functional suite? Just me being picky :)
16:56:49 <nati2> mtaylor: How do you think about this?
16:57:02 <jaypipes> nati2: no, I thought a decision was made that QA and fixes team are separate
16:57:11 <nati2> jaypipes: gotcha
16:57:27 <nati2> jaypipes: Then fixes team should have their launchpad
16:57:44 <jaypipes> dwalleck: because it tests functional components of more components than just Nova... tests the integration of Keystone, Glance, Nova, etc
16:57:54 <mtaylor> yes. jeblair is working on the fixes team right now
16:57:55 <jaypipes> dwalleck: but the distinction is a grey area to be sure :)
16:58:17 <venkater_> Is Daviey in fixes team and maintains brach Diablo?
16:58:31 <nati2> mtaylor: cool! Fixes have meetings?
16:58:47 <jaypipes> mtaylor: I believe it was decided that the fixes team would be just a few people... basically some interested parties from the distros, the PTLs who vote on which bug fixes/backports to apply, and a couple others?
16:58:47 <mtaylor> nati2: not yet
16:59:30 <mtaylor> jaypipes: yes. I actually think we were going to add Daviey, markmc and zul and let them take adding more people from there
16:59:34 <patelna> who will review the code for the fixes team ...so we don't have regressions?
17:00:06 <jaypipes> patelna: good question...
17:00:13 <jaypipes> patelna: it may depend on the project.
17:00:27 <jaypipes> patelna: for Glance, I think a few interested glance-core contribs will do reviews at least.
17:00:35 <patelna> we should formalize this...maybe the previous PL?
17:00:37 <zul> markmc already started a write up
17:00:53 <patelna> thanks ...Zul
17:01:00 <jaypipes> patelna: well, i think it would be up to the project ;)
17:01:08 <mtaylor> actually, no
17:01:23 <nati2> Hi did you read mail about  [Openstack] [RFC] Stable branch? It sounds several guys do the same thing at different place.
17:01:29 <mtaylor> what we talked about at ODS is that these teams would not really be as associated with the projects, as the projects are focused on forward dev
17:01:38 <patelna> we should involve the core developer
17:02:07 <mtaylor> markmc just sent a proposed policy ... but the thought was that this was a place for distros and integrators to collect their work and collaborate
17:02:41 <mtaylor> one of the reasons for the formation of the team was exactly that the core devs/ptls did _not_ want to maintain old releases moving forward, whereas the distros and integrators do
17:02:43 <westmaas> mtaylor: who has core status on openstack-integration-tests?
17:02:47 <nati2> mtaylor:  Aha This is from your team. I got it.
17:02:59 <westmaas> sorry if this is what is being discussed having a hard time following
17:03:24 <mtaylor> westmaas: it's not - we moved on to stable branch update process it seems
17:03:38 <mtaylor> westmaas: I'm not sure about who is core on openstack-integration-tests - lemme check
17:04:38 <mtaylor> jeblair: ^^
17:05:07 <mtaylor> jeblair: "<westmaas> mtaylor: who has core status on openstack-integration-tests?"
17:07:37 <jaypipes> OK, well perhaps we'll shelf that... :)
17:07:44 <westmaas> haha
17:07:47 <westmaas> apparently
17:07:58 <jaypipes> #action jeblair to email ML about membership for integration tests
17:08:08 <jeblair> hi
17:08:10 <jaypipes> alrighty, anything else ayone wants to bring up?
17:08:21 <jeblair> any chance we colud get this meeting listed on the openstack meetings ics calendar? :)
17:08:43 <jaypipes> #action jaypipes to get this meeting listed on the openstack meetings ics calendar? :)
17:08:47 <patelna> that is a gd ask
17:09:00 <nati2> It is useful
17:09:52 <jaypipes> OK, I'll adjourn the meeting for this week, then. See you all on the mailing list and next week on IRC ;)
17:09:54 <jaypipes> #endmeeting