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)
  • U.S.A/Canada toll free: 866-740-1260, participant code: 2257295
  • International toll free:  http://www.readytalk.com/intl 
    • Use the above link and input 2257295 and the country you are calling from to get your country's toll-free dial-in number
    • Once on the call, enter participant code 2257295
  • IRC:

Attendees 

Agenda

  1. Deprecate fcr:import and fcr:export ?

    1. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
  2. HTML/JS integration test library?
  3. Four-digit versioning scheme?
  4. 4.4.0 focus
    1. Move projects into fcrepo-exts (see: F4 GitHub Organizations)
      1. Rename packages to "org.fcrepo.exts", or something else entirely
    2. Decouple those projects from the fcrepo4 pom.xml parent
    3. Plan on all extras projects starting independent versioning with 4.4.0
      1. Therefore, 4.4.0 will represent a common ground zero
    4. OSGi - demonstrate runtime configurability of F4?
    5. Servlet-API version? 3.01 -> 3.1.0
      1. Modeshape depends on 3.1.0
      2. This would imply a hard requirement on Tomcat 8 or Jetty 9.1 for deployment
      3. OSGi already requires 3.1.0 and Karaf 4 as a container

  5. ...

  6. 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.

  7. 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 

  1. Deprecate fcr:import and fcr:export ?
    • Andrew gave a history of what fcr:import and fcr:export is.  He talked about how it uses JCR XML format and it doesn’t contain all the same info that’s in the RDF.  Idea is to move away from JCR format, so that we don't have to support it if we moved way from using modeshape down the road. 
    • General consensus is to get rid of it. 
    • An alternate "export" approach exists in message-consumer, which will be replaced by Camel work. 
    • Would rather move towards an import/export which would have more robust RDF, which supports more platforms in general and contains more information. 
    • Next step is to bring this to the larger community to find out if there are any concerns. 
  2. HTML/JS integration test library?
    • Idea is to find out if anyone has a favorite library that is good at integration testing the UI. 
    • There is a trickle of HTML/UI regressions that sneak up. Andrew noticed that there are small UI bugs from time to time and we should be able to catch this with an integration test suite. 
    • Andrew asked for suggestions of test libraries anyone has used. No Suggestions. 
  3. Four-digit versioning scheme?
    • Reference: https://wiki.duraspace.org/display/FF/Fedora+4+Semantic+Versioning
    • Fedora's versioning is like semantic versioning, but with only 2 place-holders or digits, versus 3. 
    • Aaron mentioned that, though we didn't discuss specific numbers last week, that the 4.3.0.1 idea was what most were probably thinking of (using current scheme with an extra significant digit).  He added that there is some software out there with 3 digit versioning (4.3.0) and when an additional patch happens they add on to the number: 4.3.0.1  then when they go to next release they go back to 3 digits (4.4.0).   
      • Andrew was concerned that that scheme could cause some confusion, but maybe not. 
      • Guava libraries do this w/ 2 digits (15.0, 16.0).  A patch release adds on a digit:  16.0.1
      • Andrew asked if they update the 2nd digit - Aaron hasn't seen them do that yet.
      • Andrew said that the suggestion of adding on a digit in the case of a patch release is sort of a middle ground. 
    • Andrew brought up the point that there is going to be an effort happening soon: splitting out external modules and setting them free so they can have their own versioning schemes.  
    • Ideally they would have similar approach to Fedora4 versioning - something that is easily adopted by external modules.  Question: Would external modules always have version of 4?   Example: 4.3.0 -> 4.4.0
    • Right now all external modules are in lock step with parent code base.  If we continue to keep ext modules in lockstep for next release, the would all start at 4.4.0 and then do their own thing separately, incrementing as they see fit.  
    • Aaron mentioned, in regards to versioning, anything that communications with fedora REST API can easily be versioned. fcrepo-audit, fcrepo-webapp, fcrepo-transform - these would not, he thinks, have independent versioning. They may need to be in lockstep.  These interact directly with the kernel.  
    • Andrew asked that if audit module did not undergo any change, but the kernel continues to increment and release - if Aaron is advocating for bumping it's version number?
    • Aaron: maybe, but he needs to think more about it. 
    • A few options for four-digit versioning: 
      1. Do nothing, leave it as is
      2. Always have a 4 digit number, next release being 4.4.0.0
      3. Have 3 digits, but if there is a patch release, add the additional digit.
    • Mike likes the option C - a few others indicate they do as well. No one has issues with that idea.  Option C will be our current proposal and will run it by more folks and possibly go that way. 
  4. 4.4.0 focus
    • Andrew asked if this was discussed last week.  Aaron thinks that Adam was suggesting a, b and c be done on a case-by-case basis, as some projects have different ties to their parents' setup. Others are a bit more independent from the code base. 
    • Regarding 4a) Andrew:  The proposed plan is agreed upon so now it's details on where the modules go.  We need to figure out who the project owners are going to be, and if it's not in the main GitHub organization, decide on what its package name should be, and also decide of it gets decoupled from its parent's POM file.  Assumption is that ones getting split out of main repo have their POM decoupled from the parent POM.  
    • Migration-utils is not connected to parent POM - doesn't have licensing or checkstyle plugin, though there is still a minimal set of plugins and compatibility things that those projects need to conform to.  Basically all modules must conform to the coding standards. Do they version completely separately or are they in lockstep with the main code base. 
    • Andrew suggested getting this going right now - he will add a little more detail to the GitHub page. Projects with owners - here's the chance to get this going and start working out the kinks. Start shuffling the projects away from the main organization, move from main POM file and start the process of getting these moved around. This will help reveal any points of friction/issues that might come up along the way.  Doing this sooner rather then later so it doesn't drag out or only get half way done.  Ideally, get this done before the next release, which is in a month or so. 
    • Aaron will move the camel stuff out (fcrepo-camel, fcrepo-camel-toolbox)
    • Mike will move the migration utils (migration-utils)
    • Andrew will talk to Esme about being owner of fcrepo-audit, and moving that code base around. 
    • Andrew mentioned moving message-consumer and webapp-plus out of labs and into exts area. 
    • Some discussion about decision on how to deprecate things and clean up labs - to bring it inline with being more of an incubator, versus holding a lot of projects that aren't going to see the light of day. 
      • Andrew:  What was initially decided with message-consumer was to move it to extras and put a note on it that it is going to be deprecated in 6 mos or so and then move it to deprecated at the right time.  Essentially flag it and then once the time period is up, move it to archive or wherever. 
    • Discussion about versioning of the different / independent pieces of the project - we'll keep thinking about this and when we get close to release we will have to start to get more definitive about this process.  We don't really need to decide until then. If no changes take place in a module, it might be more confusing then helpful to increment version numbers.
    • Aaron wondered what sort of testing responsibility will we have for testing interoperability between different components and their version? Andrew doesn't think this will be a problem. 
    • 4e - OSGI work – Aaron thinks the issue of 4.e.2 will not be a issue.  If we use some of the new features of servlet-api-3.1.0 then it would be a problem, but we don't so it's really no change to the deployment. 
    • Andrew noted that before long we may want to use this (asynchronous requests), so at some point the bump would happen, but for now it doesn't need to happen. 

  5. Andrew: There are a lot of bugs  (https://jira.duraspace.org/secure/RapidBoard.jspa?rapidView=27). Most of them are very low hanging and easy.  Most of them are very small changes.  Anyone who is interested in getting into different parts of the code base  - these are good opportunities to pick up tickets. 

1 Comment

  1. Jared Whiklo

    To clarify #3.3 in my mind the 3-4 digit versioning scheme would work like this.

    • 4.3.0    - next major release
    • 4.3.0.1 - bugfix release
    • 4.3.1    - minor release
    • 4.4.0    - major release
    • 4.4.0.1 - bugfix release
    • 4.5.0    - major release

     

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