All, During next week's DSpace Developer's meeting (Weds, March 10 at 20:00 UTC in #duraspace IRC), we will be having our first "Special Topics" meeting. The idea of a Special Topics meeting is to devote the entire hour towards a specific topic, often one requiring more detailed discussion.
Our first Special Topic Meeting will discuss our current DSpace Release Procedures/Cycle. For those who haven't been able to attend recent Developer meetings, you'll find more details in the "Background Information" at the bottom of this email. In preparation for this Special Topics meeting, I ask the following of each of you: (1) Before the meeting, take some time to read through the various proposals/ideas/brainstorms on how we could improve our Release Procedures. None of these are very long, and all contain some nice ideas. These are posted on the wiki at: http://wiki.dspace.org/index.php/Proposals#Release_Cycle.2FProcess_Proposals (2) Take some time to gather your own thoughts on each of these ideas. Feel free to write them up on the wiki (if you have time), or bring them to the meeting. If you are unable to attend the meeting, please add you comments to the Wiki (either at below one of the current proposals, or by writing up your own thoughts on a separate wiki page). During the meeting, we will be discussing these ideas in the order in which they are listed on the above Wiki page. Please let me know if you have any questions. *Background Information* DuraSpace (Valorie Hollister & Tim Donohue, with backing from Brad McLean & Michele Kimpton) would like to encourage the DSpace Community to take time after 1.6.0 to reanalyze our current release procedures, timelines, etc. It seems like it has been a while since we've done so, and I'm sure there is much we've all learned in recent releases (1.4.x, 1.5.x, 1.6.0) which we could work to "streamline" or take steps towards improving for the future. During recent DSpace Developers Meetings, I've encouraged all developers (committers and non-committers alike) to begin to brainstorm how our current development and release processes could be improved. There are already several brainstorms posted on our Wiki at this location: http://wiki.dspace.org/index.php/Proposals#Release_Cycle.2FProcess_Proposals (Side note: Feel free to add your own thoughts if you have time, or add comments to other's proposals/ideas. The initial Special Topics meeting will concentrate on the ideas listed on the Wiki -- so please post your ideas there if you'd like them discussed. Again, ideas from anyone are encouraged -- you don't have to be a recent release manager or even have been involved in recent releases.) Val and I see this review of our Release Cycle/Process as encompassing at least three phases: [Phase 1] First, ask all developers (committers and non-committers) to propose ideas/thoughts/brainstorms on how we could improve upon our current release process. The goal here is to first have those most familiar with release processes to brainstorm out potential "quick wins", which we could implement almost immediately as we start moving towards 1.7 and beyond. It's also a chance to let the developers to scope larger questions which may need to be asked to the community at large. (In addition, we don't want to delay 1.7 by waiting to move forward until this entire process has ended -- so, this gives us a chance to make some quick early decisions to start with for 1.7). [Phase 2] Second, broaden these ideas/questions out to the community-at-large (and especially to active repository managers in community), to receive input from non-developers on the release process. The goal here is to receive feedback from non-developers, and also see if there are ways that non-developers would like to be more involved with new releases. Valorie will help lead this phase of discussions. [Phase 3] Bring together ideas from all these discussions to develop a plan/proposal for moving forward. The final plan may be proposed by a smaller group (likely of both devs and non-devs), but will be open for comment and approved by the community-at-large. It's also highly likely that this plan may need to be implemented little-by-little, as the developers will have likely have already begun 1.7 planning/development by this point. We fully expect this entire process may be ongoing for a while. So, it will likely require some flexibility on our part as we start moving immediately towards a 1.7 release. In addition, none of us feel that any proposed changes need to happen overnight -- this is more an opportunity for us to all think about what we'd like to change and make small steps in that direction (potentially even small steps/improvements over several releases -- 1.7, 1.8, 1.9, etc.). Please let Val or I know if you have any comments, questions, concerns around this proposed process. Tim Donohue Technical Lead for DSpace Project DuraSpace.org ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
