bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olivier Mauras <oliv...@mauras.ch>
Subject Re: First installation... my humble review
Date Thu, 14 Nov 2013 07:04:47 GMT

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/13/2013 09:13 PM, Olemis Lang wrote:
>
> A final precision on this subject ...
>
> On Wed, Nov 13, 2013 at 3:08 PM, Olemis Lang <olemis@gmail.com
<mailto:olemis@gmail.com>> wrote:
>
>
>
>     On Wed, Nov 13, 2013 at 3:44 AM, Olivier Mauras <olivier@mauras.ch
<mailto:olivier@mauras.ch>> wrote:
>
>         On 2013-11-12 21:41, Olemis Lang wrote:
>
>             
>
> [...]
>
>
>         ... 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
>
>         I don't think this matters much. Even if the product owner
doesn't have access to filesystem this shouldn't prevent him to enter a
path given to him by the "bloodhound server admin"
>
>
>     I do think this matters . I'm not very fond of publishing server
paths (... neither do the admins in my team ;). By establishing a
convention (e.g. /opt/vcs/<vcs_type>/<repos_name> where vcs_type = hg |
svn | git ... ). The product admin wouldn't even need to worry about
server-side filesystem paths ; they'll only need to know the vcs type
and repos name . That's just an example ...
>
>
> This should not be interpreted as a limitation of Bloodhound core but
the lack of a repository provider providing support for such a FS layout ...
> 
>
>
>     In any case the current implementation still implies that only
TRAC_ADMIN users may create new repositories, and always outside web UI
. IMO it would be nice to integrate those operations too in forthcoming
releases for an enhanced user experience . Nonetheless in order to do so
new (or enhanced) entry points will be needed .
>
>
> ... as opposite to this , which requires an upgrade .
>
> --
> Regards,
>
> Olemis - @olemislc
>
I thought about all this. To be less intrusive and still support the way
BH was intended to, how about:
- - Keep the repository creation on global admin side
- - Add option in repository admin page to enable it or not for a given
product - Could be enabled for more than one repository
- - Product would see only its enabled repositories

This would make much less modifications to BH core. How does that sound?


Olivier
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJShHYPAAoJEJXQwVHPrdN8NKoP/33cIkTw550QdvldTpAZy7eX
UNOimeK1n2RNRggWpZZ/jN5MDXbRq3nhdMgw7d3Cc/TfJmZa/L+mNk+VFdM9YQz3
i6o3MSaLeDIBMZ7MgbNJWdzk8mpwQDw1oIKhsHXsc8nH05sybY0F//qjt6rgQjbP
+emHzNJOhBUcTJn+5pq+IACYffV/TFBuBa12sW9TcMc4t44mxWn4nC7qvYeTQu2V
9+E14eQH+zKVXSb39yx/gE0RMBS+ugC1OmZ7JL4JdkxztOmDfb4ZSMWohzd9gN1/
Ax4T+W0Otxq/JfN2Aelk5nzVAkf7bBp4b1HVH93HupQAd6dlFkrFEgzBI6S9/p19
IygjwmWrLpros+YeKwWyTtfKWhfsfhzwyOACe6EKz+V/XEUyiJ0lWs7nV3TVFhq3
nFwF4DLtDcynVv5+2xzBrNPlvyNKICVF9YqV2RuH3boqpfXy0K8L3uhDQB6Lo1qt
eaDMO1QKh9zQCNv/8K9+018OXggJtv/PcQW9/Lz2i44402QH4Tc7xWt7FQCA7Mh1
dmwnlBX3e083YJAIajdp0dwHtx7KI8aP8mse5e6u44aD3MmcaFPkS9sNKZeAt0sv
9tCUdqUkACCz2ATN1OIgt+TN5dRz0QKgOgEm35buFIqrMeh/xleW+Quf5STPufuW
WuO/e54IomJ0MYPZhF2u
=ypqy
-----END PGP SIGNATURE-----


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