Contribute to the DSpace Development Fund
The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.
Table of Contents
Meeting Schedule and Attendance
DSpace Developer meetings are a time when Committers and interested Developers can discuss new software features, upcoming releases of DSpace software, and generally plan out the roadmap of DSpace. All meetings are public. We welcome anyone and everyone to attend, speak their opinions or just listen in on the discussions. Please note that we archive all discussions (see Meeting Archives), as a service for those who are unable to attend.
DSpace Developer meetings take place on the following schedule:
- Every Wednesday at 20:00 UTC/GMT in #duraspace IRC channel
- All meetings are held for 1 hour (although, admittedly, discussion sometimes extends beyond that)
See the world clock to determine the meeting time where you live.
Meeting topics often include:
- Recent updates on upcoming DSpace releases, bug fixes or features
- Reviewing of recent reported issues/bugs/feature requests (see JIRA Cleanup Sessions for more info)
- Occasionally we vote or make decisions on upcoming DSpace technology plans/roadmap (see Developer Voting Procedures for more info)
If you are unable to attend a meeting, please feel free to add your own notes/comments to the meeting's wiki page.
Developers Meeting on Weds, September 1, 2010
Agenda
- JIRA Catch-Up (for first 20 mins or so of meeting) – starting with issue DS-588
- DSpace 1.7 Features/Updates
- Unclaimed 1.7 Issues/Potential Features in JIRA
- Documentation now on Wiki at: DSpace Documentation
- Jeff Trimble is cleaning up with help from Bill Anderson of Georgia Tech. If you'd like to volunteer to help, contact Jeff.
- Only Committers & Official Doc Gardeners can edit this area. Anyone else can only add Comments to pages.
- General Plan for 1.7: Official Documentation will be these Wiki Docs, and we'll generate PDF from Wiki (rather than old DocBook).
- Potential Asynchronous Release Processes (for DSpace Discovery and possibly REST API)
- Proposal is to find an easy way to install DSpace addons (where 'addons' are separate Maven Projects, like REST or Discovery) after you've already installed out-of-the-box DSpace. This could allow DSpace to move into more of a "plugin" architecture – where initially you'd just install the base DSpace, and later you can install only the addons/plugins that you want.
- One Option for Async Releases via Maven:
- Mark Diggory had suggested potentially creating Maven Archetypes (templates) which can be used to assist in installation of these 'addons'. We could also create our own Maven Plugin for DSpace to allow us to easily call these archetypes.
- E.g. In the end, you could run
mvn dspace:install-discovery
to auto-create the[dspace]/dspace/modules/discovery/
directory and add its dependency the[dspace]/dspace/modules/pom.xml
(thus Maven would install 'Discovery' the next time you ranmvn package
). - The Maven "dspace:xxxxxxx" namespace would be reserved for only "official" addons which you could install on demand. (e.g. 'dspace:install-rest', 'dspace:install-discovery', 'dspace:install-lni', etc.).
- Background Information (for Async Release Process proposal)
- More info on Maven Archetypes:
- More info on Maven Plugins (like the "dspace:xxxxxx" example):
Meeting Notes
JIRA catchup, 1.7 updates (need volunteers!), Async Release Process Discussion
- JIRA catchup – last item reviewed was DS-605
- DSpace 1.7 updates
- Many unclaimed issues scheduled for 1.7. We need volunteers! If you are interested in one of these issues, please claim it in JIRA. If you are a committer & haven't volunteered to help with any issues yet, we'd appreciate it if you could help out (even with just a 1-2 issues).
- DSpace Documentation now on Wiki at: DSpace Documentation – Still being cleaned up, but all new Doc changes should be made on Wiki.
- Discussion of Async Release Processes
- Two main goals:
- Goal 1: to be able to depend on dspace-api independent of official release distro
- So that dspace-api-1.0.0 <--- addon-1.0.1 <--- dspace-release-1.7.0
- We are most interested in "deploy time" integration (although compile-time & assembly-time integration could also be nice)
- Goal 2: needs to avoid extra complexity – must simplify install/upgrades and NOT make them more difficult than they already are.
- Goal 1: to be able to depend on dspace-api independent of official release distro
- Mark D's suggested approach
- 1.) not moving the code out of trunk
- 2.) just changing maven version numbering strategy
- 3.) releasing modules into same location as... http://scm.dspace.org/svn/repo/dspace/tags/
- this would mean there would be....
- http://scm.dspace.org/svn/repo/dspace/tags/dspace-api-1.x.x
- http://scm.dspace.org/svn/repo/dspace/tags/dspace-xmlui-1.x.x
- etc...
- Mark has started prototyping this idea in SVN Sandbox at: http://scm.dspace.org/svn/repo/sandbox/dspace-async-prototype/
- Two main goals:
Meeting Transcript
- Full IRC Transcript available at - http://www.duraspace.org/irclogs/index.php?date=2010-09-01
Meeting Archives
Notes and Transcripts from all recent Developers Meetings are available off of the Developer Meeting Archives page.