packageset restrictions and archive reorg

[Micah Gersten]

On 07/25/2011 04:25 PM, Scott Kitterman wrote:
> On Monday, July 25, 2011 04:52:42 PM Micah Gersten wrote:
>> On 07/25/2011 03:46 PM, Scott Kitterman wrote:
>>> On Monday, July 25, 2011 03:48:38 PM Micah Gersten wrote:
>>>> On 07/25/2011 02:05 PM, Scott Kitterman wrote:
>>>>> On Monday, July 25, 2011 02:41:29 PM Mackenzie Morgan wrote:
>>>>> ...
>>>>>
>>>>>> There was a discussion about it on IRC last week starting at
>>>>>> http://irclogs.ubuntu.com/2011/07/18/%23ubuntu-devel.html#t20:43
>>>>>>
>>>>>> In particular, this is the part about whether MOTU can or can't touch
>>>>>> packages in package sets...
>>>>>>
>>>>>> <maco>	so should we make it a habit of making teams to match when we
>>>>>> make new packagesets?
>>>>>> <persia>	Considering that AA always took care of components, we
>>>>>> probably ought adjust packageset change permissions to be union of DMB
>>>>>> and AA or similar.
>>>>>> <cjwatson>	yes.  but that is Hard.
>>>>>> <cjwatson>	(AIUI.)
>>>>>> <persia>	Unless we expect the DMB to take over regular migration of
>>>>>> stuff for transitions, etc.
>>>>>> <cjwatson>	maco: it's probably the most practical approach
>>>>>> <persia>	cjwatson: It's hard to have a union of teams.  It's not hard
>>>>>> to have a team with membership limited to AA+DMB that owns the
>>>>>> packageset.  That said, it needs discussion and consensus before being
>>>>>> done.
>>>>>> <maco>	cjwatson: so then we just ask the TB "can you make packageset
>>>>>> $name with packages x,y,z and permissions to $team" and then never
>>>>>> have to bug you about that packageset again (for the most part...until
>>>>>> it needs a new package)
>>>>>> <persia>	When we approve a PPU, does this necessitate the creation of
>>>>>> a packageset?
>>>>>> <maco>	persia: we often vote to create a packageset if the set being
>>>>>> requested seems reusable or is copied off someone else and is
>>>>>> therefore obviously being reused
>>>>>> <persia>	maco: Right, when there is a team.  My concern is that we
>>>>>> grant packageset teams exclusive authority over packages unique to
>>>>>> their packagesets (which is why packageset teams are required to have
>>>>>> core-dev as a member).
>>>>>> <maco>	persia: i did not know of this requirement
>>>>>> <micahg>	persia: in terms of Archive Reorg, I don't think PPU should
>>>>>> have a packageset
>>>>>> <persia>	This is incompatible with our statement that we *do not*
>>>>>> grant exclusive authority over packages for PPUs, once MOTU is
>>>>>> implemented as the inverse of all packagesets.
>>>>>> <geser>	maco: if the package set is DMB-owned (some are like mozilla,
>>>>>> zope and some others) the DMB can add and remove packages from it once
>>>>>> the TB created the package set
>>>>>> <persia>	maco: Failure to abide by the requirement today has a low
>>>>>> penalty, as Soyuz still supports component-based permissions.
>>>>> Package set members having exclusive lock on packages is something that
>>>>> has been discussed, but AIUI (except for packagesets corresponding to
>>>>> Main) there are no such restrictive packagesets in place.  I can't
>>>>> imagine why if I, to pick a random example, was part of the uploaders
>>>>> for a Mono package set I would want to make it harder for other Ubuntu
>>>>> developers to help with it.
>>>>>
>>>>> I know that restrictive package sets was part of the original vision,
>>>>> but I don't recall that ALL package sets were to be restrictive.  This
>>>>> just seems like a recipe for increased balkanization in the Ubuntu
>>>>> developer community. I don't think it's a good idea (regardless of it
>>>>> was originally intended or not).
>>>>>
>>>>> Scott K
>>>> AIUI, it wasn't that all packagesets would be totally restrictive in the
>>>> reorg, but rather they would be core-dev + packageset uploaders for the
>>>> ACLs.  The only difference WRT now would be MOTU access to current
>>>> universe packages.  I think the understanding is that if we have a
>>>> packageset, we have a subset of people caring for those packages.  Any
>>>> qualified person wishing to care for these packages can then apply for
>>>> the packageset.  MOTU would serve as generalists for the packages that
>>>> have no particular group taking care of them in the archive.
>>> I don't see any advantage to such a system over MOTU as generalists who
>>> care for packages outside of restricted packagesets (and restricted
>>> package sets are limited to what was historically Main and only expanded
>>> after a lot of consideration).  I see lots of disadvantages.  If there
>>> is some need for a packageset to be restricted, then I think I think
>>> it's reasonable to consider, but that's a different model than we've
>>> used so far.
>>>
>>> So far, AIUI, the model has been to create package sets where it seemed
>>> reasonable to grant limited upload rights to people who were specialists
>>> in that type of package.  Outside of the traditional Main package sets I
>>> don't think we've created a package set with the view that generalists
>>> ought not touch such packages.
>>>
>>> De facto we have a system where core-dev are unlimited generalists and
>>> MOTU are limited generalists.  Neither are excluded based on not being a
>>> package set uploader.  As a core-dev I can upload Ubuntu Desktop
>>> packages (and have done so as recently as last weekend).  I think that
>>> is a feature not a bug. Similarly I think having MOTU be able to upload
>>> to non-restricted package sets is a good thing and we should have a very
>>> good reason for making additional package sets restricted.
>>>
>>> Scott K
>> The problem is that, with the archive reorg, everything is in main
>> (except for restricted/multiverse), so there are thinks in packagesets
>> and things not in packagesets.  With this setup, the only access that
>> makes sense for a generalist group that can't do everything is
>> everything not in a packageset.
>> Micah
> We have package sets that are only accessible to core-dev + packageset 
> uploaders, so I'm not sure what you mean by that.  We have packcagesets that 
> are accessible to MOTU + packageset uploaders, so I'm still not sure what you 
> mean by that.  Call it what you will, the non-restrictive packageset is what's 
> in use now outside of what used to be Main.
>
> I'm confused.
>
> Scott K
>
Currently, the only packagesets that include MOTU are for products:
== All rights for motu ==
Archive Upload Rights for motu: archive 'primary', component 'universe'
in oneiric
Archive Upload Rights for motu: archive 'primary', component
'multiverse' in oneiric
Archive Upload Rights for motu: archive 'primary', package set
'mythbuntu' in oneiric
Archive Upload Rights for motu: archive 'primary', package set
'ubuntustudio' in oneiric
Archive Upload Rights for motu: archive 'primary', package set 'xubuntu'
in oneiric

My guess as to why this was done is those packageset's packages were in
universe whereas other packagesets were across the main/universe
boundary.  This should probably be revisited at some point.

What I was referring to is that the current packagesets would migrate to
being packageset uploaders + core-dev (for the ones that aren't
already).  MOTU would then be able to whatever isn't in those sets and
core-dev would continue to be able to upload everything.  If a MOTU
wanted to be able to upload to a certain packageset, they would be able
to apply for that set, so why should it be included in MOTU?

Micah