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
> > > 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
On Thu, 2 Jun 2016 07:46:33 -0400 (EDT)
Kamil Paral wrote:
> > 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-
> 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 s
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 wh
