Merge ~robru/britney/+git/britney2-ubuntu:send-emails-daily into ~ubuntu-release/britney/+git/britney2-ubuntu:master
| Status: | Merged | ||||
|---|---|---|---|---|---|
| Approved by: | Iain Lane on 2017-03-23 | ||||
| Approved revision: | 63573fa24a315105178c154906b8686cc84e62e5 | ||||
| Merged at revision: | 63573fa24a315105178c154906b8686cc84e62e5 | ||||
| Proposed branch: | ~robru/britney/+git/britney2-ubuntu:send-emails-daily | ||||
| Merge into: | ~ubuntu-release/britney/+git/britney2-ubuntu:master | ||||
| Diff against target: |
190 lines (+49/-45) 2 files modified
britney2/policies/email.py (+31/-17) tests/test_email.py (+18/-28) |
||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Iain Lane | 2017-03-17 | Approve on 2017-03-23 | |
|
Review via email:
|
|||
Description of the Change
Resend emails periodically, such that 2^daysold days pass in between each mail sent, with a maximum of 30, so that emails are never sent less often than monthly (see tests for explicit list of emailing schedule).
| Robert Bruce Park (robru) wrote : | # |
Not sure I understand your review laney, are you saying you want emails sent after 1 day, then 8 days after that, then 16 days after that, then 30 days thereafter?
| Robert Bruce Park (robru) wrote : | # |
Ok, aside from the mail frequency, I think I've addressed all your concerns, please merge. possibly the frequency issue should be decided by vote? Steve wants it to be quite frequent to maximize nagginess.
| Iain Lane (laney) wrote : | # |
Righto - the code looks good to me as it stands so on that basis I'm happy, thanks. I've only eyeballed and ran the testsuite though so I could be missing something.
Still not convinced by the aggressiveness of the frequency. I think the initial emails sent at 1, 2, then 4 days is too much. If there's a problem then I think people should be given some time to sort it out. Sending an email the very day after the first one, which itself is only maybe 1 day after the initial upload, is not giving people a reasonable chance to sort out the problem IMO. 2^n might be nice because it's a neat formula but I think it produces bad results. To strawman, I personally think that there should be at least 3 clear days between nags. Backing off as we get further away from the upload date is a nice feature though - I think that aspect should be retained.
Like I said initially, if the consensus of the rest of the team is to disagree with me then somebody else could merge.
(And I still think it would be cute to say in the subject that it's the nth (where n > 1) reminder, but that's not a requirement.)
| Iain Lane (laney) wrote : | # |
Ok, it now has a 3 day threshold for everything (valid or not valid).
I think that *might* be acceptable, so let's go with it and see if it turns out to be.
If we need to go back to the 1 and 5 cases, then I propose to set a lower bound on the frequency of 3 days but we'll see when we come to it.

Hmm.
Well, I'm just one reviewer, so take this with appropriate weight (if someone else wants to merge, they can).
I think that the initial schedule is too aggressive. I get that you want to psychologically burden people so that they do the work, but I think that we should be giving people some time to actually do it. As an initial proposal, we can remove the '2', and '4' levels? And an idea to ramp up the pressure if you want to do that is to put in the email subject and/or body the amount of times you've reminded about that upload so far (I guess that it should be possible to calculate this so you don't have to store it).
Subject: [proposed- migration] glib2.0 is stuck in zesty-proposed (2nd reminder)
Body: You are bad, this is the 2nd time we've emailed you about this.
Also, some comments/questions inline.