Top-level package names, UX questions

Gustavo Niemeyer gustavo.niemeyer at
Mon Mar 16 19:09:54 UTC 2015

I would again suggest just an alias: apache resolves to apache.guy, or to
apache.tribe, or to apache.canonical (ignoring the syntax, which I'd still
prefer to change).

If the best option changes over time, the alias simply points to something
else. There's no convoluted scheme to migrate from one option to the next,
and no intrinsic conflicts.

Am I missing something with that proposal?

On Mon, Mar 16, 2015 at 4:02 PM, Martin Albisetti <
martin.albisetti at> wrote:

> On Mon, Mar 16, 2015 at 3:22 PM, Gustavo Niemeyer
> <gustavo.niemeyer at> wrote:
> > I wasn't part of the original conversation, but it sounds like this
> would be
> > equivalent to having a single global namespace, except we are allowed to
> > override anybody else's names at will, which is unfriendly. In other
> words,
> > when we add a package X, we put any existing applications previously
> named X
> > in trouble.
> >
> > Whatever scheme we choose, at the end people should be able to pick an
> > identifier without being concerned about future unintended conflicts.
> Agreed, we shouldn't force you to understand the consequences of you
> picking a name. That, I think, is one of the main drivers for
> developer-keyed names. There's no collisions.
> The main subject here is how to implement the promotion from
> developer-keyed to top-level, which is a manual recognition that you
> are the best person to care for that particular piece of software with
> that name.
> --
> Martin

gustavo @
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the snappy-devel mailing list