Time/Place

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

Attendees

Agenda

  1. Second Alignment Sprint Starts Monday
    1. WebAC
    2. Versioning
    3. Documentation
    4. Miscellaneous bugs/improvements

  2. Planning for the Transition:  Two Fledgeling Efforts in need of volunteers.

    1. Adopters Guide

    2.  Breaking Changes Between Fedora 4.7.x and 5.0.0
  3. Sprint planning
    1. Update on  Ben Pennell's work on mementos of binaries and their descriptions.
      1. Outstanding questions:
        1. Should we have LDP responses for mementos?
        2. Does a memento object act as a full LDP object, particularly with respect to headers?
        3. Are the edge things (such as headers) important for our users' workflows?  Should we handle these?
        4. Is versioning for items only currently in the repo, or all items that have ever been in repo?
        5. Should Fedora keep versions of items that have been deleted?
      2. feedback from leadership?
    2. WEB ACLs
      1. Peter Eichman's assessment of moving WebACLs from modeshape.

        1. Do we still want to support the current scheme for the sake of backward compatibility?

        1. Discuss Aaron Birkland's questions in the issue comments section
        2. Should we consider abandoning Section 5.4 Specify ACL on resource creation in light of this issue as well as  and ?
    3. : 
      1. Are we comfortable with messages emitted?
  4. Shall we consider using Duraspace checkstyle rules?
    1. Checkstyle Analysis
    2. Repo
    3. There are three rules in the fedora checkstyle rules that are not in the Duraspace checkstyle rules: 
      1. requiring @author in javadoc
      2. "final" required for parameter variables
      3. "final" required for local variables
    4. There are 40-odd lines in fcrepo4  that would need to be corrected to roll this out

Sprint tickets 

Ticket Summaries

  1. Please squash a bug!


  2. Tickets resolved this week:


  3. Tickets created this week:


Minutes

  1. Upcoming Sprint
    1. Emerging focus on WebAC.  
    2. Versioning will probably go through the whole two weeks
    3. Documentation will be needed:  
      1. Adopters Guide - can someone look at a pending PR and approve it?
      2. Document: Breaking Changes Between 4.7.x and 5.0.0 - created as a place to put differences
    4. Focus is mainly API alignment, but if there's time maybe have some folks working on fixing issues that are not specifically sprint related.
    5. Danny Bernstein has been doing some sprint planning which should be complete by Friday. If you know of an issue that he should consider as part of the sprint, let him know.  He will update the sprint alingment document and send an email on Thursday or Friday of this week. 
    6. Sprint Kickoff meeting is at 11 am ET on Monday morning.  Seems like that time works for most, if not all.  
  2. Sprint Planning 
    1. Memento discussion - Ben Pennell talked about approach the group seems to be coalessing on. He is working on implementing that and hoping to have a PR this afternoon so people can see what this approach would look like.  He is having a few issues getting subjects correct right now.  Issue around etags and the wrong one being returned when asking for description (of a binary) - you currently get the etag of the binary.  Not sure why it was done this way, may have been a convenience thing.   Should we make it so you get the descriptions etag when you ask for it?  General thought is that the binary's description should return it's own etag - general concensus here.  Ben will work with this approach in his PR. We'll go down this road for now and reconsider if we learn more about why this behavior was created this way in the first place.
    2. LDP responses for mementos question talk about - headers persisted as part of the mementos?    consideration of etags
      1. The acl wouldn't be part of the memento, so not stored with them
      2. apply permissions to time map for creation / view / delete of memento
      3. as time goes along and permisions might get changed – you don't want the permission from 1 month ago to work with some of your mementos and others have different perms. Idea is that all the mementos fall into the same bucket – and the permission for that bucket, as a whole, is what might change. 
      4. ACL's for mementos - an alg could look at current resources ACL – that ACL  is what's applied to all memento resources.   Before you check the original resource, you check the time map first so that the mementos could have different perms.
        1. Peter Eichman - would have to duplicate ACLs? 
        2. mementos can only be read or deleted, so do they need a different ACL?  Can they follow whatever inheritance path structure we define? 
      5. feedback from leadership on deleting a resource - what does it mean for the versions?  leadership seems to like the idea of keeping the tombstone with versions still in place upon deleting of resource.  So the versions live under the tombstone. So one could recover.  Need to think about how to restore a version from a tombstone and maybe keep the same URL. Then what happens when you delete the fcr:tombstone – all mementos will get purged for that resource.
    3. WebACLs
      1. Assessment of removing WebACLs from Modeshape. Danny took a quick look and didn't think it'd be too complicated to separate the two.  Perhaps we can accomplish this during the sprint
      2. There is a no more then 1:1 resource:ACL, which ignores inheritance.  If an ACL triple is editiable by the user, then we can run into complications of change to that triple or adding more ACL triples.  
      3. What is the implication of dropping 5.4 from the spec? – Perhaps when you create a resource, it has a default location for that resources ACL, whether or not one is there.  
        1. Maybe we have a server managed location like fcr:acl  - that would be a starting point for locating the ACL, if nothing at fcr:acl, go up the inheritance tree from there to get the ACL. 
        2. Example from Peter Eichman:  top level PCDM container – all the PCDM modelled collections are all siblings under that.   There is an ACL on that parent container, so no resource in it has it's own ACL.  Per collection defaults for ACLs their current heirarchy won't work for themb because of data modeling.  AccessToClass impl would make that available to them. Creation of resources would need to add an appropriate access class to that.  
        3. Leads back to question of what is best practice for data modeling in Fedora 4.   At one point in time it seemed like the above scenario was a fairly performant way to model ones data. 



Actions