On Wednesday 05 July 2006 11:03 pm, Elliot Lee wrote: > On Jul 5, 2006, at 23:38, Dennis Gilmore wrote: > >> - In particular, there is a lot of concern that getting a GPG key > >> is too complicated for a lot of people such as translators, who are > >> not technical types. We need to make that process as clear and simple > >> and documented as possible > > > > can we provide a script for nontechnical types? > > One good possible solution... > >> - Allow groups to be members of other groups (i.e. you are a member > >> in group B because you are a member in group A, and A is a member of > >> B). Can't do this nicely with the current SQL schema. I did it nicely > >> with the old Red Hat build system, but it requires using text fields > >> instead of numeric IDs to specify the names of the group members... > > > > with the right interface it shouldn't matter if GID's/UID's are > > numerical or > > text > > This was where I diverged into an implementation detail rather than > stating a problem. At the SQL schema level, it does matter. All this > should be totally transparent to the user... that was what i was trying to get to the user should have no clue of the implementation. I could be wrong but i think it could be done either way > >> - On a related note, we need to add proper support for the corporate > >> CLA. If we had 'groups being members of other groups' implemented, it > >> would be fairly easy to create a group for each corporation that > >> signed the CCLA, have each of those groups be a member of the > >> cla_done group, and having access to the corporate CLA groups > >> administered by a designated contact... > > > > Sounds good. is there many corporate CLA's? > > I believe Dell and IBM are the only ones (I know Dell, not sure about > IBM). So not huge but with it being easy for the corporate type to participate It could encourage others to sign up > >> - Figure out the whole LDAP vs SQL thing > > > > Why not use both? some thing will be just easier in ldap, some in > > SQL, use > > SQL as a backend to ldap Its a little more work but would provide > > greatest > > flexibility. > > Can you explain more of what you're thinking in this area? In my > thinking you have to have one authoritative place to store the data, > and while you can do things like offer other interfaces as desired, > it's not really a matter of using two solutions where one will do... What i was thinking was to keep the authoritative data in a SQL server with ldap server as a client http://www.flatmtn.com/computer/Linux-LDAP.html provides one way to implent. I personally have not done it. But i think it could be an option. > (BTW, how hard would it be to implement an LDAP server whose tables > were the direct results of SQL queries, with no gatewaying done? Is > there a python module to make it easy to implement an LDAP server?) > > Best, > -- Elliot > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list -- Dennis Gilmore, RHCE Proud Australian
