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...
- The user info screen might want to evolve from just an "edit my
information" screen
All sounds good I read it to mean simpler and more integrated
Argh, ANOTHER thought I forgot to finish - thanks Dennis! :)
I meant to say that instead of just letting the user edit their
information, we should also have links to other places where they
might want to change their settings - the Wiki, OTRS, package
database, bugzilla, etc. - and maybe a status summary from each of
those places.
- 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...
- 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).
- 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...
(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
