Unable to locate Jira server for this macro. It may be due to Application Link configuration.
...
Ticket Summaries
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.
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.
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
Vagrant/Apache Camel Component Issue
Next week, D. Wilcox and A. Woods are to be at the Fedora Users Group meeting in Washington D. C.
They shall not be available for the next meeting
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
Unable to locate Jira server for this macro. It may be due to Application Link configuration.
and
Unable to locate Jira server for this macro. It may be due to Application Link configuration.
)
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)
A. Soroka (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; created a related ticket here:
Unable to locate Jira server for this macro. It may be due to Application Link configuration.
GitHub Shuffle
Need to sort out maintainers on a number of GitHub repositories
A Technical subtask is outstanding (
Unable to locate Jira server for this macro. It may be due to Application Link configuration.
)
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-exts 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 following GitHub repositories
Two sessions...one was a preconference event on the night of 10/21/15 (Monday)
Not much on what Islandora is doing wrong for Fedora 4
Hydra focused upon what they are improving (e. g. binding their Views)
Discussion landing on PCDM as least common denominator
Islandora over Fedora 4...Hydra over same Fedora 4...ideally, be able to have an admin view of Fedora resources
Lot of interest among the group in moving Hydra forward
Abstraction in Fedora 4...a standardized API is currently being established
PCDM conversation in particular is moving forward within the community
Addressing issues of value to the Hydra community
E. Cowles is progressing with a branch is moving towards resolving
Unable to locate Jira server for this macro. It may be due to Application Link configuration.
E-Tags
E-Tags are generated solely based upon last modified date (managed by ModeShape)
Doesn't always work...issue with inbound references (i. e. cases for referencing between repository resources)
Updating B so that it references A...updates timestamp for resource A
Some parties find this behavior to be valid and appropriate...because the one potential representation has been changed for A
Others which develop applications that rely on E-Tags find that changing the timestamps often can trigger failures
Strong E-Tags should be Weak E-Tags
Reasoning: Strong E-Tags are byte-for-byte identical with regards to response
With content negotiation, responses aren't byte-for-byte identical, but the E-Tags are same
Further, for a higher-level application (e. g. Hydra) weak E-Tags have additional benefits
Workshop at HydraConnect (all day on Monday, three parts)
Woods: Core features and hands-on exercises
Benjamin Armintor: Session on migration using fedora-migrate; ActiveFedora 8 connecting to fcrepo 3; ActiveFedora 9 connecting to fcrepo 4 and migrating the content
Lamb: Integrating with external components via Apache Camel...just used fcrepo-camel (didnt use reindexer, solr, triplestoreupdater); How can you integrate with Fedora using Camel (using routes defined in XML)
Re-ran migration utility...using Camel routes for image resources, filtered for just JPEG images, executed ImageMagick, and re-ingesting the thumbnail as a child of the resource with the image
Session later in week: Hydra, and migrating into fcrepo4 (A. Woods, B. Armintor are in the interest group)
Hydra community is in the position: no active development for fcrepo3 stack; how do I get on to Fedora 4 then?
Hydra is strictly focused upon fcrepo 4; Hence, the IG was born (define practices, documentation around migration)
(Within Hydra context, a consistent way of migrating into fcrepo4)
Exercising the limits of the Fedora stack
People are being drawn to the fcrepo4 project
Current and potential scalability appeals to these new parties
Concrete descriptions of tests are desired
These render it easier for individuals coming into project...leading to the creation of infrastructure and the addressing of testing
Infinispan and the potential of the fcrepo4 stack (particularly focusing upon scalability targets)