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

Ticket Summaries

  1. Please squash a bug!

  2. Tickets resolved this week:

  3. Tickets created this week:

Minutes

Release Update

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

The issues addressed are:

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:

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:

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

Discovery Requirements

(Ben mostly inaudible) 

Tickets

Please review tickets if you are the assignee.