"What I like least in Ubuntu"

Scott Kitterman ubuntu at kitterman.com
Mon Jul 25 20:46:18 UTC 2011


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



More information about the ubuntu-devel mailing list