deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jvlcek <jvl...@redhat.com>
Subject Re: split of mailing list
Date Thu, 10 Jan 2013 13:03:33 GMT
On 01/10/2013 07:44 AM, Koper, Dies wrote:
> Hi Michal, Marios,
>
> Yes, I think splitting up into dev@ and users@ is a bad idea. Having a
> very-low-traffic users@ mailing list looks bad and people would still
> send their questions to the higher traffic list.
>
>> mails. Also I think JIRA could be configured to not spam the mailing
>> list and just send mails about issues that your are subscribed to.
> Is that something I (each user) can/needs to do or is it done by the
> project owner?
> I just searched through the JIRA settings but couldn't find any settings
> page with notification options.
>
>>> didn't do this yet) - why don't you try some mail rules/filters
> (e.g.
>>> one subfolder for 'tracker' and one for 'jira') - this isn't the
> most
>>> user friendly approach but could help with the mail overload for
> now,
>
> Are you splitting jira and tracker?
> I was thinking of one ML for jira AND tracker and patches, and one (the
> current one) for user and dev discussions. If we can make jira less
> chatty (maybe only notifications of new issues. Or new and fixed?), I'm
> fine with including jira messages in the latter mailing list.
>
> Regards,
> Dies Koper
>
>> -----Original Message-----
>> From: Michal Fojtik [mailto:mfojtik@redhat.com]
>> Sent: Thursday, 10 January 2013 9:07 PM
>> To: dev@deltacloud.apache.org
>> Cc: Koper, Dies
>> Subject: Re: split of mailing list
>>
>> On 01/10, marios@redhat.com wrote:
>>> On 10/01/13 06:11, Koper, Dies wrote:
>>>> I noticed I received 80 e-mails from this mailing list in my Inbox
> since
>>>> Monday.
>>>> I'm very glad to see the increased activity!
>>>> But I can imagine Deltacloud users will consider that spam,
> especially
>>>> as most e-mails contain patches or tracker notifications. It also
> makes
>>>> it harder to find/follow discussions on functionality.
>>>>
>>>> I'd like to suggest we split up the mailing list according to
> message
>>>> purpose:
>>>> 1. dev@ for discussions (new functionality, changes to existing
>>>> functionality, questions from DC users);
>>>> 2. patches@ for patches, jira and tracker notifications.
>>>>
>>>> 1. will then generally contain threads that are permanently useful
> to
>>>> both us and DC users as reference, while 2. mainly contains
> messages
>>>> that are mostly important in their first few days (until ACK'ed),
> after
>>>> which they only serve as patch review history.
>>>>
>>>> What do you think?
>>>>
>>> imo this is a good idea; I'm pretty sure we've discussed this in the
>>> past, on at least one occasion. I can't remember why we didn't go
>>> through with it at the time.
>>>
>>> While we have this discussion - and until the admin side is sorted
> (if
>>> we decided to go ahead with the split - or someone reminds us why we
>>> didn't do this yet) - why don't you try some mail rules/filters
> (e.g.
>>> one subfolder for 'tracker' and one for 'jira') - this isn't the
> most
>>> user friendly approach but could help with the mail overload for
> now,
>> I think we have this solution before we moved to ASF. We had
>> deltacloud-users list and deltacloud-devel list. Problem was that the
>> users list was very low traffic (basically 1 mail per month).
>>
>> I would prefer to use filters/folder to filter out JIRA and tracker
>> mails. Also I think JIRA could be configured to not spam the mailing
>> list and just send mails about issues that your are subscribed to.
>>
>> But I have no problems with creating a new mailing list as well,
>> if others think it will be benefitial.
>>

My vote would be to leave it all on the dev list and work to reduce the
 JIRA/TRACKER/Patch traffic.

When a fix is proposed to a JIRA a patch email is sent, the JIRA is
sometimes  updated and a tracker is published. So for 1 patch
3 systems can end up sending email.

I'm not sure which of the many possibilities would be the best solution
and I'm open to any that would result in a fewer emails being sent
when a patch is published for review.

Joe


Mime
View raw message