yellow team mailing list archive

[Danilo Šegan <danilo@xxxxxxxxxxxxx>]

Hi all,

On the topic of bug 772763, here's my summary.

У чет, 05. 05 2011. у 14:25 +0200, Danilo Šegan пише:

> У уто, 03. 05 2011. у 14:56 -0400, Francis J. Lacoste пише:
> 
> > Jono and I are tempted to say that we should try to fix the 'Unmuting a bug's 
> > notifications should restore your previous direct subscription ' bug in those 
> > two weeks. If that's something bigger than that, let's not bother. I don't 
> > think that not being able to deploy this at the end of the two weeks is a big 
> > deal. If we have a fix that will be rolled-out two weeks later, that's good 
> > enough.
> 
> I'll look into how much effort this'd really take.  Depending on that, I
> might pursue it.

Looking into it, it's not too complex.  I should have the very basic
functionality done tomorrow, but cleaning up the "NOTHING" level of
subscriptions will take a bit more time, just like making sure UI
interaction is clean and consistent will.

This is how I see it:

 1. Branch to introduce BugMute table and switch Bug mute/unmute methods
to use it[*], and change one of
getRecipientFilterData/construct_email_notifications to ignore
recipients which are muting bug mail; the latter part of this still
needs doing and testing.

It turns out this is not overly complex because NOTHING level works "by
default": it mutes your subscription because it changes the level to a
lower one which nothing looks at when sending notifications.  Direct
subscriptions take precedence over assignee/implicit supervisor
subscriptions.  And they probably take precedence over structural ones,
but I haven't checked that yet.

Or well, not work: it doesn't work for team subscriptions in my testing.
We took that this worked in good faith, but it doesn't.
I spent most of my time trying to figure out how is muting a direct team
subscription working, becoming convinced it's not, and then confirming
it with a test.

As a side effect of the change, we'll fix this as well (and be certain
that no emails go out, because we'll be stopping them right before they
fly out).

 2. Branch to get rid of all BugSubscription.bug_notification_level ==
NOTHING usage

 3. Branch to get rid of all
BugSubscriptionFilter.bug_notification_level == NOTHING usage (not much
of these), and removal of the NOTHING value from the
BugNotificationLevel enum

 4. Make sure UI flows nicely: i.e. when a subscription is unmuted, UI
restores to a state to reflect that (since the JS keeps the subscription
state pre-loaded, we might need to make sure it's there even if a
subscription was muted when the page was initially loaded); also,
"Unmute" perhaps needs not be a pop-up dialog anymore, but that's up for
further discussion; interaction with the "Edit subscription" link gets
trickier as well

1-3 are suitably easy, and I believe they can be finished in three days
of work. I believe 2-3 need to be done so we are certain we haven't
missed anything.

4 is a bit complex considering we are breaking some of the core
assumptions of the model, and I wouldn't even try to give an estimate
considering we are not set on what we want to do exactly.  Choosing a
simpler plan Gary proposed would not have helped this, because we'd
still have to think about exactly the same problems.

Cheers,
Danilo

[*] I am also changing the return value of mute() method to be a BugMute
record: this means an incompatible API change, but it was exported as a
write operation with no annotation for the return value, so I believe it
doesn't matter.