> == Namespace structure ==
> We'll be providing some top-level namespaces (list not yet final):
> * app
> * fedoraqa
> * package
> * scratch (?)
> These will the further split to facilitate for a finer level of
> granularity, e.g.:
I'm not sure if "func" and "unit" were meant as mandatory in the
original proposal, but I'd drop them. Let each package maintainer organize their tests
however they see it logical/useful. I don't see any benefit this separation would
bring for us. Is there?
My thought on namespaces would be something like:
test (or dev)
I like test/dev/scratch. I realized it could be useful for experimentation, we could for
example omit sending fedmsgs for these namespaces, and prune these results in resultsdb
more often, and yet people would be able to run something in an experimental mode
including seeing results in resultsdb. (Of course for basic task development, we should
recommend disabling resultsdb submission).
team and user are self explanatory; each package would be in the package
release would cover release-validation testing,
I'm not sure about "release", I see the same problem as with
"app", it's hard to decide what goes in there and what goes into
"team.qa" or elsewhere.
and test would be reserved
Ah, I understood test/dev differently. For taskotron testing, we run staging and
development instance with separate resultsdb instances. So I guess a namespace for this
purpose is not needed.
I'm thinking that we could do, for example:
Am I on the right track here, or just wandering in the weeds?
That's how I imagine it. In the beginning, it might be a wild west, but once we have
some permission model in place, I'd like to pre-define just a very small skeleton of
top-level namespace prefixes (pkg.<pkgname>, team.<teamname>,
user.<fasname>, etc) and let people do whatever they like with it.
Thanks for feedback, pirate.