packageset restrictions and archive reorg

[Scott Kitterman]

On Monday, July 25, 2011 05:44:21 PM Micah Gersten wrote:
> 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?

So if a MOTU is working on something like, as an example, a library transition 
for NBS, it's better they have to stop and ask for sponsorship or fill out a 
form and get approved to be added to a team (see the way upthread comments on 
excessive bureaucracy)?  I don't.  

If I were not core-dev, my solution to this would be some kind of cron job 
that automatically applied to all the packagesets.

This view that we need to chop things up into small pieces and make sure only 
core-dev can upload without extra paperwork is not a good idea.  It also makes 
me really glad I resisted the idea of creating a KDE packageset for KDE 
packages in Universe.  The last thing I want is less help on these packages.

Scott K