Time/Place

• Time: 12:00pm Eastern Daylight Time US (UTC-4)
• Place: Google-hangout, https://plus.google.com/hangouts/_/event/c1glu6soq43r1rr6ou17qtobug8

Attendees

• Andrew Woods
• Esme Cowles 
• Chris Beer *
• Daniel Davis *
• Declan Fleming
• A. Soroka
• Benjamin Armintor
• Zhiwu Xie
• Neil Jefferies

Note-taker = 
Previous note-taker = *

Agenda

1. Review of previous actions

2. Revisit "Areas of Assessement" and establish plan of action
3. Thought exercise: "What would be the technical "risks" of releasing 4.0 Production *now*"?
   1. Or another way, "Where do we want to put next sprint's dev energy"?

Previous Actions

From 2014-08-20

•  Esme to investigate current ModeShape development roadmap and how it aligns with F4
  • Modeshape Roadmap
• Adam and Ben to assess REST-API (goal of versioning this API)
•  Dan to enhance descriptions of "Areas of Assessment" numbers 6, 7, and 8
• Neil to define initial set of system CI tests

Discussion

• Action items from last meeting
  • Esme: Modeshape 4 is pretty much like Fedora 4, targeted at improving sustainability, performance, etc.  Not much roadmap after 4.0, but areas of focus for 4.0 are well-aligned with ours.
  • Ben: REST API assessment/specification is a good idea, but not done
  • Dan: Enhanced areas of assessment
  • CI test definitions: Neil absent
• Areas of assessment
  • Andrew: need to focus on topics with highest levels interest/concern, topics that can be acted upon now.
  • Priorities
    • Adam: REST API and Performance are highest priorities, and distinct areas of work
  • REST API
    
    • Adam: CRUD operations are the core and most in need of assessment, excluding auth, messaging, etc.
    • Dan: How to we ensure long-term evolvability of clients/apps
    • Adam: That's the purpose of specifying and versioning the API
    • Dan: What about other apis and stuff that's excluded from scope?
    • Ben: We should also create a TCK (http://en.wikipedia.org/wiki/Technology_Compatibility_Kit)
    • Dan: Need to specfy both how the functionality, and how that funcitonality is used used (identifiers, etc.)
    • Action: Ben and Adam will begin drafting a spec and what a TCK should cover
      • Incremental deliverable for next week: what LDP is, how F4 extends it, and bytestreams
      • Can draft Rob Sanderson, for input that's not so closely tied to the implementors
    • Dan: need to have criteria to judge REST API or anything else -- not just raw functionality, but also quality (reliability?)

• • Performance
    • https://wiki.duraspace.org/display/FF/2014-08-20+-+Performance+Summary
    • Dan: It's importat to have multithreaded clients to simulate real-world performance
    • Andrew: Real world use cases are important
    • Chris: Neil and I have added some of these, see https://wiki.duraspace.org/display/FF/2014-08-20+-+Fedora+Technical+WG+Meeting
    • CI test suite is the key deliverable
    • Dan: We have a limited amount of time to explore different scenarios
    • Andrew: Grinder work hasn't moved forward yet, but it seems like a good toolset for this work repeatable, flxible, multi-threaded, etc. suitable for CI integration
    • Action: Dan will review existing work and put together some scenarios will then move on to executing plan
    • Esme: will begin ingesting soon, can test repo v. federaetd filesystem, with and without jcr/xml serializer
    • Action: Esme will report plan/status next week
    • Dan: It's important to track when extended effects finish, and the system returns to baseline state