> 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.". _______________________________________________ qa-devel mailing list qa-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org
