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 < [email protected]> wrote: > On Mon, Mar 16, 2015 at 3:22 PM, Gustavo Niemeyer > <[email protected]> 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 @ http://niemeyer.net
-- snappy-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snappy-devel
