Fw: Assessment of Allura at SourceForge

[Trevor]

Hi Federico

I've fished the mail below out of my archive. It shows the assessment I 
made of Allura before starting the migration. You might find this useful 
as a set of points to consider.

I was amazed to find I carried out this migration as a temporary 
stop-gap to avoid losing all our database in the summer of 2015 - almost 
5 years ago - when Google dropped their !

In spite of the good match it still took me almost three months of quite 
hard work to bring the migration to a successful conclusion. The main 
problem was getting a reliable and complete migration of all the data - 
including correct numbering, full text of comments, contributor names, 
and images (particularly tricky). Because the data transfer took many 
hours it frequently broke before completing. I needed the help of the 
Allura devs several times to overcome various problems. They were 
particularly responsive and helpful.

Let me know if you'd like any more info.

Trevor

------ Forwarded Message ------
From: "Trevor Daniels" <address@hidden>
To: "Lily-Devel List" <address@hidden>
Sent: 17/05/2015 09:33:32
Subject: Assessment of Allura at SourceForge

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) address@hidden

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