Well, then, let me just pile on some more here since I forgot to add this to my last reply....
Regardless of the path we take to get to Milestone 1, v1, etc... We need to include QA in the planning/scheduling/thinking/doing (add us to the wikis/pads/content please): "Who's doing the work:" QA: I will be leading the QA efforts for Milestone 1 with direct support from the entire Services QA team under Edwin Wong. Some Android- and Desktop-specific testing, especially in the areas of tools and automation, will be indirectly supported by the respective QA teams, with guidance and scheduling to be provided by Bob Moss and the QA management staff. Once this hits Nightly, end-to-end testing by the entire QA team will need to be coordinated. Input from Dev and OPs will be greatly appreciated at that time to help scope the work, resources, and scheduling in order to meet the various Milestone 1 goals and deadlines. "What's next:" Nick, please mark all significant/testable bugs with the [qa+] label and cc me. Lloyd, if you could do the same for the desktop bugs, it would be greatly appreciated. Alternatively, I can walk through both sets of bugs with you two (a sort of triage) and add the necessary labels and the names of QA that will want/need to track the bugs. "Key Steps" This is where input from QA and OPs will be extremely helpful. One for testing and qualifying the work. The other to actually perform the necessary deployments to Stage and Production. In addition, we may need to accelerate the schedule of bringing up the PiCL/Sync Stage environment for testing the Milestone 1 code in a production-like environment. Right now that environment does not exist. Thanks, James ----- Original Message ----- From: "Ryan Kelly" <[email protected]> To: [email protected] Sent: Wednesday, August 14, 2013 5:55:38 PM Subject: Re: Client Implementation - Milestone 1 On 15/08/2013 4:44 AM, Richard Newman wrote: > > There's been some talk over the past few months about using Sync 1.1 plus FxA > to achieve some of this. I support doing so, if we can do the following: > > * Build and deliver device management and service discovery/negotiation, such > that we can have one auth flag day, and have the next transition -- to better > storage/client/etc -- be managed by our service discovery/capability stuff. > We'll need this anyway, and this is point 5 in the last email. > > * From an engineering/product perspective, we must explicitly regard the Sync > 1.1 code as a dead-end (a hacky stopgap), just as it is right now, and don't > waste time fixing and extending it beyond life-support. +1. We need to commit to building something better, and have a concrete plan for how we'll transition to it. > This has the two large caveats: that we absolutely need product buy-in for > both stages, and that Mark and Ryan are on board. Mark and I are both on record as being happy to ship this atop the Sync1.1 servers, so I guess we can't back out now :-) We'll need to do some non-trivial server-side work for durability purposes, but that can happen in parallel and transparently to the client. Ryan _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
