Working on next FAS release

[Toshio Kuratomi]

On Sun, Oct 30, 2011 at 11:29 AM, Toshio Kuratomi <a.badger at gmail.com> wrote:
> On Sun, Oct 30, 2011 at 06:17:51PM +0100, Thomas Spura wrote:
>> On Sun, 30 Oct 2011 10:07:02 -0700
>> Toshio Kuratomi wrote:
>
> We'd also need to figure out how to get that information out to the bugzilla
> syncing scripts/other users who need to access this.... We could special
> case it on the servers (kinda defeats the purpose of having it in a plugin),
> add it to the client code in python-fedora (but, at least with the methods
> I see exposed right now, that means an extra query per user returned which
> will be unacceptably slow -- probably needs a method to return all the
> bugzilla emails which would mean client-side we'd have to wait for one extra
> query per request -- that could be cached on the client-side which would
> make it faster for scripts that make many calls to one fas objects but still
> slower for scripts that either run once and then exit or have to use
> separate fas instances (for instance, for threadsafety)).
>
> (Now that I'm going over the problems... I have a vague recollection that
> Mike might have queried me about these same topics long ago and pinged me
> about it... if that's correct, maybe we never came up with good answers to
> this and that's why we've never deployed this.)
>
> Another option would be to break backwards compatibility and tell people
> that bugzilla_email addresses have to be queried separately.  It's been
> quite a while since we had an API break so it's not out of the question to
> do that.  We might want to look at whether there's some other low hanging
> fruit that we've put off due to API breakage at the same time, though.
>
Another thing we'd need to look at is how to change the code that
modifies bugzilla when email addresses are updated.  The code
presently lives in core fas and updates a table when an email address
changes.  The table lists email addresses that need to have
permissions in bugzilla changed.  Then a cron job goes through that
table and adds and removes bugzilla permissions.

With bugzilla addresses in a plugin, the plugin would need to somehow
monitor changes to email addresses or that table and decide whether to
use the bugzilla email or main fas email when updating permissions.
FAS core doesn't currently provide event-type hooks for plugins.  It
only provides the means for plugins to register that they want to be
included in the FAS UI and tables to save any data to.

One option that was tossed out a while ago is whether to give up on
having this in a plugin; instead making it part of FAS core.  Doing
that, there would be no separation between parts so the code that
updated an email address would know about both the main FAS email
address and the bugzilla email address and be able to update the queue
of email addresses to change appropriately.

-Toshio