- Giuseppe Digilio (4Science)
- Nelson Torres
- Matteo Perelli
- Not as much to report this week, but we have 4 open PRs that need review/merging
- REST Services: https://github.com/DSpace/dspace-angular/pull/62
- Only feedback from Antoine so far
- Uses REST mockups, but is pulling data
- Needs final review / merger
- Tim: In essence of time, we likely should start to "trust" this early work. Merge it quickly, and log tickets later if we find flaws / bugs that need resolution. Otherwise, we slow down the development process
- James: agrees that this should likely be merged if it is pulling data successfully
- ACTION: Art: will check one last time with Antoine to see if he has this working. If so, will merge it
- Yarn: https://github.com/DSpace/dspace-angular/pull/66
- Hardy tested on Linux. Art tested on OSX
- Seems to be working well, waiting on a test on Windows. Tim volunteered
- ACTION: Tim will test on Windows and merge if working.
- CI Testing: https://github.com/DSpace/dspace-angular/pull/51
- Waiting on resolution of "concurrency" vs "npm-run-all". We want to avoid having two dependencies that do the same thing.
- Matteo noted issues with getting "concurrency" working for this PR
- Art suggests possibly just moving to use "npm-run-all" everywhere. We can use this instead of "concurrency" if it is working better.
- Where "concurrency" is used (and two lines down): https://github.com/DSpace/dspace-angular/blob/master/package.json#L44
- ACTION: Matteo will look at using "npm-run-all" throughout our
package.jsonand remove "concurrency" as a dependency.
- Spinner PR: https://github.com/DSpace/dspace-angular/pull/43
- William Stanley Welling said he'd review this PR code. But he's at code4lib conference this week.
- Tim: Let's table this until next week. At next week's meeting we should make a decision on this PR. It's been open/stalled for too long now.
- Either, we merge it immediately and create a new ticket to discuss how the Spinner could be improved (in the future)
- Or, we get immediate feedback on how to rewrite/refactor it now, so that we can move this forward ASAP
- Side Discussion: How are these meetings going? Alternating between Slack & Google Hangouts. Weekly meetings, etc.
- Positive feedback. The weekly touchpoints are good (keep us on task). Facetime every other week also good for bigger discussions.
- Seems to be working well, and we'll continue with this structure.
- Andrea asks about his idea to put "http://handle.hdl.net" URLs in the Browser URL/History.
- See last paragraph in this comment: https://github.com/DSpace-Labs/Rest7Contract/issues/1#issuecomment-280715885
- Not likely in the URL..that seems confusing (Art & Tim agree)
- However, we agree that the Handle (prefix/suffix) could be used as the internal identifier (much shorter than UUID) as discussed in that same issue.
- Nelson Torres
- Matteo Perelli
- RESTContract - Not much progress since last week
- However, Andrea created a new RESTContract PR as a proposal for the main README.
- README viewable at: https://github.com/4Science/Rest7Contract/blob/4e43ff8c02c12229572f97a51c81d22dfaf54e21/README.md
- ACTION: All should review this initial README and make sure we agree. Add comments/questions or approval. Let's get this merged quickly.
- New REST code (in 'dspace7' branch of main GitHub repo)
Metadata hierarchy representation PR: https://github.com/DSpace/DSpace/pull/1665
Concerns: very hierarchical. Concerns about whether this is too complex for our needs
- Art: Can we deal with metadata fields like any other object, via UUIDs? (Tim agrees this might be easier)
- How does Fedora and other systems deal with metadata updates via REST?
- Fedora REST: RESTful HTTP API
- Any other systems we should look at?
- Terry now contributing to code! Docs getting improved based on his feedback. Good progress
- Pagination PR: https://github.com/DSpace/DSpace/pull/1666
- Waiting cause it makes some significant changes to API that could conflict with "master". Otherwise the code does look good
- ACTION: We need a concentrated effort to fix the build/CI testing issues on 'rest7' branch. The sooner we do so, the sooner we can move all development over to "master". The longer we keep this a separate branch, the more likely we'll hit difficult code merges
- Andrea had a call for help. He may be able to tackle, but may need support
- Tim offered support...may not have time to lead the effort, but knows the Maven build process fairly well. Is able to help with Questions/issues (at a minimum)
Wrap up: Thanks to everyone for your hard work here. Next week's meeting via Slack.
Next Meeting: Thurs, March 2 at 16:00UTC via Slack