My quick two cents... I like the idea of the Release Notes on the Wiki...and basically pulling together all the information about the release into that single location. However, in my opinion it'd be a little more user friendly (for people who are running DSpace) if we could do the following:
(1) Link to "Known Bugs" in a tracker system (like Claudia mentioned) (2) Links to individual bugs which were fixed in each version. So, rather than just listing "Fixes"...asking the committers to log a bug in the tracker system *first*. Then, fix it. Finally, provide a direct link from the Wiki Release Notes to the full description of the fixed bug in the tracker system. (3) Get rid of the SVN repo history...and just provide a list of new features added during that version. If we also can develop a process where all bugs get logged in the tracker system, then there should be no reason to see the ugliness of the SVN repo history :) But, in general, I definitely prefer this path to the old "KNOWN_BUGS" and "CHANGES" documents... - Tim Mark Diggory wrote: > Developers, > > I've reached a point where I cannot take the the thought of > continuing what I consider to be rather "Archaic" practices of > maintaining KNOWN_BUGS files in the "dspace" directory. I consider > these files as "always incomplete and out of date" information. They > introduce an overhead for developers contributing changes, commiters > processing them and for the release manager to verify all has been > documented properly in. To be honest, as a maintainer of a DSpace > instance and a developer, I never read these files, and instead > review the work done in the Tracker, WIKI and SVN logs. > > http://dspace.svn.sf.net/svnroot/dspace/branches/dspace-1_5_x/dspace/ > KNOWN_BUGS > > I would recommend a different approach for maintaining a more > accurate reference to the issues that have arisen since a DSpace > instance is released. And this would be to setup appropriate WIki > pages which can be edited by users to document new issue as they > arise both before and after a release has been cut. This will both > speed up the release process and provide a nice convention location > to track the issues and get appropriate feedback from our user-base. > > http://wiki.dspace.org/index.php/DSpace_Release_1.4.0_Notes > http://wiki.dspace.org/index.php/DSpace_Release_1.4.1_Notes > http://wiki.dspace.org/index.php/DSpace_Release_1.4.2_Notes > http://wiki.dspace.org/index.php/DSpace_Release_1.4.3_Notes > http://wiki.dspace.org/index.php/DSpace_Release_1.5.0_Notes > http://wiki.dspace.org/index.php/DSpace_Release_1.5.1_Notes > > It is my feeling that these URL's already provide an adequate jumping > point for discovering documentation on the KNOWN ISSUES in a DSpace > Version. Would there be any argument with adopting the usage of > these for documenting these details rather than static files in the > SVN repository? The Static README File could then point into these > pages and thus allow the users of DSpace to take up a post release > documentation effort > > It also seems these locations would be adequate for listing out the > CHANGES that have occurred, but I do like the process that listing > ones changes in the CHANGES file introduces into the community. > However, as the project grows and becomes more modular, listing > changes that may have happened in each separate component in one > centrally located file quickly becomes intractable. So I would > recommend either doing away with the practice, or coming up with a > better way to list out the work that commiters have done in a > particular project using separate CHANGES (Or possibly just WIKI > pages like identified above). > > What are the developers (and more explicitly the commiters) opinion > on this topic? > > Sincerely, > Mark Diggory > > ~~~~~~~~~~~~~ > Mark R. Diggory - DSpace Developer and Systems Manager > MIT Libraries, Systems and Technology Services > Massachusetts Institute of Technology > Home Page: http://purl.org/net/mdiggory/homepage > > > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Dspace-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-devel > -- Tim Donohue Research Programmer, Illinois Digital Environment for Access to Learning and Scholarship (IDEALS) University of Illinois at Urbana-Champaign [EMAIL PROTECTED] | (217) 333-4648 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
