ubuntu-appstore-developers team mailing list archive

[Michael Nelson <michael.nelson@xxxxxxxxxxxxx>]

On Wed, Aug 28, 2013 at 3:08 PM, Christian Dywan <christian@xxxxxxxxxxxx> wrote:
> 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.

Hallo Christian,

I don't think there is no need to restrict an app to one person to
begin with - it'd be great to have an easy way for one person to add
an app and enable a whole team to upload new versions by default. I'm
just asking how (ie. by adding those people directly to the app or the
*.example.com namespace, or by first creating a team and then adding
the people to that, or whether we're importing Launchpad teams).

Another thought: when you look at your own profile in myapps, you
could add your team(s) there and re-use them on your apps - maybe
that's what Martin meant?

Cheers,
Michael