Hi,
we have deployed task result namespaces support a while ago and put
our checks (depcheck, upgradepath, rpmlint) into the 'qa' namespace.
With newly added tasks like task-abicheck and task-dockerautotest,
we weren't sure where to put them and so we used the scratch
namespace which is supposed to be used for testing purposes. Now
with those "3rd party" tasks deployed to production, we need to
decide what namespaces should they and other future tasks belong in.
The starting namespaces, and maintainers of tasks belonging to that
namespace, follows:
qa.* - Fedora QA
pkgs.<pkgname>.* - <pkgname> maintainers
fas.<username>.* - <username>
fasgroup.<groupname>.* - fas members belonging to <groupname>
scratch.* - anyone
Now, since we maintain task-dockerautotest, it should go into qa.*,
Agreed. Once we have dist-git checks implemented, we can ask docker maintainers to keep it
and maintain it in their repo. If they don't want, we can keep it in our domain (same
as anyone will be able to run any test against any package in their personal space).
I am not sure though where does task-abicheck belong. I see three
options here:
1. we can create fas group and put it there,
More on this below.
2. create additional dist.* namespace where tasks like abicheck
and/or rpmgrill would be, or
What is the use case for "dist."? Which tasks would go there and which would
not? Is this just about "scratch" not sounding that good?
3. change semantics of qa.* to 'anything Fedora QA maintains or
important, not package-specific, tasks".
Personally, I always considered our namespaces to have two functions:
1. show ownership - it's clear who owns qa.depcheck, or fas.ksinny.abicheck, or
group.workstation.gnome-startup
2. increase security and eliminate mistakes - by allowing certain people or groups to
write results only into their own namespace, we reduce attack vectors (random people
can't send fake results for qa.depcheck) and we eliminate mistakes (people will not
create a thousand test cases in "qa." by accident)
I didn't intend namespaces to reflect task importance in any way, e.g. to put all
gating tasks into "qa.". It sounds tempting, but it's likely to violate the
two functions mentioned above. For release critical tasks, it's possible that we will
take their ownership and maintain them, but I don't think it's going to happen for
all of them. I don't see a problem in Bodhi or some releng tools monitoring
qa.depcheck, qa.upgradepath and fas.ksinny.abicheck. It's all about trust, and the
exact testcase name doesn't matter. You can't trust a random person that he/she
will maintain the task and quickly fix all issues, but once you know who you're
dealing with and that he/she is willing and capable of doing that work, it doesn't
matter whether the namespace is "qa." or "fas.".
Of course there's the issue of people coming and going, and it would be nice to have
the testcase name changing as little as possible. For that reason, I imagine that really
important tasks will move to some group ownership, where people can maintain it and the
namespace doesn't need to change. Let's imagine "group.workstation" or
"group.dnf" (which can match fas groups, or be created manually, or both - the
implementation is up to discussion).
So, personally, what I would *not* do is to place task-abicheck into "qa."
namespace while having Dodji or Sinny still maintain it. That breaks the two primary rules
of namespaces (as I see it). We should either move it to "qa." and start
maintaining it ourselves, or put it into Sinny's/Dodji's personal namespace and
let them maintain it. This is nothing personal against Sinny or Dodji (you two are doing
great work), and it's not that I don't trust them, I'm using a concrete
example but trying to show the principle in general.
The only thing is that "fas." is not implemented yet and that's why it is in
"scratch." now. I don't see a problem with it, and we can move it once we
implement "fas.". Once abicheck proves to be useful and reliable (or before,
once we agree on what we really want), we can suggest them to come up with some
maintenance fas group so that the namespace doesn't need to change, in case they want
somebody else to take it over.
Of course you might have a different opinion on what the namespaces are useful for, and
what are their important a unimportant features. Please feel free to disagree with me and
present your views. I do not feel strongly about this, I was just trying to describe what
I currently see as the best (safest, least error-prone, least maintenance) way forward.
Thanks.
PS: There's one case where I can imagine we should do a different solution. If we
wanted to show abicheck results in Bodhi *asap* and were concerned about the risks of
displaying results from "scratch." namespace, then it would make sense to create
some separate temporary namespace, place abicheck into in (and set up permissions so that
it's not publicly accessible) and have it there until we implement "fas.".