Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <475DA5D1.8060503@roguewave.com>
Date: Mon, 10 Dec 2007 13:47:13 -0700
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.9 (X11/20071031)
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: mailing list for Jira issues?
References: <475CE829.9040909@roguewave.com> <14257741.post@talk.nabble.com>
 <7BDB2168BEAEF14C98F1901FD2DE643801511F2D@epmsa009.minsk.epam.com>
 <14260442.post@talk.nabble.com>
In-Reply-To: <14260442.post@talk.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Travis Vitek wrote:
> 
> 
> Farid Zaripov-2 wrote:
>>> Travis Vitek wrote:
>>>
>>> I have no objections. Either way, I need to look at both sets 
>>> of messages regardless of where they come from. So, for me, 
>>> moving the Jira messages to a new -issues list doesn't have 
>>> any significant impact.
>>>
>>> I guess it might be useful for users with 'dumb' e-mail 
>>> clients that don't have proper message filtering.
>>   My +1 for the change.
>>
>>   I'm using the MS Outlook and filtering the JIRA messages by the
>> "[jira]"
>> in subject. But any reply to jira messages with "Re: [jira]" in subject
>> are
>> filtered also :( And Outlook dosn't provide the possibility to make more
>> flexible rule :(
>>
>> Farid.
>>
> 
> I don't know how the infra group will set this up, but I wouldn't expect the
> addition of a new list to fix this problem for you. All generated messages
> from jira would come from the user that modified the case and be sent to the
> stdcxx-issues@apache.org list. Any response would appear the same. This is
> how it works now.

This, btw., is pretty extensively configurable in Jira. stdcxx
is subject to the STDCXX notifications Scheme that I set up for
us back in 2005 when our Jira was first created.

The latest documentation that explains how this works is here:
http://www.atlassian.com/software/jira/docs/latest/notification_schemes.html

I suspect you may not be able to view the stdcxx notifications
page w/o Jira admin access but here it is anyway:
https://issues.apache.org/jira/secure/admin/EditNotifications!default.jspa?schemeId=12310060

Here's our current setup for those who can't access the page,
with Events first and the set of available Notifications below
(defaults in parens):

Issue Created  (System)
     * Reporter
     * Single Email Address (stdcxx-dev@incubator.apache.org)

Issue Updated (System)
     * Reporter
     * Current Assignee
     * Single Email Address (stdcxx-dev@incubator.apache.org)
     * All Watchers

Issue Assigned (System) 	
     * All Watchers
     * Single Email Address (stdcxx-dev@incubator.apache.org)

Issue Resolved (System)
     * Current Assignee
     * All Watchers
     * Reporter
     * Single Email Address (stdcxx-dev@incubator.apache.org)

Issue Closed (System)
     * All Watchers
     * Current Assignee
     * Single Email Address (stdcxx-dev@incubator.apache.org)
     * Reporter

Issue Commented (System)
     * Reporter
     * Current Assignee
     * All Watchers
     * Single Email Address (stdcxx-dev@incubator.apache.org)

Issue Comment Edited (System)
     * Current Assignee
     * Reporter
     * Single Email Address (stdcxx-dev@incubator.apache.org)
     * All Watchers

Issue Reopened (System)
     * Single Email Address (stdcxx-dev@incubator.apache.org)
     * Reporter
     * All Watchers
     * Current Assignee

Issue Deleted (System)
     * Single Email Address (stdcxx-dev@incubator.apache.org)

Issue Moved (System)
     * Single Email Address (stdcxx-dev@incubator.apache.org)

Work Logged On Issue (System)
Work Started On Issue (System)
Work Stopped On Issue (System)
Issue Worklog Updated (System)
Issue Worklog Deleted (System)
Generic Event (System)

> 
> Also, I believe that Outlook rules allow you to make a rule handle this
> situation. You just add an exception to your rule that checks for the
> strings "RE:" or "Re:".
> 
> Travis