You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

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. Camel component issue - priority for next week's workshop

  2. Next release planning

  3. Switching to a new conference line
  4. Notes from the field: HydraConnect
    1. Issues raised:
      1. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
      2. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
    2. Constructive interop discussions: best practices and common us of PCDM
    3. F3 to F4 migration interest group
  5. Scale/performance opportunities – brainstorm testing scenarios
  6. Vagrant refactoring: new base-box?

  7. Landing in-flight issues - revisited

    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.

  8. ...

Ticket Summaries

  1. Please squash a bug!

    type key summary assignee reporter priority status resolution created updated due

    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

(Integration tests are required for Bethany's latest pull request)

Vagrant/Apache Camel Component Issue

Next week, David and Andrew are to be at the Fedora Users Group meeting in Washington D. C.
This features a Fedora 4 workshop (requires the spinning up of a Vagrant Box)
Recently, this Vagrant stopped working
When 4 commits are rolled back, the Box is fine
Determining which of these commits is the perpetrator is necessary
Unless an easy fix can be determined, the rollback will suffice for the time being

Apache Camel Components

Vagrant depends upon snapshot versions of Camel components
Without previously spinning up Vagrant...if a commit went into toolbox...and Jenkins pushed it...it could potentially be pulled into the Vagrant box
Tying Vagrant box to released vs. bleeding-edge components 
Confirmed as reasonable by acoburn

Next Release

Community has gone longer than preferred to go between releases
Call for a new release
Contributors: should we be waiting on any outstanding issues?
Not everything works...clustering still doesn't work (since 4.3)
awoods prefers to have frequent releases, rather than wait to introduce fixes
acoburn: fixes in review preferred to make it into a release (Issues 1752 and 1706)

Issue 1706

Discussed between ajs6f and acoburn
They have a temporary patch; wait to fix this in Modeshape
Implement a patch (which works fine), or update the Visitor Class (an interface in Jena; this requires more work)
ajs6f: Good with pull request as it stands
Osman Din: confirms that he shall create a ticket in Modeshape for this
Create another ticket for the Visitor approach?  Or will Modeshape fix handle this?
acoburn: Modeshape ticket will handle it; Visitor implementation would still be useful in other contexts
acoburn: confirms, another ticket for Visitor within Jena would be good; can create the Visitor ticket

GitHub Shuffle

Need to sort out maintainers on a number of GitHub repositories

Technical subtask is outstanding (1745)

acoburn: Outstanding issues for these shouldn't hold up a release

awoods: These 6 repositories appear to have been moved out of fcrepo-labs, and into fcrepo-ext where appropriate

awoods: Just a matter of updating the README file for each of them

Identifying the GitHub Repo. Maintainers

Finding the most commits, assigning the maintainers based upon this

Coburn and Ruest coordinating who shall be maintainers
A Woods:
Call for maintainers for any of the 6
WebAppPlus: awoods
Transform: whikloj, acoburn
Audit is assumed to be Esme's
This still leaves Audit, MessageConsumer, and WebAppPlus with 0 or 1 maintainers
Without owners, note that these modules are to be put on the fence, staying where they are

Still outstanding: selecting which of the modules to be released...and which of these lie with the maintainers

Response: create a matrix as a part of this process
Let's say we do that...which modules to be released (not a huge deal)
  1. Issue 1752
  2. Issue 1706
  3. Issue1683

It was suggested in a previous release that release candidate branches be created

Let these float out there for testing (as integration tests alone may not be sufficient)
Are people in the position to do sandy testing (if candidate branches created over the next week)?
Ideally, all developers in Fedora who run into issues while testing would create a ticket
For example, the most Vagrant issues (tests are passing, but not working)
whikloj, acoburn, and Nick Ruest suggest the usage of release-candidate branches with a code freeze

awoods: Prefers to get in some more tickets in review before Monday

Following this, a code freeze begins on Monday and throughout next week
Week of 10/12/15: Can perform a release
The code freeze message, hence, shall be announced to the community

 

  • No labels

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