[Scummvm-devel] Pending Upgrade of Sourceforge Trackers to Allura...

[D G Turner]

On 19/04/13 19:58, Willem Jan Palenstijn wrote:
...
> Do any of you know of any issues remaining which would be blockers?
> 

The issues I and others identified previously are listed in the
scummvm-devel e-mail thread with subject line "Re: [Scummvm-devel] ATTN:
ScummVM sourceforge project update" sent to the list between
28/09/12 and 12/10/12. Some are probably fixed... but not all the
ones I indicated as you have listed some of them below.

> My personal list of annoyances includes:
> * paginated comments
> * attachments hard to find because they're hidden in (paginated...) comments
> * inefficient layout
> * lack of a search "filter"
> * clumsy/unpolished user interface in general
> * lack of data export/backup function
> 

I concur with these, especially the lack of the search filter, the
"hidden" attachments and the lack of data export/backup.

Of my comments, I haven't looked at an Allura tracker currently, but I
suspect these are still relevant:
<snip>
  6. The new tracker lacks a change history list per artifact/bug,
     which the old one had. This makes it hard to see what has been
     changed on a bug, when and by who.

     This is compounded as the new tracker also allows editable
     comments i.e. they are mutable, so this could lead to various
     annoyances of users removing useful information in error or
     modifying existing bugs in confusing ways.

    I would urge changing the admin settings to disable post-editing
    of comments and enabling a change log per bug if possible.

  7. A similar issue applies to the fact that attachments are now
     inlined as comments, rather than listed at the end, though
     this is less of an issue. Though the removal of attachments
     should probably be limited to creator and developer rights,
     as per the old tracker behaviour.
</snip>

Overall, my main requirement is that it must have the same or better
functionality compared to the current legacy tracker without causing
the user/bug submitter headaches in trying to use it i.e. it must either
be very similar to previous layout or be _very_ intuitive... which I am
not convinced the current user interface manages. :/

This also includes importing all the historical bug data for reference.

> 
> It remains an option to switch to a self-hosted Trac, but since data
> export from allura is problematic, that would have to be done pre-upgrade.
> The main disadvantages to such a step would be having to handle user
> management, abuse/spam and hosting ourselves, of course.

Personally, my "perfect" solution would be a decentralised bug tracking
database/system akin to or built on top of Git such that you could have
a copy of this data offline.

As there seems to be very few mature solutions for this, my "optimal"
solution would be either a self-hosted solution which we would have full
control over and thus could backup and export data from i.e. Trac or a
hosted solution like Allura, but where it is possible to backup/export
the database... as this would give us the advantage of offline copies
for those who want it, backups and the possibility of
migration.

One other option is that SF.net can now have hosted applications which I
think include Trac and similar, so we could use SF.net for hosting, but
have full admin access to the raw database in this way?

Anyway, overall, this is a decision for the Core Team to resolve.

> 
> 
> -Willem Jan
> 

Thanks,
David Turner