launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Fri, Nov 27, 2009 at 2:35 AM, Martin Pool <mbp@xxxxxxxxxxxxx> wrote:
> 2009/11/27 James Westby <jw+debian@xxxxxxxxxxxxxxx>:
>> On Thu Nov 26 19:49:43 -0500 2009 Martin Pool wrote:
>>> Adding the owner would be a bit consistent with bzr branches, to which
>>> these have some resemblence.  However, I think putting the owner into
>>> the branch name has been a bit mixed, because there are important
>>> cases where people want to change the access rightly without changing
>>> the name.  Therefore on the whole I'd argue for leaving it out, and
>>> having an owner field that can be changed later.
>>
>> The only issue with leaving it out is that the name must then be
>> unique across all recipes for that package/distro, correct?
>>
>> I see two problems with this, firstly that if someone calls theirs
>> say "official" or "poolie" then you have an issue with impersonation.
>> Yes, you can check the owner by going to the page, but even those
>> looking at the page might not notice. Granted, there tends to be
>> a proliferation of branches named "trunk" or similar, so it is hard
>> to know which is the blessed trunk from the unique name anyway.
>
> They can of course already register ~bzr-team and push
> ~bzr-team/bzr/3.0 if they're actually trying to be malicious.  I don't
> think the name can ever be enough.
>

I agree that such malice cannot be addressed by the name alone.

>> The second issue is that I expect people will tend to informally
>> namespace things by putting their nick in to the recipe name anyway.
>> This isn't necesarrily an issue, but in other areas LP tends to want
>> to capture this information structurally where it can.
>
> I agree with these, but I'm not sure the second is a problem.  I think
> people do tend to distinguish branches that ought to have global names
> (even if they happen to be owned by someone) from those they think of
> as personal.  So they can make mbp-doc.   Launchpad will know from the
> owner field and other things who's been involved with it.
>
> So I could accept either one but I think it's worth having the
> conversation before we introduce a new namespace.
>

We're having the conversation now. :)

 * Putting owner in the URL and conflating ownership with write
permissions leads to broken URLs, which is bad.
 * Not having the owner in the URL disallows recipes for the same
package with the same name.

What other considerations are there?

jml