Top-level package names, UX questions

[Mark Shuttleworth]

On 16/03/15 11:49, Martin Albisetti wrote:
> Indeed they do get easier. I think, though, it comes at the expense of
> being heavy-handed with how the ecosystem grows. There's a lot of
> first-come-first-serve for popular names, and makes it more common for
> renaming to have to happen down the like as competing apache's improve. 

I think this is OK.

Developers can claim whatever name they want, first come first served.

To INSTALL that package, I would need to say "I want that developers
package called <name>".

No unofficial, developer package could be installed accidentally,
because the only way to install one of those would be to name the
developer explicitly, like:

 snappy install foo --by beuno

The question is:

 * do I now have to refer to commands in that package as
foo.beuno.command, or
 * can I just say foo.command (I prefer this)

but that means that

 * if there is an "official" foo, I must choose between beuno's foo and
that one
 * because foo.command :)

I think the latter choice is reasonable to have to make.


>> I'm leaning towards saying that developer versions would conflict with
>> mainline versions - for a device, pick one or the other. I can't
>> recalled why we went the other way, now, in prior discussions.
> We can have both "apache" and "apache.beuno" co-installed, if we
> choose wisely how to implement this.
> There are 2 separate cases here, that we might be conflating.
>
> 1) "apache.beuno" exists, but is my take on apache, which might just
> be popular with a small, lets say exotic crowd
> 2) "apache.slangasek", which turns out to be stable and popular, and
> is promoted to "apache"
>
> How "apache.beuno" and "apache" co-exist, I think, is clear and
> understood.


Well, no. If you accept that you will be typing apache.beuno.command all
the time, then yes, but I don't think that's an experience we really
want, even if I said I was happy with that previously :)


>  The key question is how we handle the transition from
> "apache.slangasek" -> "apache" for folks who already have
> "apache.slangasek" installed, because it was popular in the first
> place.

That I wouldn't worry about, because apache.slangasek.command could
easily keep working.

But we should not be planning to ask people to type
apache.slangasek.command for ages in the first place!

I think it's OK to expect namespace use to converge. In other words,
it's good to allow and even encourage people to pick a name and go, but
to recognise that as a name gets popular, the packages using that name
should converge so that they are reasonable substitutes for one another,
for a given major version of Ubuntu.


> If the package manifest is changed from "apache.slangasek" -> "apache"
> when the "promotion" is approved, the question remains on how to
> handle that on disk. Do we rename it? Do we leave it alone?

Ideally, nothing changes at all on disk (except perhaps in a database
somewhere).

> If it isn't changed, how do we make sure the system knows about this
> promotion, allowing you to now access the package with the new, more
> convenient name?  A second entry in the manifest?  A separate piece of
> metadata from the store?

Well, this is where we differ. I think we should say that there is one
and only one apache package installable at a time. Sooner or later that
means people will need to make choices, and we're abile to facilitate
the social dynamics around that. I think building technical solutions
that avoid any social resolution just causes long term problems.


> Regardless of what we do, we need to make sure we don't break
> anybody's existing installation, so the package needs to continue to
> be accessed from its previous namespace, as well as the new one.

... in the course of the life of an LTS release, yes. On devel, and
between LTS releases, no, we can rename it.

> We could also say that you essentially have to upload a new package,
> that will have existed from the beginning as "apache", but you would
> loose your existing community of users, which is not ideal for either
> party.

Rather, lets say that users must choose, and that will force developers
to collaborate.

> Another option would be to leave you alone, and you remain unaware
> that it's now called "apache" as well, and only new installs get
> "apache". I fear that might confuse people too much, though.


> Given developers upload directly to the store, with no mediation, we
> can't easily guarantee that apache.beuno is the apache webserver and
> not a native-american history app, or that while of similar quality to
> "apache" mine has some experimental but incompatible changes to it,
> that some folks use for some things while using the known-stable
> "apache" for others..

For "official" packages (no developer name required on install) we
certainly can conduct that kind of review. And unofficial packages need
explicit pointer from the user as to which developer they want that
package from, so there is no ambiguity in the users mind. How a user
decides of the fives unofficial "apache" packages which one they want is
up to them, Google and $DEITY.


> No matter what avenue we go down, I particularly care about
> "apache.slangasek" to continue to work after the promotion to "apache"
> to ensure that all the blog posts out there pointing to how to install
> this package don't suddenly break.

Yes, and my proposal allows that, because anyone who installed
"apache.slangasek" is using it as just "apache" on their system, and new
users can get it without knowing about the very excellent Mr Slangasek.

Mark