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