Hello,
After reading what Martin, Kamil and Tim wrote in the thread earlier, it
seems to me that we are trying to make task namespaces address several
features at once.
Task are trying to address:
1/ Ownership documentation. That is, telling who a task "belongs" to.
2/ Access control. Who should be able to write result into which
namespace of the resultsdb data base.
3/ Conceptual categorization. That is, tasks that seem to belong
"together" because they share some common conceptual properties.
For instance, tasks that are meant to (in the future) block a
release if they don't pass.
Note that this feature can be "used" to implement feature 1/ and 2/
above. That is, if we say:
all tasks named fas.ksinny.something belong to Sinny
we effectively documented that the task belongs to the FAS user
ksinny (so we addressed 1/) and we can enforce the fact that only
that task can write results into the fas.ksinny.* namespace of
resultsdb (so we addressed 2/).
Another important point mentioned by Kamil is that we expect the
Taskotron system in its entirety to be running hundreds of different
tasks that are designed, implemented and maintained by hundreds of
different Fedora contributors.
If we want to be able to manage that amount of taks, it seems to me that
we should use something else to address features ownership documentation
and access control. And use namespaces just for conceptual
categorization.
This would allow people to choose their namespaces to best suit their
categorization needs, whereas at the same time, the Fedora
Infrastructure people can *independently* apply tight and strict access
control to the relationship between tasks and the ResultsDB database.
Ownership documentation could also be provided independently.
An example.
------------------------>8<--------------------------------------- When
Sinny started to write her task, she could have called it
fas.ksinny.abicheck. She plays with it for a while. By default, of
course that task can only write into the fas.ksinny.abicheck.* ResultsDB
namespace. But that default can be changed by updating an entry in the
proverbial Fedora Task Access Control Service. There is also a separate
Fedora Task Ownership Documentation Service somewhere in the fedora
infrastructure that says that "this task is maintained by a set of one
FAS user and that FAS user is Sinny".
At some point, the task got noticed by some other people who want to
join and help improve it. The task get "moved" to another namespace:
"abisig.abicheck". An entry in the Fedora Task Ownership Documentation
service is updated to say that "abisig.abicheck is now maintained by a
set of 4 FAS users" and lists their user name. An entry in the Fedora
Task Access Control Service is updated to allow the task abisig.abicheck
to write not only into the abisig.abicheck namespace in ResultsDB, but
also to *keep* writing into the fas.ksinny.abicheck namespace so that
scripts that were expecting to get input from that namespace can keep
running until they are made to switch to consume the abisig.abicheck
namespace at some point.
Once her task becomes rock solid thanks to the input of the many parties
involved, the task gets moved into the "updates.blocking.abicheck"
namespace because that task is applied to bodhi updates, and blocks the
update if it doesn't pass. Its access control and documentation is
updated independently as well.
------------------------>8<---------------------------------------
In a nutshell, I believe namespacing is meant to name things and
categories of things. Once we know how to name things and categories of
things, other services can be used to apply, query, and work with
properties from those things and categories of things. And, inherently,
the naming is going to change in the life time of the task.
I understand that what I am proposing here involves (more) work and that
we are spread thin already, resource-wise. But even if we cannot have a
Task Ownership Documentation Service or a Task Access Control Service
right now, we should keep their concepts in mind.
And as we don't have those services ready right now, I believe we should
minimize the churn induced by changes of namespaces.
In light of that, I'd vote against trying to document ownership or
document the access control policy using namespaces because these are
going to change. I believe it'd be better to try to come up with a
generic-enough categorization that is less likely to change and yet
would convey, somewhat, the relevant common properties of the tasks
belonging into a given namespace.
So, no fas.ksinny.abicheck, please. I'd prefer qa.abicheck, even if
Sinny and I will (help) maintain the task, along with the fine Fedora QA
usual hackers, and *whoever* shows up armed with good will, a great
sense of humour and willingness to hack on ABI matters :-)
Once we start having more tasks we can create more categories depending
on the kind of check the task performs, whether it can block an update
or not, the kind of packages it applies to, etc. I guess the
discussions about the right naming scheme in that case would be the
subject of a dedicated thread.
Sorry for the long message and thank you for reading so far.
Cheers,
--
Dodji
_______________________________________________
qa-devel mailing list
qa-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org
