codespeed
codespeed copied to clipboard
tobami
Multiple Project UI
Currently the front-end provides no way to select which project to view, which makes it hard to use as a multi-project service.
If this seems reasonable I'm willing to add the proposed changes below:
- Add a slug field to Project
- Move all URLs to be prefixed with the project slug
- Have / redirect if there's only one project (maybe controlled by a flag?) or display a list otherwise
There is actually working support for multiple projects, but it is admittedly not perfect. First, the changes and timeline view will only show results for projects marked as "track changes". If that is the case, its executables will all be shown in the left menu among executables of other projects.
The revisions select box is also completely integrated. If you select an executable from another project, you will see a brief glow over it. That means that it has reloaded itself with revisions corresponding to the newly selected project.
The timeline view is not as good integrated. All executables will be shown without regard for which project (marked with tracked changes!) they belong to.
The comparison view, allows to compare between all projects, even those which are not tracked.
I would propose something else (next message).
My solution would be to improve the current multi-project implementation by making it more complete and visible.
- All views should display executables in a per-project tree, exactly in the same manner as benchmarks in the comparison view are displayed in a units-separated tree (try it).
- Changes and comparison views would then be finished.
- Timeline: it should support multi-projects like the revisions select box from the Changes view. So different projects shouldn't be displayed in the same plot? grid for a single project?
What do you think?
That seems reasonable. My goal is to take something like what I've been setting up for Django trunk at http://djspeedcenter.djangy.com/timeline/ and start collecting data for other projects which I use such as django-haystack, django-tastypie, etc. The main goal is separation since there'd be no meaningful way to compare results from unrelated benchmarks.