...
The url and the location map: http://11870.com/pro/manolo-1934-bar-restaurante
In any case, the area of Moncloa/Arguelles is full of bars.
...
- Andrew Woods
- Aaron Birkland
- Brad McLean
- Kai Strnad
- Asger Blekinge...
- Steve Bayliss
- Thorny Staples
- Bill Branan
- Chris Wilper (virtual Chris)
- Bill Parod (Northwestern U., USA)
- Louis Varita (UNED Univ in Spain)
- Matteo Boscini (CILEA, Italy)
Meeting notes
Morning session
...
- No overall best time for releases based on people's availability
- Not a good idea to release right at Christmas or Open Repositories
- Two releases a year roughly in October and April (similar to the Ubuntu release schedule) would make sense
- More frequent releases than this are desireable, eg every 3 months
- Aim for a 3 month release for 3.5, ie mid-November, plan at next committer meeting
...
- Bug fix release plus re-engineering of the release process (important to ensure we do have user-facing items in this release)
- Two release manager roles for this release - traditional release managment and release process re-engineering management; Aaron may be willing to cover the former with Chris leading the latter
- Release will include continued work on ECM and prep work for high-level storage (such as Spring integration)
3.4 Release
- No change to the timing for this
- Noteworthy outstanding items for this release:
- adapter for LLStore plugins (addressing Java package renaming)
- Datastreams: utility for migrating inline XML datastreams to managed content
- Datastream size: utility for calculating size of existing M datastreams (size now calculated automatically for new ones)
- Possibly new Fedora client (Asger)
...
- Currently, live documentation on the wiki is for the current release, previous version of live documentation is snapshotted to archive documentation for previous release
- This is a barrier to documenting trunk changes, as it means modifying current release documentation (which then would not represent the current release)
- Would be better to snapshot current release documentation as part of release process and link to that as the current release documentation (read-only, but allow comments, which would feed into next release), and have the live documentation reflect trun
- There are still issues around this approach with changes done in branches (eg if branch doesn't make it into trunk for the release)
- Atlassian have a space for each release, not clear if they have a "trunk"/dev version, we should look at their process in more detail to see if we can learn from itRecruit a documentation gardener (non committer)
Testing
- System tests need enhancing
- revisit what fits in config-A/B/Q test suites
- do the current set of test suites still make sense?
- should add testing for the various database, jdk, and OS variations that are usually part of release testing
- Run code coverage tool (Atlassian Clover), do this overnight (as part of nightly build)
- Have a JIRA issue for code coverage so this gets done at least once per release
- Current test objects need revisitiing, need to step back and reconsider how the testing fits together
...
- Hold "special topics" meetings for "getting started with Fedora development" to lower the barrier to coding with Fedora in various dev environments (Eclipse, IntelliJ IDEA, Netbeans)
- There is a need for review of patches, a "buddy" system could work, try and bring the person being "buddied" into committer meetings
- Improve visibility of stuff being worked on, current priorities: publishing the "small items", announce on lists current priority of issues to encourage feeback/voting
- Possible role for community management here, this could be the release manager, perhaps we should have a release manager who is not a committer
- Report back to community outcome of committer meetings, particularly status of JIRA issues, JIRA issues opened/accepted; to dev and user lists
Roles for non-developers
- Documentation gardener - keeps the wiki organized and up-to-date
- Secretary - keep notes in all committer meetings and helps to keep the community up-to-date and involved
Face-to-face committer meetings
...
- Not a lot has changed since the London meeting (Data Conservancy work has affected availability)
- Feedback needed in order to progress this (Aaron presenting at the conference, specifically requesting feedback)
- Series of special topics meetings to be held to make decisions
- There are big issues, need proper governance for these issues
- Key themes in progressing this are a roadmap and governance
- Development plans to be finalized at next committer face-to-face
Enhanced content models
- Most of the ECM specification has been implemented for 3.4
- The validate method has been implemented (outstanding work on RELS-INT validation)
- Items on the roadmap:
- "Clone" method (3.5 release?)
- Search engine configuration for atomistic models
- Also noted that atomistic models are problematic in general for indexing, searching, OAI-PMH
...
- There is a basic working implementation (http://github.com/kstrnad/fedora-commons-dropbox)
- This is a "folder watcher", FTP is also available
...
- We have two APIs (REST, SOAP) with two sets of code
- SOAP splits into API-A and API-M, REST does not
- Mapping SOAP directly to REST does cause issues, however we should perform a comparison and understand the differences
- The Java client should map directly to the server API
- Merging APIs should be targetted at the 4.0 release
- Consider hooking authorization to objects/datastreams rather than API methods