Having a local bug tracker which follows the developer and all is nice, but not sufficient. It must be possible to easily provide a public, modifiable copy of the tracker for use by QA people, or users.
The single user UI is entirely too inefficient for this, but could perhaps be helped by running as a script under a real webserver.
There would have to be some sort of moderation when moving issues back to the primary VCS copy. Maybe a recommended setup would be to have a plain filesystem/VCS export version of the repository with the script/whatever Public UI running. Then every so often a person can run a synchronization/moderation script which gives simple choices to add the public change for a bug to the repo or not.
One possible way to do this would be to punt it off to the VCS. For many cases just looking at a diff and reverting anything which doesn't seem correct would cover many cases. This is likely what the initial tool will be like.
In the future it would be possible, but significant work, to present a moderation view where anything which isn't part of the issue repository is coloured and a list between modified issues. But this would only be done if some scripting around the VCS isn't sufficient.
It shouldn't be too hard to convert the web UI to run as a CGI script. The VCS type would have to be set to filesystem internally to avoid needing to call external commands. That would reduce the security impact. It's not like anybody would like the public changes committed to any repository automatically anyways. Even a DVCS where not all the changes end up in the canonical repository would be strained.
The static dump has worked quite well so far. So well, in fact, that the only issue I've come across is the inability to sort and filter. A fully sufficient readonly interface could be created with some javascript magic to make the filtering and field selection work correctly.
My first tactic was to take a static dump of all the possible index states and then modify the sort and filter button to run javascript to load the proper page. It turns out the combinatorial explosion means that just the page with the links to the indices is hundred of megabytes in size.
The only remaining serious issue for the public UI is that the sorting links don't actually dump correctly. This may have to do with their long length, over 300 characters with the default options.
I've fixed this by cutting out all the sorting and filtering options from the query string.
This works, but pushes offline saving of the filter and column settings to the issue f4a61e53
Having a local bug tracker which follows the developer and all is nice, but not sufficient. It must be possible to easily provide a public, modifiable copy of the tracker for use by QA people, or users. The single user UI is entirely too inefficient for this, but could perhaps be helped by running as a script under a real webserver.
Date: 2012-07-24 01:40:43
User: travisb
There would have to be some sort of moderation when moving issues back to the primary VCS copy. Maybe a recommended setup would be to have a plain filesystem/VCS export version of the repository with the script/whatever Public UI running. Then every so often a person can run a synchronization/moderation script which gives simple choices to add the public change for a bug to the repo or not.
Date: 2012-08-16 00:07:43
User: travisb
One possible way to do this would be to punt it off to the VCS. For many cases just looking at a diff and reverting anything which doesn't seem correct would cover many cases. This is likely what the initial tool will be like. In the future it would be possible, but significant work, to present a moderation view where anything which isn't part of the issue repository is coloured and a list between modified issues. But this would only be done if some scripting around the VCS isn't sufficient.
Date: 2012-08-16 00:11:13
User: travisb
It shouldn't be too hard to convert the web UI to run as a CGI script. The VCS type would have to be set to filesystem internally to avoid needing to call external commands. That would reduce the security impact. It's not like anybody would like the public changes committed to any repository automatically anyways. Even a DVCS where not all the changes end up in the canonical repository would be strained.
Date: 2013-02-16 06:33:15
User: travisb
The static dump has worked quite well so far. So well, in fact, that the only issue I've come across is the inability to sort and filter. A fully sufficient readonly interface could be created with some javascript magic to make the filtering and field selection work correctly.
Date: 2013-02-16 21:41:51
User: travisb
My first tactic was to take a static dump of all the possible index states and then modify the sort and filter button to run javascript to load the proper page. It turns out the combinatorial explosion means that just the page with the links to the indices is hundred of megabytes in size.
Date: 2013-02-27 22:12:56
User: travisb
I've added some javascript which allows the user to sort and filter the issue index. This seems to be sufficient for many public UI usecases.
Date: 2013-02-27 22:42:19
User: travisb
The only remaining serious issue for the public UI is that the sorting links don't actually dump correctly. This may have to do with their long length, over 300 characters with the default options.
Date: 2013-02-28 02:17:21
User: travisb
I've fixed this by cutting out all the sorting and filtering options from the query string. This works, but pushes offline saving of the filter and column settings to the issue
f4a61e53Tracked by Nitpick