launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxx>]

On Thu, May 3, 2012 at 9:57 AM, Jonathan Lange <jml@xxxxxxxxx> wrote:
> On Thu, May 3, 2012 at 1:27 AM, Julian Edwards
> <julian.edwards@xxxxxxxxxxxxx> wrote:
>> On Wednesday 02 May 2012 12:04:45 Jonathan Lange wrote:
>>> On Wed, May 2, 2012 at 11:36 AM, Julian Edwards
>>>
>>> <julian.edwards@xxxxxxxxxxxxx> wrote:
>>> > On Tuesday 01 May 2012 15:05:30 Jonathan Lange wrote:
>>> >> On Mon, Apr 30, 2012 at 5:28 PM, Jonathan Lange <jml@xxxxxxxxx> wrote:
>>> >> ...
>>> >>
>>> >> >  * add a boolean parameter to the subscription that controls whether
>>> >> > emails are sent
>>> >>
>>> >> This should have read "constructor" not "subscription".
>>> >>
>>> >> The corollary is that it would be stored as a field on Archive, and
>>> >> that anyone would be able to set it on construction. Presumably only
>>> >> PPA owners could change it. William jokingly suggested 'shut_up' as a
>>> >> name for this field.
>>> >
>>> > So basically s/commercial/shut_up/
>>>
>>> Yeah. Probably spelled as "suppress_subscription_notifications" or
>>> something of that ilk. Would be simpler than 'commercial' in that it
>>> would need fewer special permissions and wouldn't be so easy to
>>> confuse with commercial_admin and things like that.
>>>
>>> jml
>>
>> I'd go for an enum instead of a bool, far more flexible.
>>
>> Call it "block_notifications" and we get a few possibilities:
>>
>> NONE
>> SUBSCRIPTIONS
>> ALL
>>
>
> Cool. I'll work towards that then.
>

Actually, that wasn't entirely honest. Sorry. Here's what I was
actually thinking:

I want to continue doing this work incrementally. Before the 'enum'
suggestion, the way I planned to do it was this:

 1. make a property with the new name;  make that a simple
getter/setter for 'commercial'
 2. change the permission model for setting both it & commercial
 3. a series of patches to rename the column in the db

I still think this is a good plan.  We could do the enum bit as a step 4.

However, I'm not 100% convinced about the enum. It is more flexible,
but without an actual use case it's a YAGNI. I also suspect that it
will drive me into a positive line count delta. If we decide that
that's the way it should be, I'll happily do the work. I'd only note
that we could postpone that work until there's a use case, at no cost.

jml