|
|
| Line 90: |
Line 90: |
| == Raw Notes == | | == Raw Notes == |
| <pre> | | <pre> |
| - capture the notes and send them out to waverly and sumo
| | Crowdbot dropped : |
| 3 major bullet points
| | new zippity working; pulling together the new zippity |
| tony : good to be back | | Not sure where tony is on the other items. |
| wait til 2nd half of the meeting to talk about mobile
| | jbonacci finished his dashboard; link in the past action items section. |
| fennec native meeting at the end. James and tracy get back to other stuff if they want
| |
|
| |
|
| Services talk :
| | BHAG: |
| - John is starting next week; senior server side engineer to help james and tracy for test infrastructure
| | tracy : |
| - runner between ops and us
| | mozmill and tps, we can nearly automate all test cases. |
| | need another person or way more time to get this done. |
| | mobile : |
| | automation solutions |
| | engagement / Community |
| | browser id : |
| | automation solutions |
| | engagement / Community |
| | pancake : |
| | automation solutions |
| | engagement / Community |
|
| |
|
| - the sync team is being allocated for native ui fennec | | Need to get audience for Services side |
| - there are a couple of wikis that they are going to figure out how to get sync support | | - who the community is |
| - how to incorporate mobile and sync testing | | - how to reach out to them |
| - traditionally it's been driven by mobile to do it.
| | - it's a little different from client |
| - with native fennec, we should
| |
| - sync is part of the first release
| |
| - sync team is working on the backend for sync, but not the ui.
| |
| - sync qa team knows sync but not mobile, and mobile qa team knows mobile, and some sync.
| |
| - something for tracy and james to think about in terms of backend infrastructure
| |
| - test matrix to including mobile, there are the plans for that currently, but because of the java the sync has to be redone because of the storage system is different
| |
| - cross team expertise is needed
| |
| - up to fennec 10 XUL is also being supported
| |
| - what's the best way to approach this?
| |
|
| |
|
| - sounds like it needs to be in fennec 10 UI test plan for sync; major feature of the client
| | Services need more technical community that's interested in bouncing ideas in hacking and testing which may be tricky |
| - the back end is changing per se.
| | Come up with some ideas for single or small groups through various sites that specialize in server side testing |
| - plan to be major integration within fennec (from mike conner)
| | Trying to reach a community, not sure of |
| - concern with too much power to google in terms of information giving that
| | trying to think of what's already running in terms of conferences or community with server ops maybe? |
| - leaning towards leaning unified accounts
| | hacking community : hacking for security privacy issues. |
| - what if we introduce sync
| |
| - do we need gmail account?
| |
| - more design questions
| |
| - fennec feature with sync developers working it
| |
| - someone needs to drive it around ui fennec side w/ support from sync team (collaboration)
| |
| - understand dependencies and architecture
| |
| - ux people work with fennec
| |
| - shouldn't matter who the contact person is
| |
| - just need to figure out the distribution of people
| |
| - back end is still traditional
| |
| - related project is the open web app
| |
| - native fennec is going to support html shim
| |
| - need to look at scope of native 1.0
| |
| https://wiki.mozilla.org/Mobile/NativeFennec1.0
| |
| - proposal :
| |
| - XUL up to 10 : QA mobile team supports sync; tracy does verification with sync on mobile and desktop
| |
| - Native : tracy work with kevin w/ new features ; feature test plan : the spec was sent out today
| |
|
| |
|
| - browser ID support plan : | | Again trying to find the people would be hard |
| - talk to dan mills
| | |
| - plans to release ; don't have good grasp on scaling plan, staging, automation, etc.
| | For Browser Tech, not sure. |
| - haven't looked at plumbing plan. James and Ioana have been working on client side bugs
| | - hard to accomplish each of these goals due to youth of projects (for mobile, sync/browser id, pancake) |
| - deployment plan : the other pieces like unit test framework, Jeff's team talked to ops
| | - one of the goals for next quarter is to get pancake out |
| - they are patterning after the sync server
| | |
| - dev, staging and production enviroment. Very similar to sync
| | Anything for process? |
| - the amount of client activity is going to slow down. Most of the work is done on the server side
| | - chance to reset |
| - client is dummy web for the most part
| | - figure out the processes : risk areas, etc. |
| - testing will be more server side; log checking.
| | - rotational program for each person for a round robin [ that way we don't get tester fatigue; coverage ] |
| - less client /ui testing
| | - newsletter for each group |
| - haven't seen the certification handling.
| | |
| - could be split into multiple services
| | - newsletter : cross training, bi weekly. based on btech meeting? should we have it through out. |
| - change in production?
| | - try to take as little time as possible to spend on the newsletter |
| - should be able to similate everything (load etc) on staging
| | |
| - load test needs to be more related to browser id
| | - do we need a SLA? Need to formulate structure for SLA : response to testing ? |
| - don't know if it's created yet; tickets open for those tools; might not be the same thing
| | - Some kind of more formalized process with the dev |
| - need to run functional test while doing load testing
| | |
| - make sure on our side, we don't have those final issues like we did with sync
| | Mobile : |
| - lloyd having to separate things to have separate RPMs (still working on details)
| | - Robocop would help out with. |
| - splitting putting in different directories and then repackaging showed some issues
| | - exploratory in the beginning, manual verifications of nonautomated tests, remaining 10 % |
| - working with pete and monitoring the issues
| | - Crowdtest : martijn Crowdbot ported to native UI? Need agreement from Martijn |
| - any site that uses it, can point to it. what we need is more sites.
| | - Zippity ported already |
| - need more real world sites using browserid
| | - Something around Devices? |
| - before we sign off on this.
| | - Performance : automation, compare against other browser. |
| - is it pointing to our beta. do we test those sites while generate load
| | - getting community with devices that we don't have ; community device owner |
| - we need both. more sites ; more testing that doesn't relying on party and do testing on the server side
| | - getting devices to contributors; people that have devices that we don't have. |
| - everything else you type up lives on the server
| | - Resources : move 90 % automation? -> verify the automations, migrate tests litmus to automation, write litmus to automation, maintainence, increase in waverly help |
| - API testing, we don't have that yet.
| | - if we have some slack we can shift people to identify testing, browser id, etc. |
| - John needs to work on API testing
| | |
| - talked to lyod ... need more sites ; QA verying
| | Services: |
| - would rather have real sites.
| | - QA is running a fully integrated Test system, consisted of VM's and physical hardware |
| - "can you point to stage?"
| | - sync server environments, mix of VMs and physical hardware that's already happening |
| - externally there are some websites that use it. such as Open Photo
| | - could be a scaling thing, in terms of how to cover this? |
| - yesterday or day before developer engagement : need to find 600 users
| | - automation picture is bigger? |
| - went do dev identity.
| | - cut thing? need tony to check out |
| - developer presentation outreach
| | - rest of these seems like processes, which most of them we already starting to do. |
| - we can get them involved.
| | - he wants us to be doing; we have various test environments: |
| - silly dumb sites still need to exist (myfavoritebeer.org)
| | - requesting QA have their own environment for testing |
| - sync.in has more details
| | - borrowed stuff from Ops team |
| - wiki site that has stuff listed
| | - 2012 : make our own sync environment : browser ID environment rather than staging environment |
| - "does the environment work?" will be the first initial testing; make sure that it's stable first.
| | - No server side automation. |
| - overlay is open web apps. need to make sure that the environment works. Make sure the train is there. and stable. | | - nightly unit testing; that's only nightly? per train? not sure if it's nightly testing? |
| - need a highlevel checklist. | | - will soon. on the sync server side it is happening Tarak has it set up |
| - happy to make a wiki for that. | | - Browser ID ones are javascript |
| - some enumerated set of headings with "this has to work" and status | | - sync server side it's python |
| - ex. load testing ; subtest under that | | - sync is not moving to pyramid |
| action item: - jbonacci : dashboard would be good idea. Spreadsheet is fine as well; relevant bugs, status, checklist items.
| | - sync is all javascript? TPS stuff; some kind of nightly test that's being done... disregard. it's client side. |
| - QA side meeting for the details; taking offline for QA centric
| | |
| - ping st3fan/nhirata for the staging pancake
| | BHAG: |
| - services : reminder next week. | | - context: for the next year |
| - anything blocking bring it up. desktop/mobile : go/no go later today (2:00)
| | => 2 big goals : automation, and community |
| | Since browser ID has started, most of the stuff has been running on VM. They are creating full facing environments for release |
| | for staging, production, dev. Work in progress. All 4 environments will be up and running by end of Nov. (est) |
| | => end of Q4 go live |
| | |
| | |
| | How do we track the community |
| | => we have one active community member for mobile team |
| | => sync no progress as of yet. |
| | actionitem: => sync newsletter to be discussed between james/oki |
| | |
| | Status : read wiki |
| | | |
| Check with community team goals. yesterday's meeting: we could be doing a better job.
| | Round Table : fennec table to make sure that sync and fennec stay in sync. |
| - community is a tough thing. time , resources, ... asking a lot
| | Are they bundling as two separate applications? |
| - james brought up a good point. We are at the max
| | Not sure how it's going to go. |
| - even so, just ignoring it or letting it slide... can't do that
| | The release of first version of native is sync is a blocker if it isn't there. |
| - "what can we do?"
| | - it might not be a hard blocker for having sync there. |
| - we are conducting test days?
| | - idea is tighter knit strategy for this. |
| - is there a better communication that we can do?
| |
| - newsletter?
| |
| - a lot of the things coming up, how do we use our community for testing?
| |
| - not just on test days.
| |
| - if it's open? QMO? Browser ID ... we need your help! Come check
| |
| - how do we entice people to help? jobless friends?
| |
| - bbd? If you help build this, it would look good on your resume
| |
| - web api stuff: leave it with the open question with "how can you make it better?"
| |
| - give them a challenge. Give them a carrot... that's going to help a lot.
| |
| - "What's in it for me?" for the community ...
| |
| - articulate that. Here's what it is... here's the value
| |
| - take away : first off Q4 goal.
| |
| - community goal. Target for each individual. can collaborate that and put it up
| |
| - we can make this more meta.
| |
| - these are some things that we are trying to do.
| |
| - for example : Naoki's newsletter.
| |
| - test days, outreach events, mozcamps : and see a physical page?
| |
| => good start. community is a promenent slice to show what we are doing
| |
| - need more visibility : seeing what people are doing
| |
| action item : tchung : give bullets for browser tech on visibility for outreaching; show communities for each individual goals for people.
| |
| - newsletter: feedback. good stuff. nightly testers ; we got gaby2300 testing outside of test day and some other mozilla workers
| |
| - how wide: QMO, planet, Naoki's blog, mobile, browser tech
| |
| - action item to go to about:mozilla
| |
| - how do you get involved with it? etherpad and Naoki announces.
| |
| - how do we get outside in educations and such
| |
| - asking about tools, jobs, etc. market place for fennec users. We can definitely expand
| |
| action item: tchung : talk about impact of other communities in the QA community meeting
| |
| - crowdbot : martijn : browser chrome working and mochitests as well.
| |
| - haven't gotten them packaged in the extension
| |
| - working on right now
| |
| - post an extension later today with package mochitest and browser-chrome test
| |
| action item: b-tech team: please try out crowdbot for fennec xul; and give feedback
| |
| - need to get this out next week for crowd
| |
| - should we be spening resources to XUL base?
| |
| - this will not die. this is an addon; this is already in mochitest, gecko test, etc.
| |
| - browser-chrome will not work, mochitest should work for native ui
| |
| - we're almost there, we should finish it up
| |
| action item : tchung and mevans to talk about crowdbot off line
| |
| - dev are mostly working native
| |
| - results might get ignored for crowdbot
| |
| - martijn to post link when it's done
| |
| - stop here for project status
| |
| - read the wiki through for each project status
| |
| - any project status.
| |
| - JHammick has project status : jonas's team working on ; integrated with b2g
| |
| - can run with fennec
| |
| - automation side proof of concept : ctalbert's team is taking over w/ robotium to support nativeui
| |
| - John will drive later
| |
| - has it been finalized? no : just running as a proof of concept for now.
| |
| - launching fennec; battery api is working and comparing with native battery app
| |
| - what's the state w/ automation?
| |
| - as we build up the abilities of the web apis. How do we check them independently?
| |
| - dealing with issue with accuracy of the geo location APIs? We didn't see it.
| |
| - this is an example where it would fail; proof of concept.
| |
| - take a look at geolocation to see if we can do something like this
| |
| - didn't list all APIs in the APIs section
| |
| - it doesn't seem like it's overlapping with anything
| |
| - it offers good automations in semi automated, where it could be crowdsourced as well as a full automation that it does the full life cycle where the data gets pushed to a server
| |
| - Robotium route : we are pulling data out of the native API.
| |
| - we might be able to take the class and stick it in the automation
| |
| - 11:50 ; Mobile strategy
| |
| - hard stop at 12
| |
| - free at 1:30? release go: no go is at 2:00.
| |
| - place the meeting at 1
| |
| action item : mobile team to meet at 1:00
| |
| </pre> | | </pre> |