Hi I've now completed my assessment of Allura at SourceForge against the list of requirements supplied by Phil. A point-by-point comparison is shown below. My conclusion is that Allura at SourceForge is suitable for hosting our Issues DB.
There are some differences from GoogleCode, but these are relatively minor and can be accommodated by small changes in our procedures. In particular the Blocking and Duplicate facilities will be different, and the various posts in the discussion are fully threaded and so are not numbered, meaning cross-referencing is by link rather than number. The emails sent out following additions and amendments are not formatted as nicely as those from GoogleCode, but contain all the information. Support is by +ve and -ve voting rather than starring. Finally, the Owner field in the transferred tickets is not populated. The owner is identified in the text of the ticket, so the field can be manually amended after the event in the few tickets where this matters. Other than that the facilities are remarkably similar, and apart from congestion the transfer of the DB is fairly trouble-free. I'm in the process of tailoring a test facility for developers and admin to play with, and as a vehicle for re-engineering git-cl and patchy. I'll post again when this is ready. Here's the point-by-point comparison: > 1. Allow creation of a new sequentially numbered issue, with > text describing the issue's title and details Available as standard. > 2. Allow tagging the issue with a range of types > (e.g. Type-Critical = Defect which blocks a stable release, > Type-Maintainability = Hinders future development) Available by creating a new custom field Type, with a list of permitted values. > 3. Allow tagging the issue with life-cycle stages > (e.g. Accepted, started, fixed) This is the Status field. Available as standard. > 4. Allow tagging issues with patch status Available by creating a new custom field: Patch, with list of permitted values. Note that existing values are not capitalised, unlike values of the Type field, so need to continue with this as searches are case-sensitive. Search name is "_patch". (All field names in searches are lower-case only, and custom field names start with an underscore.) > 5. Allow display of issues at different lifecycle stages > (issues open, issues to be verified, all issues) Comprehensive searching possible, eg "labels:2_19_19 AND status:Fixed" also custom buttons can be created for commonly required searches. > 6. Allow display of issues of different types > (e.g. Critical, Documentation, .) Possible after creating new field called Type. Search name is "_type". eg "_type:Documentation AND !status:Fixed" > 7. Allow image attachment and display Available as standard. > 8. Allow non-image attachments Available as standard. > 9. Prevent non-registered users from adding issues Available as standard. Separate permissions may be set for: Admin Configure Create tickets Delete tickets Moderate comments Post comments (subject to moderation) Post comments (without moderation) View Tickets Edit Tickets Permissions are set per group: Admin Developer Member Authenticated Anonymous Additional groups can be created. so Create tickets (etc) could be restricted to Admin and Developers It would be possible to have a second set of tickets which could be available to anyone. Tickets can be selected and moved between trackers or even projects. > 10. Allow registered admins to add users Available as standard. Users must have a SourceForge account. > 11. Allow users to add comments to existing issues Controlled by permissions. See 9. above. Might be best restricted to Authenticated users (any logged-in user). > 12. Provide an API to allow patchy to find issues with new patches, > to detect the URL with the Rietveld link and to update the patch status > once the patch is tested. An API is available which seems to have all the facilities required. > 13. Provide an API for git-cl to allow automatic creation of issues > to track patches. An API is available which seems to have all the facilities required. > 14. Allow export of the issue database in CSV form Actually GoogleCode (and Allura) export the text part of the DB as a JSON file, with urls pointing to the attachments so these can be located and exported by a script at a later time. The GoogleCode CSV export just exports the index (i.e. no text) which is singularly useless for backup and transfer. So this requirement might be better written as: > 14. Allow export of the issue database as a zipped JSON file containing all > the index variables and discussion text, together with a means of accessing > all attachments so these may be re-associated correctly with the relevant > text. Available as standard, together with import. This is a way, albeit rather extravagant, of modifying any field in the DB, even those not available for editing in the usual way, such as the author field. > 15. Allow issues to be closed as duplicates Issues can be given a status of Duplicate, which closes them, and the primary issue of which this is a duplicate can be indicated in the text of a message as a clickable reference: "Duplicate of [#nnnn]". Can't see a way to include a clickable ref in the index. (See 16 for alternative way using Labels) > 16. Allow issues to be blocked by other issues Seems to be no way to provide these fields. One approach would be to add labels manually: "Blocking 1435" and "Blocked-by 1922". Although these are not clickable in the index they are visible and it is easy to transfer either number to the search box, and both issues are then found. Alternatively add a message, which can contain a clickable reference. (See 15) > 17. Email updates to (preferably) lilypond-a...@gnu.org Available as standard. > 18. Allow users to watch an issue and be informed of updates by email Any user who comments or votes on an issue is automatically informed of further changes to that issue. Trevor _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
