Top-level package names, UX questions

[Martin Albisetti]

Hi all!

We've kicked off the work to support top-level package names (eg
"apache" instead of "apache.beuno"), and plan to work on it in a few
iterations, each adding a bit of usefulness each time.
You may have seen there are already some apps that have this
("docker", "hello-world"), but those were implemented in a bit of a
rush to release and only work for Canonical applications. We would
like to open this up this option a bit more.
We care about keep the ecosystem safe and pleasant, so we'll ask that
top-level package names are reviewed manually the first time they are
requested. The final plan is for apps to be uploaded to the store
under their developer namespace (like PPAs work in Ubuntu today, to
some extent) and have those get established in the community as the
way to access that particular piece of software, and then essentially
graduate to a top-level name. More on that in the future, for now
we'll keep things nimble and just leave them flagged for manual review
the first time you upload.

Given how we see the path currently, it means packages will
essentially have, at least from the Store's point-of-view, both
namespaces equally accessible ("apache" and "apache.beuno").
In this first pass at the implementation, the quickest iteration to
allow proper usage is to not support transitions, but rather start by
supporting new packages that will use the top-level namespace from the
start.
With all that context in mind, I'd like to get some feedback on where
and how to specify the package namespace.
As I see it, we have 3 options:
1) It's not specified at all in the manifest file in the package, the
metadata for that is provided separately by the store all together
2) The package's manifest always contains the developer's package
namespace (apache.beuno), and the store provides the metadata
separately
3) The package's manifest contains the top-level namespace

The pieces affected by this decision are:
a) Path on disk (/apps/packagename)
b) How to execute binaries in the package (apache.start)
c) What the developer specifies (or has to remember to specify!) in the manifest

We had an internal discussion about this already, but didn't land on
any conclusions so I'm trying to summarise the discussion and the
problem well enough for a wider audience.

Option 1 is tempting, since it effectively allows package name
transitions with no need to change the packages themselves, but for
sideloading it's a bit awkwards as you have to provide both a package
and a piece of metadata separately.

Options 2 and 3 are similar enough, that I think it mostly comes down
to how it affects the pieces identified before. I wouldn't want you to
have been running "apache.beuno.start" for a year, and then suddenly
with an update it stops working because it gets upgraded to
"apache.start".

I don't have an opinion on the exact implementation on the client, I'm
happy for the store to provide the extra metadata payload separately,
however much amount of it and for it to parse any value out of the
manifest file.

I do care that we support the path from a developer namespace to a
top-level namespace in a seamless way for the user (ie. they don't
need to know about it at all).

Thoughts?

-- 
Martin