← Back to team overview

ubuntu-appstore-developers team mailing list archive

Re: Sharing namespace permissions

 

Am 28.08.2013 12:01, schrieb Michael Nelson:
> On Tue, Aug 27, 2013 at 10:54 PM, Martin Albisetti
> <martin.albisetti@xxxxxxxxxxxxx> wrote:
>> Following the UDS discussion[1] about click packages as part of the
>> touch image, I'd like to flesh out how I understand the server should
>> work.
>> The core idea here is that tying a namespace to a user alone is not a
>> good fit for a collaborative, team-based software development process.
>>
>> The proposed solution would that someone would still own a namespace,
>> but would be able to give access to teams to be able to update the
>> app.
>>
>> An example of this would be, for any app that is shipped in the
>> default image that Ubuntu isn't the upstream, we'll want core devs to
>> be able to push updates to it (especially security updates).
>>
>> So my proposal is this: from the app page, you will be able to add
>> multiple teams to it, and anyone who is on one of those teams will be
>> able to upload new versions of the app (but not necessarily to a lot
>> more).
>
> Why teams, or teams defined where? If myapps is the UI for defining
> those teams, it might be simpler to use if you just "Add uploaders"
> rather than "create new uploader team" and "Add uploader to team" etc.
> (I'm assuming you're not talking about LP teams).
>
>
>> They would not own the namespace, they would just be able to upload.
> ... to upload a specific app right? (ie. they'd be able to upload
> fooapp.example.com, rather than general upload access to any app under
> the *.example.com namespace which is linked to the original person who
> registered the app).
Coming from the point of view of community projects, I wonder why
there's a need to restrict apps to one person to begin with and not even
use teams out of the box. There's a ton of problems involved with
requiring a specific individual who is occasionally unavailable. I'm
speaking from experience, I know what it means to not get critical fixes
out for days.
And indeed this applies to non-public probjects all the same as to
public ones.

Excuse my naivety here. I know there's security concerns. But seeing
collaboration as an after-thought seems very backwards to me.


Follow ups

References