Date: Tue, 19 Mar 2024 06:57:30 -0400 (EDT)
Message-ID: <337027516.9035.1710845850127@lyrasis1-roc-mp1>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_9034_854794109.1710845850127"
------=_Part_9034_854794109.1710845850127
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
Join via S=
kype + IRC backchannel
- When: This call will begin at 20:00UTC (the same time =
as our weekly DSpace Developers Meeting). We will try to keep discussion to=
one hour.
- Where:
- Call in via Skype or Phone line - See #Connection Instructions below
- In addition, #duraspace IRC will be utilized as a discussion "backchan=
nel" =E2=80=93 to share links to current discussion topics/ideas, and poten=
tially even take notes.
Connection Inst=
ructions
You can call in via either Skype or via your Phone. This call wi=
ll be audio-only. We will also use the #duraspace IRC as a discus=
sion "backchannel" (to share links, etc.)
Via Phone:
- Dial-in Number: (805) 399-1200=20
- Participant Code: 929807#
Via Skype:
- Search and Add Contact: "freeconferencecallhd.8053991200"=20
- Copy and paste freeconferencecallhd.8053991200 (the entire name) into y=
our contact search area
- add as a contact
- After freeconferencecallhd.8053991200 is listed in your contact list, s=
imply call that contact.
- Enter the participant code through the Skype keypad (not by just typing=
in the numbers on your keyboard): 929807# (you will prompted to add the # =
sign).=20
- Mac Users: The Skype Keypad can be found at the top of your call window=
(look for the little phone keypad icon).
- Windows Users: The Skype Keypad is unfortunately hidden under the
Call -> Show Dial Pad
menu
- Linux Users: The Skype Keypad can be found at the bottom of your call w=
indow (look for the little phone keypad icon).
More info on Skype connections also available at: http://www.freeconferencecallhd.com/skypeinstructions.html=
a>
Agen=
da - 3.0 Discussion & Planning
Discussion Topics
- 3.0 Release Pl=
anning=20
- Brainstorming out new features or design for 3.0, timeline/schedule, et=
c.
Potential 3.0 Features/Discussions?
- Brainstorming Features/Changes for 3.0. Can we work towards development=
teams around any of these projects?=20
- Larger DSpace projects which seem to have a lot of recent support:=20
- Moving towards a Common "Business Logic" / Business Services API. (I.e.=
avoiding duplication of business logic in all UIs)
- Metadata For All (i.e.=
metadata on all objects), SubTopic: Getting us up-to-date how we use Dubli=
n Core / DCMI. (Support from DCAT)=20
- Various features from the Dryad Project (based on DSpace)=
? May or may not include the following.=20
- UMICH and @Mire Advanced Embargo Support
- Other DSpace projects receiving mention recently=20
- Migrate Search and Browse to DSpace Discovery
- "Change which UIs come out-of-the-box" (and which are optionally instal=
led later)
- Move configurations to DB or similar (so they can be managed/edited fr=
om Admin UI)
- Context Guided Ingest (or I=
tem Type based submissions)
- Other Development Pro=
posals
Meeting Notes
These notes are what Tim was able to "glean" from the interestin=
g conversation. Please feel free to enhance or correct any mistakes as you =
see fit.
- Main Topic: 3.0 Release. We have a very preliminary schedule up at DSpace Release 3.0 Notes=
a>
- Richard sent some brainstorms to Committers (see 2012-05 Reflections & Brainstorms) a=
round whether we want to do any radical/significant re-architecting of DSpa=
ce for 3.0 (or start any work in parallel to 3.0). Tim attempts to summariz=
e them (likely badly).
- Some concerns that Cocoon (technology under XMLUI) is not very well sup=
ported anymore. Do we need to look towards a new UI? Is XMLUI work sustaina=
ble if the technology underneath isn't really moving forward?=20
- 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 supp=
ort of XMLUI. XMLUI will continue to be supported fully in 3.0. This is mor=
e 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 Proto=
type process & the DAO Prototype (before 1.6).
- Any larger re-architecting would need to involve more committers (canno=
t 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 e=
verything all at once. (Sands)
- MarkD wants more info on suggested "radical re-architecting" changes fr=
om Richard
- Richard explains thought processes behind larger changes like Metadata =
on All Objects (high priority feature, which may require large changes)=20
- Metadata on All Objects would require large scale changes in DB/API, an=
d 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 X=
MLUI? Especially if we are already wondering if ongoing Cocoon support is q=
uestionable.
- Does Admin UI even need to be the same as the main browsing/searching U=
I? (Mark Wood) Could we scope any project so that it just deals with part of the UI.
- WebMVC project does this / same with XMLUI =E2=80=93 several not neithe=
r were "feature complete" at the initial time of release.
- Do we really want to be deciding on or supporting multiple interfaces c=
entrally (as a Committers team), or do we want to concentrate more on "busi=
ness 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? =E2=80=93=
i.e. put more work into WebMVC (Robin) or =
SkylightUI (Tim)
- MarkD: One concern, going back to Async Release discussions - pulling s=
tuff "out of trunk" was seen as a bad thing. Limitations to achieve that ha=
d 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 le=
ss technical folks, but want to also keep technical folks interested. 3.0 d=
oesn'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 folk=
s 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 evolutio=
n 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 (B=
usiness 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/mds
- MarkD : likewise @mire's work on Metadata on all objects is in GitHub a=
s well. https://github.com/DSpace/DSpace/pull/12
- 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 wo=
rk 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 t=
o "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 Requ=
ests. Tim mentions a thread on dspace-devel: http://www.mail-archive.com/dspace-devel@lists.sou=
rceforge.net/msg08702.html
- Questions on our new GitHub workflow.=20
- 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 Git=
Hub
- TIM TODO: Also want to ask Fedora/Hydra folks how they=
manage JIRA + GitHub. What does their workflow look like, and are GitHub c=
hanges/commits/pull-requests auto tracked in JIRA?
Tim's 3.0 Discussion Summary:
- There are some concerns about the long-term 'viability' of Cocoon (whic=
h XMLUI is based on). It has served us well, but it doesn't seem to be as s=
upported 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 fu=
ture. (NOTE: Currently nothing specific is in the works, though we do have =
several recent UI projects in: WebMVC and S=
kylightUI.)
- 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 evol=
ution from 1.7.=20
- That being said, we can and should make DB changes or API changes as ne=
eded to support that evolution
- Sounds like none of us are against others starting to do re-architectur=
e work with DSpace. However, there are obviously concerns that the work nee=
ds to be done openly so that we get buy-in from all. This work could happen=
parallel to 3.0.
- We still need more discussions on what exactly will be in 3.0.=20
- These should happen via email lists (dspace-devel).
- We should all start to add our brainstorms in there. A=
ll brainstorms welcome =E2=80=93 no need to have a full-fledged proposal.=
li>
- Next week we can discuss this more via IRC
Action Items
Action items coming out of this meeting go here, if any.
- TODO - Update the Relea=
seCoordinating page to better outline Release Processes=20
- Add "Update this document with lessons learned" as the final task of an=
y release.
------=_Part_9034_854794109.1710845850127--