Hi all, imo the tracking of known bugs should not be done in the Wiki but rather kept in a tracker system (whatever will be the new one) out of which wiki pages might be populated.
This assumes that we do keep track of changes on it. There is a tendency to submit patches and fix especially small bugs on the fly, without submitting a new tracker or close an existing one. These changes are lost to most of the community. Thus folk running into the same problem or searching for a certain funtionality have not even the possiblity to find out about it. Maybe we'll find the time to have a go through the trackers and do a bit of cleanup. The average item age is not encouraging folk to submit new things. Have a nice day Claudia Mark Diggory schrieb: > 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 ------------------------------------------------------------------------- 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
