Versions Compared

Old Version 9

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version Current

changes.mady.by.user Tim Donohue

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

  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 (see 2012-05 Reflections & Brainstorms) 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 .& help them release Cocoon 3
    • 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?

Tim's 3.0 Discussion Summary:

  1. There are some concerns about the long-term 'viability' of Cocoon (which XMLUI is based on). It has served us well, but it doesn't seem to be as supported as it once was. This makes us all wonder if it's time to encourage new UI development or if we want to take a more active role in Cocoon's future. (NOTE: Currently nothing specific is in the works, though we do have several recent UI projects in: WebMVC and SkylightUI.)
  2. Sounds like most of us prefer the "gradual evolution" model that we've had with DSpace, as it lets us stick to our release schedules easier. So, 3.0 should be a gradual evolution from 1.8, just like 1.8 was a gradual evolution from 1.7.
    • That being said, we can and should make DB changes or API changes as needed to support that evolution
  3. Sounds like none of us are against others starting to do re-architecture work with DSpace. However, there are obviously concerns that the work needs to be done openly so that we get buy-in from all. This work could happen parallel to 3.0.
  4. We still need more discussions on what exactly will be in 3.0.
    • These should happen via email lists (dspace-devel).
    • We should all start to add our brainstorms in there. All brainstorms welcome – no need to have a full-fledged proposal.
    • Next week we can discuss this more via IRC

Action Items

Action items coming out of this meeting go here, if any.

...