Re: [Mailman-Developers] Postorius issue tracker labels

[Terri Oda]

On 2016-06-04 3:23 PM, Simon Hanna wrote:



I'm not sure "rest" is the way it's currently being used either: it

might be

more useful to rename it to be like the wait-for-mailman tag to

indicate bugs

that occur due to mailmanclient.


'wait-for-mailman' is just a little weird given that we use the term
'mailman'
for the whole umbrella project.  'wait-for-core' is a little better but
it
doesn't accurately describe blockers on mailman.client.
'wait-for-api'?  I'm
also okay with leaving it as it us until/unless we figure out something
better.


In most cases I think we would have to wait for both core and mailmanclient. 
Thats why I don't think we need two labels for it.
In my opinion it would be better to have only one label and always link to an 
issue in mailmanclient and/or core


We actually changed it to be just "blocked" so it can refer to any thing 
we might be waiting on, including things just in client, things in core 
and client, and other issues, since that turned out to be useful for triage.


 Terri


___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Postorius issue tracker labels

[Simon Hanna]

>>I'm not sure "rest" is the way it's currently being used either: it
>might be
>>more useful to rename it to be like the wait-for-mailman tag to
>indicate bugs
>>that occur due to mailmanclient.
>
>'wait-for-mailman' is just a little weird given that we use the term
>'mailman'
>for the whole umbrella project.  'wait-for-core' is a little better but
>it
>doesn't accurately describe blockers on mailman.client. 
>'wait-for-api'?  I'm
>also okay with leaving it as it us until/unless we figure out something
>better.

In most cases I think we would have to wait for both core and mailmanclient. 
Thats why I don't think we need two labels for it. 
In my opinion it would be better to have only one label and always link to an 
issue in mailmanclient and/or core

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] New Interface

[Harshit Bansal]

Hi,

On 04-Jun-2016 1:11 am, "Barry Warsaw"  wrote:
>I've always wanted styles to be composable, by which I mean that a style can
>describe just a partial set of attributes.  For now I'll call these stylets.
>One stylet might define how autoresponses work, while another might describe
>how digests work.  In a sense, this is analogous to how the composition was
>broken down in MM2.1, but without all the ugly mixin stuff.

How can this composability be achieved in a model? I mean that the
size of a table is fixed in a model and if a style describes just a
partial set of attributes then what would be stored in other
attributes?
Also how would this partial style be applied to a mailing list?

Problems that are blocking me for past two-three days:

Solved:
1: Getting a list of all styleable attributes.
Since you have approved the new interface this problem is solved.

Unsolved:
1: How to trigger the fallback mechanism?
2: Current 'IStyle' interface allows us to define either a partial
style(stylet, describing just a partial set of attributes) or a
complete style. But is that possible with a model?
3: If I go for style composabiltiy as described by you then how would
I represent that idea in REST and Postorius?

Thanks,
Harshit Bansal
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] New Interface

[Barry Warsaw]

On Jun 04, 2016, at 07:38 PM, Harshit Bansal wrote:

>Would you like to keep these attributes(those which are unused and we
>don't want to support) or should these be removed?

For now, keep them.  It would probably make sense to open an issue on gitlab
listing the unused attributes to delete.  We can mark that as a tech-debt
issue and address it outside of the context of your work.

>From core's point of view this idea seems to be fine but I am unable to think
>of any way of representing this idea in Postorius(since new styles would be
>created there)?

Yes, the ui issues are challenging. ;)  I think it would be fairly easy to
represent in REST.

>Earlier while discussing we decided to make style composable in terms of
>other styles(inheritance and fallback mechanism). For example, if a user
>wants to modify only the the autoresponses attributes of Style1, then, he may
>create a child style of Style1 and change only the attributes related to the
>autoresponses and rest of the attributes will take their values from the
>parent style(Style1).  Also is there any advantage of making styles
>composable in terms of stylets?

It allows the admin to only be concerned with the attributes defined in the
stylet.  It can be fairly difficult otherwise to figure out what a specific
stylet modifies.

>The new interface will contain only styleable attributes and not any
>immutable attributes like created_at. All the immutable attributes
>will reside in the existing 'IMailingList' interface.

Cool.

>> Then it may be possible to do a lot of cool things on stylets, such as
>> impose permissions on changing or using one; recording the stylets used
>> with a particular mailing list, so if you change the stylet, the mailing
>> list automatically changes, etc.
>
>How will be the permissions enforced without authorization system?

Postorius would enforce it for now.  When we have the authproxy, it will do it
for scripts.

>> The only other comment on the above paragraph has to do with requiring a
>> style to contain *all* the attributes.  How would you handle the
>> composability in that case?
>
>All attributes will be required only in case the style doesn't inherit
>from any other base style. In case the style inherits from some other
>base style then the dictionary(argument to the constructor) will
>contain only those attributes which the user wants to change and rest
>of the attributes would be taken from the parent style.
>
>Also could you suggest some default value(such as 'DEFER') for
>styleable attributes that would trigger the fall back mechanism to
>take values from the parent style.

That's tricky.  If we weren't interfacing to a database (i.e. in pure Python),
we'd have a marker object, e.g. `INHERIT = object()` but we have to worry
about database column types.  I'm not sure what the right thing to do there
is.

-Barry

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Postorius issue tracker labels

[Barry Warsaw]

On Jun 04, 2016, at 08:46 AM, Terri Oda wrote:

>I'm not sure "rest" is the way it's currently being used either: it might be
>more useful to rename it to be like the wait-for-mailman tag to indicate bugs
>that occur due to mailmanclient.

'wait-for-mailman' is just a little weird given that we use the term 'mailman'
for the whole umbrella project.  'wait-for-core' is a little better but it
doesn't accurately describe blockers on mailman.client.  'wait-for-api'?  I'm
also okay with leaving it as it us until/unless we figure out something
better.

-Barry

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Postorius issue tracker labels

[Terri Oda]

On 2016-06-04 1:11 AM, Stephen J. Turnbull wrote:

Hi, all

I just went through the labels in the Postorius issue tracker

https://gitlab.com/mailman/postorius/labels

and documented the undocumented as well as changing a couple of
labels.  Comments very welcome.

There are two labels whose purpose I'm unclear on, "subscription" and
"ui".  I think "ui" should be split into "appearance" (CSS) and
"workflow" (what operations can be done from which forms).  If so, I
think "subscription" really should be merged into "workflow" (at least
the open issue should be).


It looks good to me, and I especially like the proposed UI split.

I think the "subscription" tag can go away: it was used to flag bugs 
related to subscribing and unsubscribing, but I don't think that's a 
super useful category in and of itself right now .


I'm not sure "rest" is the way it's currently being used either: it 
might be more useful to rename it to be like the wait-for-mailman tag to 
indicate bugs that occur due to mailmanclient.


 Terri

___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9