On Wed, 2014-01-29 at 17:47 +0100, Łukasz Stelmach wrote:
> Hi,
>
> Thanks to Patrick Ohly we've got a place to improve definition of the
> Tizen Domains
>
> https://wiki.tizen.org/wiki/Tizen_Platform_Architecture_Overview
For those who were not involved, this was motivated by an attempt from
Łukasz to move some packages (vim [1] and less [2], for example) out of
the "Social & Content" into a more suitable domain. Without a definition
of the domains, "suitable" is basically undefined.
In the case of vim, it is a tool to manipulate "Content", so one could
argue that it belongs to "Social & Content". Clearly someone must have
thought so, otherwise it wouldn't be there today.
My own understanding of "Social & Content" is more narrow, so as one of
the domain architects of that domain I am in favor of removing packages
from it.
If there is no dedicated maintainer for a package (which should never be
the case, but currently still is true for many), ultimately the domain
architect becomes responsible for ensuring that a package is kept in
good health (my interpretation of the "Must monitor the overall health
and progress of Tizen" line item in [3]; clearly that applies in
particular to the domain that he or she knows best). In that sense,
Tizen domains are not just architectural concepts, but also distribute
responsibilities and thus work. Therefore domain architects should get
veto rights before having a package added to their domain without there
knowledge.
There is no documented processes for moving packages, so we need to come
up with one in addition to defining what domains really are. My proposal
is the following (first described in [4]):
* check out
https://review.tizen.org/gerrit/#/admin/projects/scm/meta/git
* modify the git-trees file
* submit patch to Gerrit
* get approval from affected domain owners
* once merged, Sasha's scripts will update Gerrit permissions
Note that we still need confirmation from Sasha whether that is
technically possible; see also [5].
In addition, in particular for packages which might be controversial, it
might be a good idea to announce the change request here on the list, to
avoid the situation where a project gets moved from A to B while others
would propose C if they knew about the proposed change.
For creating new packages, there is a process based on filing "Package
Request" issue for the "Tizen Infrastructure" project in Jira [6]. As
Tracy pointed out, domain architect approval was not part of that
process and packages were often added rather arbitrarily to domains. She
suggested to require an explicit acknowledgment from the affected
architect in the Jira issue before completing the request [7]. I agree
that this would be useful.
Any other thoughts on these topics?
[1] https://bugs.tizen.org/jira/browse/TINF-446
[2] https://bugs.tizen.org/jira/browse/TINF-427
[3] https://wiki.tizen.org/wiki/Tizen_Governance#Architect
[4]
https://bugs.tizen.org/jira/browse/TINF-446?focusedCommentId=29850&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-29850
[5] https://lists.tizen.org/pipermail/dev/2013-December/001141.html
[6] https://bugs.tizen.org/jira/browse/TINF
[7]
https://bugs.tizen.org/jira/browse/TINF-446?focusedCommentId=29896&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-29896
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
