"What I like least in Ubuntu"

[Micah Gersten]

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.

Micah