Time/Place

This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join...here's the info:

Attendees 

Agenda

  1. 4.7.0 and 4.6.1 release update
    1. Release Testing - 4.6.1
    2. Fedora 4.6.1 Release Notes
  2. Major remaining spec issues: Create-on-PUT, Headers vs. URIs for atomic ops
  3. Import-Export Sprint; Call for participation!
  4. Any news from the "Discovery" requirements front?
  5. ...

  6. Status of "in-flight" tickets

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Ticket Summaries

  1. Please squash a bug!

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  2. Tickets resolved this week:

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  3. Tickets created this week:

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Minutes

Release Update

Topic: 4.6.1 patch release. Team: Jared, Dane Bernstein,  Andrew Woods.

The issues addressed are:

  • Upgrade to ModeShape patch release (backup/restore capabilities compatible with newer version).
  • Concurrent client creating the same resource

Release should be out at the end of next week.

Kevin Ford has not tested the concurrency issue yet. Hopes to do it today. Limited test with 4.7 revealed no issues. 

Andrew discusses the background of the issue: Modeshape 4 Infinispan into a non-Infinispan ModeShape introduced the issue. ModeShape applied patch to 5.2, and that patch has been back ported now, so that’s what we have in 4.6.1. 4.7.0 is using the version of ModeShape that’s in between, so that’s the reason behind the issue. The solution suggested (by Kevin) is to continue with the releases (assuming no issues): follow up 4.7.0 with 4.7.1. 

Aaron’s comment: All commits will be fine with 4.7.1. release; other than bugs fixed, nothing much has changed.

Andrew’s suggestions:

  • Please test stuff if interested in either issue. 
  • Add test results to wiki.
  • 4.6.1 sanity test for Hydra and Islandora needed. (Esme volunteered for some testing).

Spec Issues

Adam Soroka (ajs6f) clarifies the background: “Trying to do a stable draft .. to present the community” with options (not finalize anything).

Issues at stake:

  • Create-on-put: No negative response yet (discussion with Ben)
  • Atomic operations: Transactions have a URI currently. This is “better in some ways, not so in other ways.” ajs6f and Aaron Coburn seem inclined towards using headers.

Other than that, "most of the issues have been resolved." 

ajs6f suggests different ways for the interested parties to submit feedback. Stresses on the importance of finding out where the code base diverges from the spec.

Andrew’s comment/point # 1: Resources within a transaction are different resources than those outside. (That’s represented by a different URL.)

ajs6f: But there’s more to that: (a) sometimes they are the same resources; (b) the resource is the same, but the state is different (after mutation, etc.).

Andrew’s point # 2: Easy to following links for transactions with URIs, easy to remove the URI…  With headers, “the browser interaction would be more complex.”

ajs6f: Removing a segment from a URI is no more RESTful than adding a header is. We can add canonical links. If you remove the headers, you are at the resource. . . so it’s very “natural” —  otherwise you have to follow a series of links, “. . . the semantics of which might not be obvious." There are tradeoffs on either side. (Andrew in agreement about the tradeoffs).

Aaron: Using a browser so that if someone clicks refresh it doesn’t lose that. Make the interaction work so that it’s pretty obvious that you are in a transaction or if you are in outside the transaction.

ajs6f: Perhaps a visual indication could be done to indicate transaction. A toggle perhaps.

Ben: Nothing should be changed until design documentation is done!

ajs6f: The specification will link to a document that describes how the codebase is different and why.

ajs6f: In conclusion, no one spoke up in favor of URI approach; there’s some interest in headers.

Andrew appreciates Adam’s effort.

Import/Export Sprint

  • Nick: 3rd sprint, Dec 5th - 16th. Short on volunteers (Tasks: (a) coding and (b) testing/documentation).
  • Esme and Jared (and Danny Bernstein) are available.
  • Bethany and Joshua are working on a Python tool to do verification
  • Contact Bethany if interested in working on details.
  • Looking for more volunteers (Marcus Barnes?).

Discovery Requirements

(Ben mostly inaudible) 

  • awoods (providing a summary): The issue was raised at HydraConnect higher; folks are still talking about it.
  • "Discovery is not the right word here." 
  • Ben: No one word yet . . .
  • Esme: “. . . not sure if there’s a good term to encapsulate that..”
  • awoods: As the requirements do solidify, it would help to have them have mentioned in this call.
  • ajs6f (side comment): Not sure if we are all (mikeAtUVa, e.g.) talking about the same thing.  (Andrew agrees.) 

Tickets

Please review tickets if you are the assignee.

  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.