[Mageia-dev] maintainers database

Sat Dec 18 13:39:17 CET 2010

Op zaterdag 18 december 2010 12:00:52 schreef Michael scherer:
+> On Fri, Dec 17, 2010 at 11:55:39PM +0100, Romain d'Alverny wrote:
+> > On Fri, Dec 17, 2010 at 23:41, Maarten Vanraes
+> > 
+> > <maarten.vanraes at gmail.com> wrote:
+> > > imo, it could be used into mageia-app-db, allthough the purposes are a
+> > > bit different.
+> > 
+> > So it should be a separate component.
+> > 
+> > > however, if we plan on using ldap to store the maintainership (it would
+> > > be more like groups for each package and people being member of
+> > > it...), then perhaps it should be in catdap.
+> > 
+> > I'm not sure this should be put into the LDAP, but I may be wrong. The
+> > data model is likely to change often enough (even if not a lot) and
+> > queries are likely to be frequent enought, to justify a separate,
+> > simple db/app for that. But here again, I may not have all the infos.
+> 
+> I think we should use a simple sql database for now.
+> 
+> Even if later, ldap could help use to set ACL, and tree structure for
+> packages ( ie, the grouping feature of packages you spoke of ), I think we
+> should aim first for a very basic application :
+> 
+> 1 srpm -> 1 to N maintainers,
+> 
+> and that's all.
+> 
+> Later, we can think more thoroughly about this, and likely rewrite.
+> But the initial goal was to reuse mdvdb because
+> it was the fastest route. So we should not forget about it. If we use a
+> quick and dirty django application with basic CRUD to manage that, it
+> should be fine.
+
+i'm ok with quick and dirty.
+
+tbh, i would like to have this in ldap; since it's related to groups; 
+especially if we will woul mailgroups for each package, the member (or 
+uniqueMember) can be used to get all the maintainers for that package, and an 
+extra attribute to have a primary maintainer.
+
+in effect: being co-maintainer could even be validated by the primary 
+maintainer; if primary maintainer leaves, a co-maintainer can grab the primary 
+maintainership; if no maintainers are there, someone can become maintainer 
+without checks, and becomes primary maintainer directly. only valid packagers 
+can grab maintainership (but novices can too)
+
+packagers should have an ldap attribute for the level: none, novice, full, 
+security (where none can be omitted and security means he can do security 
+updates)
+
+(if you haven't seen it yet; i'm a fan of having everything directly related 
+to auth and groupings of users into an ldap)
+