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 -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
