...
1. The decision is made on the changing Fedora package name. Fedora users/clients should not be impacted on it. However, software built around Fedora will be impacted.
2. Release 4.3.0 next week. Nick is the release manager. Andrew and Nick will meet on next Friday and proceed 4.3.0 release. Review current sprint JIRA tickets and decided which tickets to be included in the 4.3.0 release. People who want to do future Fedora release can contact Andrew.
3. After discussion, decide to store the properties presented as triples in fcr:metadata on the NonRDFSource being described (as opposed to on the fcr:metadata-backing resource).
[IRC discussion]
ajs6f: I claim that this won't prevent us from doing whatever we want with fcr:metadata later (making it a container, making it have a special lifecycle, filling it with peanut butter and Valvoline and baking it for several hours in a turtle shell, whatever we want).
escowles: i'm fine with storing the properties on the nonRDFsource -- that makes sense since they are about that resource 12:29
and i'm actually fine with retrieving fcr:metadata and getting triples about the nonRDFsource -- I think it was barmintor who was most concerned with the repository URL and the subject URI being the same
awoods: I think there is good reason for concern about a mismatch between the repository URL (binary/fcr:metadata) and the subject URI (binary)... but there does not appear to be a better solution at the moment.
escowles: i agree -- too many operations required by the binary and its description for them to peacefully coexist at the same rest api URL
4. a. Repository CRUD: LDP, Transactions, Versioning, Authorization, and Fixity. https://wiki.duraspace.org/display/FF/F4+GitHub+Organizations
b. ref impl. Could have something like http://docs.sonarqube.org/display/PLUG/Plugin+Version+Matrix
c. yes. seems everyone agrees with it.
Continue discuss 4.d in next week meeting.
...