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)

No change to the timing for this
Noteworthy outstanding items for this release:
1. adapter for LLStore plugins (addressing Java package renaming)
2. Datastreams: utility for migrating inline XML datastreams to managed content
3. Datastream size: utility for calculating size of existing M datastreams (size now calculated automatically for new ones)
4. 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 it
Recruit a documentation gardener (non committer)

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

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

...