« Return to Thread: Project status
Re: Project status
by Vlad Skvortsov
::
Rate this Message:
Drew Myers wrote:
>I agree with Vlad in that whatever solution we develop, it definitely
>should not be dependent upon a single client interface.
>
>Ronny and I have spoken a bit via email about this topic. As an
>example, TortoiseSVN already handles some degree of issue tracking, when
>the issue tracking is done via a set of rules they've set forth. While
>TortoiseSVN is significant, and perhaps one of the most popular clients
>for Subversion, I still think Vlad is right...the issue tracking should
>not be limited to a single interface.
>
>However, I'm not sure that extends to administration of the
>issue-tracking system. If the administrative interface to 'subissue' is
>web-based, but various clients can interact via some issue-tracking API,
>with all the metadata stored within the subversion repository itself,
>then, to my mind, that's a clean solution. You may disagree.
>
>The 'administration' term usually means access restriction and control
for different groups of users. The only way to control access to data is
to direct it through single gateway that enforces policies established.
The 'administrative interface' in this case is the control interface for
such a gateway.
In my model data is distributed between different consumers (by the
means of svn) thus the only point of control is the repository itself
with its hooks. I believe that administrative settings (ACLs, user
roles, etc) should be kept in a repository as well and be enforced by
hooks dealing with the same repository. So if one needs, any number of
administrative interfaces could be built within the same model: those
will access data in the same repository (provided having enough
permissions, enforced by repository hooks).
So, may be what I thought of doesn't fit into others' mode of operation
regarding the business logic of issue tracking system. My focus is
currently on small groups (because my group needs that) that can just
hack administrative settings with 'vi' and do not need any
administrative interfaces *for now*. This is according to the general
engineering philosophy that I stick with: "Build something small that
works, then try to scale."
Anyway, it seems that the project founder wants to get back to Subissue
some time in the future, so there are too many cooks in the kitchen,
probably...
>If you haven't seen the spec the TSVN guys have laid out, here's a link:
>http://tortoisesvn.sourceforge.net/docs/release/TortoiseSVN_en/ch05s24.html
>
>If nothing else, perhaps this will give us some solid grist for the mill
>:).
>
>
>drew
>
>
--
Vlad Skvortsov, vss@..., vss@...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
>I agree with Vlad in that whatever solution we develop, it definitely
>should not be dependent upon a single client interface.
>
>Ronny and I have spoken a bit via email about this topic. As an
>example, TortoiseSVN already handles some degree of issue tracking, when
>the issue tracking is done via a set of rules they've set forth. While
>TortoiseSVN is significant, and perhaps one of the most popular clients
>for Subversion, I still think Vlad is right...the issue tracking should
>not be limited to a single interface.
>
>However, I'm not sure that extends to administration of the
>issue-tracking system. If the administrative interface to 'subissue' is
>web-based, but various clients can interact via some issue-tracking API,
>with all the metadata stored within the subversion repository itself,
>then, to my mind, that's a clean solution. You may disagree.
>
>
for different groups of users. The only way to control access to data is
to direct it through single gateway that enforces policies established.
The 'administrative interface' in this case is the control interface for
such a gateway.
In my model data is distributed between different consumers (by the
means of svn) thus the only point of control is the repository itself
with its hooks. I believe that administrative settings (ACLs, user
roles, etc) should be kept in a repository as well and be enforced by
hooks dealing with the same repository. So if one needs, any number of
administrative interfaces could be built within the same model: those
will access data in the same repository (provided having enough
permissions, enforced by repository hooks).
So, may be what I thought of doesn't fit into others' mode of operation
regarding the business logic of issue tracking system. My focus is
currently on small groups (because my group needs that) that can just
hack administrative settings with 'vi' and do not need any
administrative interfaces *for now*. This is according to the general
engineering philosophy that I stick with: "Build something small that
works, then try to scale."
Anyway, it seems that the project founder wants to get back to Subissue
some time in the future, so there are too many cooks in the kitchen,
probably...
>If you haven't seen the spec the TSVN guys have laid out, here's a link:
>http://tortoisesvn.sourceforge.net/docs/release/TortoiseSVN_en/ch05s24.html
>
>If nothing else, perhaps this will give us some solid grist for the mill
>:).
>
>
>drew
>
>
--
Vlad Skvortsov, vss@..., vss@...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
« Return to Thread: Project status
| Free embeddable forum powered by Nabble | Forum Help |
