Time/Place
This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join...here's the info:
- Time: 11:00am Eastern Daylight Time US (UTC-4)
- U.S.A/Canada toll free: 866-740-1260, participant code: 2257295
- International toll free: http://www.readytalk.com/intl
- Use the above link and input 2257295 and the country you are calling from to get your country's toll-free dial-in number
- Once on the call, enter participant code 2257295
- IRC:
Attendees
Agenda
4.3.0 Release is out
- Process reflections and improvements
- Release candidates?
- 4.4.0 Release manager?
- 4.4.0 focus
- Move projects into fcrepo-exts (see: F4 GitHub Organizations)
- Rename packages to "org.fcrepo.exts", or something else entirely
- Decouple those projects from the fcrepo4 pom.xml parent
- Plan on all extras projects starting independent versioning with 4.4.0
- Therefore, 4.4.0 will represent a common ground zero
- OSGi - demonstrate runtime configurability of F4?
- Servlet-API version? 3.01 -> 3.1.0
- Modeshape depends on 3.1.0
- This would imply a hard requirement on Tomcat 8 or Jetty 9.1 for deployment
- OSGi already requires 3.1.0 and Karaf 4 as a container
- Move to a four-digit version number scheme?
- Community comment: Re: Fedora 4 Semantic Versioning
...
Current Priorities
- Performance
- Single subject
- fcr:metadata as a container
- Point-like objects
- Camel RDF serializer
- Migration-utils
- Bugs
|
Tickets resolved this week:
Tickets created this week:
Minutes
4.3.0 Release is out
- Process reflections and improvements
- There were a few last-minute pull requests – having a longer code freeze might be better.
- Or maybe we should have release candidate branches that get voted on? This is the way that other projects work, e.g., Apache.
- Esme, Nick and Adam are all in favor of having release candidates
- Release candidates could be open for testing/voting for months, or just a few days
- Aaron: So we'd want to agree on process, how long to leave release candidates are open for testing and voting, etc. and update the release docs
- 4.4.0 Release manager?
- Yinlin volunteered
- 4.4.0 focus
- Timeframe is uncertain
- Move projects into fcrepo-exts (see: F4 GitHub Organizations)
- Rename packages to "org.fcrepo.exts", or something else entirely
- Adam: who is taking responsibility for the modules should decide what namespace is used
- Aaron: do we want to add "exts" to e.g., org.fcrepo.transform?
- No need to make a decision right now, but we will need to resolve these
- Decouple those projects from the fcrepo4 pom.xml parent
- Aaron: some can be decoupled (Camel, client, etc.)
- But transform, audit, and anything that interacts with the kernel will need to continue depending on fcrepo4
- Esme: So we should go through the projects and decide what can be decoupled and what needs to depend on fcrepo4
- Plan on all extras projects starting independent versioning with 4.4.0
- Aaron: For decoupled projects, there's no compelling reason to keep the versions in sync, but the audit/transform/etc. projects might be better to keep in sync
- Adam: I would hope we could decouple the version numbers, and as the API specification goes forward, we might be able to dissolve them and make them not Fedora-specific as much as possible
- Aaron: So we'd be separating the fcrepo4-api and fcrepo4-impl into separate projects
- Adam: Absolutely
- Aaron: And we could break out a number of utilities that aren't related to the Modeshape implementation
- Adam: They could go in the kernel-api (as long as they are related to the models and not any implementation)
- OSGi - demonstrate runtime configurability of F4?
- Aaron: There's been progress here, optimistic about this
- Servlet-API version? 3.01 -> 3.1.0
- OSGi is more strict about dependencies, so it would require 3.1.0, and Modeshape depends on 3.1.0 (we're downgrading to 3.0.1 in our Maven config)
- The downside is losing compatibility with older servlet containers like Tomcat 7 (Tomcat 6 is EOL at the end of 2016, so expect Tomcat 7 to be supported for quite some time)
- We may be able to just depend on whatever JAX-RS provides and not have this explicitly required
- Move to a four-digit version number scheme?
- Community comment: Re: Fedora 4 Semantic Versioning
- Since the "4" is fixed, our versioning system isn't really the same as the standard semantic versioning
- Having a four-digit version number could be more clear
- Adam: Not sure anyone's confused – backward compatibility may be an issue
- Aaron: We've been focused on moving forward, not maintain backwards compatibility
- Esme: Not a lot of production installations yet, so not much emphasis on version/API stability yet – but that will change as more people migrate
- Aaron: Move to 4.4.0 and new versioning schemes is probably a good time to move to a four-digit version numbering scheme
- Adam: Better to make any changes sooner rather than later
- Current Priorities
- FCREPO-1609: Adam: General interest in how fcrepo4 handles large RDF, not any real-world scenario
- Bethany: Is this related to the OutOfMemoryError issue?
- Esme: No, that's a real practical issue, this is more of a benchmarking task
- FCREPO-1474: Adam: Related to fcr:versions and fcr:metadata, I've done most of the sub-part related to fcr:metadata, but need some HTML fixes
- Expecting Benjamin Armintor to chime in here
- FCREPO-1590: Esme: Not sure we've really reach consensus, but this responds to a real use case, and shouldn't be too challenging to implement since we already have working containers
- FCREPO-1470: Adam: This is non-container RDF sources, as requested by Aaron Birkland and others. There haven't been any developer resources dedicated to this, yet
- Related to having RDF that describes non-repository subjects
- FCREPO-1519: Esme: We had a call to talk about requirements, I'll revise those requirements and UCSD will take a stab at implementing it soon