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 XieNeil Jefferies
Note-taker =
Previous note-taker = *
Agenda
Review of previous actions
- Revisit "Areas of Assessement" and establish plan of action
- Thought exercise: "What would be the technical "risks" of releasing 4.0 Production *now*"?
- 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
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
- Performance
Actions