[Fedora-infrastructure-list] Translating owners.list to packagedb: unknown accounts

Toshio Kuratomi a.badger at gmail.com
Thu Sep 14 08:46:56 UTC 2006


Hey packagedb and accounts2 people,

As part of filling the test packageDB with data, I'm working on a script
that pulls information out of owners.list and enters it into the
packageDB.  One of the problems is that I've got 631 errors where an
email address in owners.list doesn't match with anyone in the current
accounts system.  So I need to get a handle on how we can fix these
issues both short-term and long-term.

1) extras-qa at fedoraproject.org is listed as qa contact on all the Extras
Packages.  This field is nullable so I've decided that short term, I'll
leave this field as NULL.  Long term, we can either create an extras-qa
user in the accounts system or we can ask the people in Fedora Extras
what they want to do with it.  Unless there's a better idea, I'll
propose to them that we leave this as NULL and only fill the field if
there is actually someone who is the qa contact.

2) extras-orphan at fedoraproject.org is for packages which have been
abandoned.  I thought about letting Null equate to an orphaned package
but I think we might want to be notified if someone is modifying an
orphaned package so I think setting it to an orphaned user account is
better.  My long term suggestion is to create a fedora-orphan or
extras-orphan user in the account system to handle these.  Short term,
I'll just set them to go to me instead (heh -- Looks like I'll only have
46 extra packages to pretend to take care of.)

3) fedora-perl-devel-list at redhat.com is watching all perl packages.  No
matter what, we'll probably create a perl-SIG group in accounts.  For
SIGs, people should sign up for SIGs in the accounts system and then
they will receive all notifications that the SIG would receive.  There's
another table in the packageDB that handles that.  This leads to two
long term paths: perl-devel-list will be outdated in this new scheme as
everyone interested will just get notification via the SIG.  The other
path is that people still want notifications to go to the mailing list
instead of (or in addition to) subscribing themselves to the perl-SIG.
If that's the case we'll have to either create a perl-SIG user in the
accounts system or allow groups in the new accounts system to have an
email address.  lyz, abompard, do you have opinions on this?  Short term
I'm going to set these to being watched by a non-existent-group.  We'll
have to fix that before we get group notification working.

4) other emails which are not in the accounts system: This seems to
account for 82 errors.  I think that most of them are because the user's
bugzilla email address is not the same as the accounts system email
address.  Long Term: Running against the AccountsSystem2 with multiple
email addresses.  Short Term: I'm going to try to figure out which
addresses map to what numbers in the accountsdb.  This'll be tedious but
we should be able to just make the proper entries into the accounts db
later and everything will work.  One requirement this introduces to the
AccountsDB is being able to ask "for userid 12345, what is that user's
bugzilla address?"

Alternate short-term ideas that will save work are welcome.  Alternate
long-term ideas should make good discussion.  Code is owners.py in the
bzr repository:
  bzr branch http://www.tiki-lounge.com/~toshio/fedora/fedora-packagedb/

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20060914/b52c2f07/attachment.bin 


More information about the infrastructure mailing list