bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
Subject Re: First installation... my humble review
Date Tue, 12 Nov 2013 19:41:21 GMT
On Wed, Nov 6, 2013 at 10:06 AM, Olivier Mauras <olivier@core-hosting.net>wrote:

> Hello,
>

:)
Below you'll see my quick comments ... I'll fast forward to recent messages
in this thread .

[...]

>
> Here's a compilation of the points that i find "lacking":
>
> 1/ Blocking points for a production adoption - indeed that's only my
> opinion
>
>   * Product owner should automatically have admin rights to this product.
>

Unless I missed something or a regression has been introduced in /trunk
that's exactly the case . This is enforced by the multi-product permission
policy [1]_

  I plan on using Bloodhound in a multi product / multi users setup.
>   I can't imagine it working without delegating the product admin rights
> to their owners
>

Nevertheless there's a difference between Trac and product admin role . The
former are site admins , i.e. they have access to the file system , sudo
etc ... whereas the later only manage product resources e.g. tickets , wiki
, ... If you could list all the instances we fail at doing so we'll be
looking forward to improve them asap


>
>   * Products should be able to have their own source repo
>

they can ...


>   If rights are delegated, I don't see any valid reason for owners to not
> be able to add their own repos
>

... but yes , there is a reason and it's due to the Trac vs product admin
roles mentioned above . Trac repository connectors operate on repos cloned
in the local file systems (or equivalent ;) therefore adding a new one
happens outside the web site boundaries is more like a task of site admins
.

Of course , I see your point and you are right . The current implementation
has to be improved . Nonetheless AFAIK there are no interfaces in Trac
providing entry points for creating / forking new repos (which is a
backend-specific task ...)


> 2/ Confusing points
>
>   * Tickets tab being the dashboard
>   Being a new user, I find it really confusing for the "Tickets" tab for
> being the dashboard and consequently the only access to products list.
>   It would be way more intuitive - and faster - to keep the products list
> dropdown at the left of the breadcrumb.
>
>   * Not knowing where you are
>   This is indeed linked to the previous point, wiki and source pages don't
> show the product in breadcrumb
>

This depends ... in deployments based on sub-domains , there's no strong
reason to highlight an specific product context .That might be helpful
though .


>
> 3/ Eye candy
>
>   * Source browser CSS may not be the easiest to read
>   All lines to the same color make it difficult to catch things
>   Age color highlight is too light and/or too close in colors
>
>   * There's place on the mainnav tabs
>   As there's place available and that one can enable timeline and roadmap
> from base.ini why not add them to mainnav() to not have then in "More" tab?
>

They should also fit in screen for smartphones and tablets ...


>
> 4/ Graphic glitch
>
>   https://bh-demo1.apache.org/products/%40/roadmap
>   As you can see here milestone bars are not displaying correctly.
>

AFAICR the roadmap view has been phased out , cmiiw .

[...]

.. [1]
https://issues.apache.org/bloodhound/browser/trunk/bloodhound_multiproduct/multiproduct/perm.py#L47

-- 
Regards,

Olemis - @olemislc

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message