launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxx>]

On Tue, May 1, 2012 at 3:27 AM, Julian Edwards
<julian.edwards@xxxxxxxxxxxxx> wrote:
> On Monday 30 Apr 2012 17:28:27 Jonathan Lange wrote:
>> We think that removing 'commercial' would make Launchpad simpler and
>> reduce its maintenance costs. However, we would want to still be able
>> to subscribe people without sending them emails. It's on this that we
>> want your input.
>
> Can you explain a bit more why you think it would make LP simpler?  Bearing in
> mind you still want to do the same thing elsewhere:
>

Because it would have less stuff in it. What do you mean by the same
thing elsewhere? Do you mean preventing other "normal" PPA emails from
going out?

>> Here are some options that we thought of:
>>
>>  * add a boolean parameter to the subscription that controls whether
>> emails are sent
>>  * don't send subscription emails when the request came from the API
>>  * don't send subscription emails at all
>>
>> Are any of these preferable? Are there better options?
>
> Emails from PPA actions are a total mess right now and unfortunately None of
> these suggestions will improve it IMHO.  One of the main problems is that
> everything is too tightly coupled which makes it far too easy to break
> unrelated events.  For example, emails are only normally sent to uploaders,
> except if you are an archive subscriber, and except again if it's commercial
> :/
>

If that's the behaviour we need (mails sent to uploaders who aren't
archive subscribers or if the archive is used for the Software
Centre), then that sounds like intrinsic complexity. All decoupling
will do is take the 'if' statements about mail in Soyuz and turn them
into 'if' statements about events in a mail dispatcher.

> Ideally we need a separate subscription mechanism that clearly delineates
> email sending from the Soyuz innards.  I think Rob had some ideas for that to
> use Rabbit as part of the SOA push.  Decoupling email entirely from LP would
> be marvellous.
>

Well, that's rather paralyzing. Is there no middle ground?

jml