Versions Compared

Old Version 11

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version 12

changes.mady.by.user Mark Diggory

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Sorry, Had to reconstruct the pull request after hard reset... lesson learned, do not use "pull request" to merge your fork

...

  1. Brainstorming Features/Changes for 3.0. Can we work towards development teams around any of these projects?
  2. Other DSpace projects receiving mention recently
    1. Migrate Search and Browse to DSpace Discovery
    2. "Change which UIs come out-of-the-box" (and which are optionally installed later)
    3. Move configurations to DB or similar (so they can be managed/edited from Admin UI)
    4. Context Guided Ingest (or Item Type based submissions)
    5. Other Development Proposals

...

  • Main Topic: 3.0 Release. We have a very preliminary schedule up at DSpace Release 3.0 Notes
  • Richard sent some brainstorms to Committers around whether we want to do any radical/significant re-architecting of DSpace for 3.0 (or start any work in parallel to 3.0). Tim attempts to summarize them (likely badly).
    • Request for Richard to post these up on the Wiki or similar, so that we can track them better
  • Some concerns that Cocoon (technology under XMLUI) is not very well supported anymore. Do we need to look towards a new UI? Is XMLUI work sustainable if the technology underneath isn't really moving forward
    • Likely if we stayed on XMLUI, we'd need to get more involved in Cocoon to help push it forward more.
    • Obviously, this does NOT mean we are stopping any support of XMLUI. XMLUI will continue to be supported fully in 3.0. This is more of a long term question as to whether we need to begin looking towards a new UI.
  • MarkD mentions some concerns about any "rapid rea-rchitecting" project from "mistakes" made in past, especially what we learned from the 2.0 Prototype process & the DAO Prototype (before 1.6).
  • Any larger re-architecting would need to involve more committers (cannot fall on a sub-set of committers or it may not achieve wide acceptance)
  • 3.0 would need to be scoped properly, no matter what it is. Cannot do everything all at once. (Sands)
  • MarkD wants more info on suggested "radical re-architecting" changes from Richard
  • Richard explains thought processes behind larger changes like Metadata on All Objects (high priority feature, which may require large changes)
    • Metadata on All Objects would require large scale changes in DB/API, and also major UI level changes (as most every layer of UI would be affected by newly available metadata). Do we want to make those massive changes to XMLUI? Especially if we are already wondering if ongoing Cocoon support is questionable.
  • Does Admin UI even need to be the same as the main browsing/searching UI? (Mark Wood) Could we scope any project so that it just deals with part of the UI.
  • WebMVC project does this / same with XMLUI – several not neither were "feature complete" at the initial time of release.
  • Do we really want to be deciding on or supporting multiple interfaces centrally (as a Committers team), or do we want to concentrate more on "business logic" / REST / maybe one UI? (MarkD) Our resources are already a bit strapped.
  • Should we look at what we have "mostly done" in terms of UIs? – i.e. put more work into WebMVC (Robin) or SkylightUI (Tim)
  • MarkD: One concern, going back to Async Release discussions - pulling stuff "out of trunk" was seen as a bad thing. Limitations to achieve that had to do with community/committer feedback (most wanted a centralized "Trunk"). How does this affect UI discussions? (May need to either pull some UIs out of trunk or make it easier to allow others to build & support their own third-party UIs outside of "trunk"). Note, "Trunk" is now "master" in GitHub
  • Andrea: Concerns about too large of changes. Don't want to scare off less technical folks, but want to also keep technical folks interested. 3.0 doesn't need to be any bigger than 1.7->1.8. Some things may be difficult to do gradually.
  • If new releases have clear features/functionality, that helps convince people to upgrade to more recent versions. (Andrea)
  • Upgrade interests are definitely driven by feature sets. (MarkD)
  • Incremental Development works best for us (RobinT) - only exception is possibly Manakin. But, we could have multiple approaches at once (some folks working on architecture reworking, while others do incremental work in 3.0)
  • Need to adopt a longer view (3.0 obviously won't be perfect and cannot do everything at once). Need to stick to timed releases - Andrea
  • A large rearchitecting project may not be "shiny" enough yet for others organizations to contribute to - MarkD
  • Could potentially leverage Spring more to not be "bound" to specific UI technologies - MarkD
  • We all admit there's stuff in DSpace that "gets in the way" of evolution at times
  • We need to support the building of interfaces, but need not support all interfaces ourselves (at least not centrally) - MarkW
  • Throw out "parity" across UIs? Just support "parity" at a Java level (Business Logic) / REST API? - Peter
  • Alternative UIs should go on GitHub, so we can all pitch in as we need & want (MarkW)
  • Richard's work towards re-architecting DSpace is all in GitHub in his "MDS" project. https://github.com/richardrodgers/mdsImage Removed
  • MarkD : likewise @mire's work on Metadata on all objects is in GitHub as well. https://github.com/DSpace/DSpace/pull/11Image Removed12
  • Tim points at Business Logic / REST API really needing some stabilizing & support if we really want to support others building new UIs
  • Tim wonders out-loud if we can have rearchitecture & new feature work going on simultaneously if we can all agree on a "middle layer" (likely REST API or Java Business Logic). I.e. if we decide that everything needs to "bubble up" via REST API, then rearchitecting could happen under that (as long as it doesn't break other main UIs)
  • MarkW - we can "break stuff" in terms of API compatibility, if we want in 3.0. But, we just don't want it to be difficult to upgrade to.
  • Some discussion in the end on how we want to use GitHub & Pull Requests. Tim mentions a thread on dspace-devel: http://www.mail-archive.com/dspace-devel@lists.sourceforge.net/msg08702.htmlImage Removed
  • Questions on our new GitHub workflow.
    • Still want to be tracking things via JIRA (as JIRA is our "history" of what changed in DSpace in each version).
    • We may need to play around more with Pull Requests and see what "works for us". Worst that can happen is that we need to roll back mistakes in GitHub
    • TIM TODO: Also want to ask Fedora/Hydra folks how they manage JIRA + GitHub. What does their workflow look like, and are GitHub changes/commits/pull-requests auto tracked in JIRA?

...