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
