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@xxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxx 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@xxxxxxxxxx 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
Attachment:
signature.asc
Description: This is a digitally signed message part
