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)
• Dial-in Number: (712) 775-7035
  • Participant Code: 479307#
  • International numbers: Conference Call Information
  • Web Access: https://www.freeconferencecallhd.com/wp-content/themes/responsive/flashphone/flash-phone.php
• IRC:
  
  • Join the #fcrepo chat room via Freenode Web IRC (enter a unique nick)
  • Or point your IRC client to #fcrepo on irc.freenode.net

Attendees 

• Esmé Cowles
• Danny Bernstein 
• Andrew Woods
• Ben Pennell
• Nick Ruest
• David Wilcox
• Jared Whiklo
• Bethany Seeger
• Daniel Lamb
• Michael Durbin
• Yinlin Chen

Agenda

1. Announcements
   1. 2017-06-12 Performance - Scale meeting
2. 4.7.3 Release Notes - ready to go
   1. 4.7.4 plan
      1. Align commits between master and 4.7-maintenance, with the exception of breaking changes in master
      2. 4.7.3 reverts should go into both 4.7-maintenance as well as master?
3. Import/Export utility - summary of current state and next steps
4. Fedora committer representation on Fedora Leadership group (for reference)
5. Update on low hanging, priority bugs
   1. 
   2. (and related)

6. Status of "in-flight" tickets

   
   

   
   

Ticket Summaries

1. Please squash a bug!

   
   

2. Tickets resolved this week:

   
   

3. Tickets created this week:

   
   

Minutes

Agent 1:

• Performance and scale meeting on Monday - Interest in moving forward, refreshing for more recent versions, integration with build processes

Agenda 2:

• 4.7.3
  • release ready to go, Nick cranked through it.
  • github.io doesn't redirect, so the docs for moved modules/projects don't update automatically.  Is working on cleaning that up.
  • Auth modules, master and maintenance branches getting setup correctly after release.
  • Just involved reverting 3 commits to cnd file, otherwise is same as 4.7.2.  Commits on 4.7.x maintenance branch skipped this and will go to 4.7.4.
• 4.7.4 planning
  
  • Discussing master, maintenance, commit strategies
  • master - improvements, with bug fixes.  
    • A few breaking changes, need to go through and inventory what those changes are.  RDF 1.1 vs 1.0 syntax.  CND files.  
    • Most of what is available is non-breaking
  • Andrew: Proposing that 4.7 maintenance branch should be non-breaking.  Look through commits on master, cherrypick non-breaking ones into 4.7 maintenance branch.  4.7 maintenance would also include the changes from 4.7.3.  Do a maintenance release.
  • Andrew: Master is the forward looking branch, will contain breaking changes (change client facing interactions).  There will be a fair number of commits where it is unclear where they go.  All commits going forward that are non-breaking should target master and maintenance.
    • Jared: Will this result in more work?  Having to figure out how to do something against both master and maintenance
    • Danny: committers could include info about how likely a commit is to cause breaking changes
    • Andrew: Will targeting multiple branches add a lot of overhead is a consideration.  Also, what do we want the maintenance branch to look like?  Should it track master or freeze it and only include bug fixes?  No 4.7.5 with new features.
    • Andrew: right now there isn't a lot of conflict between master and maintenance.  But overtime the gap will widen as master begins to move more towards the API.
    • Next major release is 5.  Will the API actually be stabilized this calendar year?  Only one major release per year, so it is going to be a while before we can do another 
    • Bethany: likes idea of 4.7 only being bug fixes.
    • Andrew: Current approach has been to leave maintenance branch alone, only add bug fixes to it.  It would be nice to be able to get features out prior to the big API shift release.  
    • Esme: Maintenance branch we only port bug fixes.  But if time goes by and we are piling up features, we could plan for minor non-breaking feature releases.  Do feature work on master, and do occasional non-breaking releases.
    • Jared: Okay with bug fixes, but pileup is a concern.  Concerned that that by providing non-breaking features independently, may take away impetus to get people to test the breaking stuff since they could go the easier route.
    • Bethany: will we still be maintaining 4.7 going forward?
    • Andrew: policy question, fedora leadership group needs to decide.  Would likely still address major issues, but not features.
    • Bethany: If that's the case, can understand bringing features back to 4.7 periodically and would support that.
    • Andrew: two questions:  What do we want to do right now for 4.7?  What do we want to do on an ongoing basis?  Sounds like there is some interest in bringing maintenance branch up to date with all the changes (non-breaking), is there a reason not to do this?  Dangers?  Pollution?
    • Esme: would like to see the changes introduced, even if they come with some risk of introducing bugs.
    • Andrew: So people are okay with 4.7.4 in the near term with features?  yes.   So maintenance branch will be relatively stagnant.  4.7.5 will just be a patch release.  5.0 is expecting to come out at the end of the year, with many breaking changes and the specification.  4.7 line, last major release, but will backport bug fixes.  Everything else will be on the 5 line.  There would then be a 5.x maintenance branch.  Master would then be targeting 6.0, but would assess if changes from master should be backported to 5.x for minor features and bug fixes.
    • Jared: once 5.0 released, then when a commit is worked and is a non-breaking improvement, it would target 5.x and 6.  Might be easier at the time of working to make two pull requests.  If maintenance branch contains the changes already, it'll be a lot easier to cut minor releases than cherrypicking back.
    • Danny: by merging sooner than later, will the whole process be served better?  For a developer it might be perceived as a hurtle to have to do two pull requests.  Complexity really comes in when a non-breaking commit relies on a breaking commit.  But still not sure worth the extra effort of targeting both.  Effort of developers vs managers.
    • Andrew: lets review conversation later after 4.7.4 for the sake of time.  Will start working on 4.7.4, then revisit

Agenda 3 - import/export/verify tools

• Andrew: Two sets of tickets, some for the import/export, some for the verification tool.  Best not to work on both tools at the same time.  Verification is trying to catch up now.
• Danny: Josh and him have been making some progress.  Couple issues ongoing.  Verifying export of external resources.  Should be ready to start testing verification tool in earnest.  Need to look at the different combinations of options that you can set.  Clarify which scenarios are working so people will understand the scenarios things work in.
• Andrew: Will have something testable soon, can do a release, will have list of scenarios it works for.
• Discussion of if verification tool version should track the version of import/export.
• Esme has a list of things that still need to go into 0.2 release: 

  https://wiki.duraspace.org/pages/viewpage.action?pageId=85530420

• Andrew: How to address these in a systematic/time sensitive way?  Sprint?  

• Esme: Most of them are about documentation and preparation of the release
• Andrew: Need to figure out how to collectively land this.

Agenda 5

• Bethany: Working on ticket, going to see if it helps with the other tickets

Agenda 4

• Will talk about more next week.  Putting committers on leadership group.

Actions