From dev-return-7765-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org Wed Jun 04 21:55:16 2008 Return-Path: Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: (qmail 48434 invoked from network); 4 Jun 2008 21:55:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Jun 2008 21:55:16 -0000 Received: (qmail 86152 invoked by uid 500); 4 Jun 2008 21:55:19 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 86143 invoked by uid 500); 4 Jun 2008 21:55:19 -0000 Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@stdcxx.apache.org Delivered-To: mailing list dev@stdcxx.apache.org Received: (qmail 86132 invoked by uid 99); 4 Jun 2008 21:55:19 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jun 2008 14:55:19 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [208.30.140.160] (HELO moroha.roguewave.com) (208.30.140.160) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jun 2008 21:54:23 +0000 Received: from nebula.bco.roguewave.com ([10.70.3.27]) by moroha.roguewave.com (8.13.6/8.13.6) with ESMTP id m54Lsilt020355 for ; Wed, 4 Jun 2008 21:54:44 GMT Message-ID: <48470F24.3090706@roguewave.com> Date: Wed, 04 Jun 2008 15:54:44 -0600 From: Martin Sebor Organization: Rogue Wave Software, Inc. User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: dev@stdcxx.apache.org Subject: Re: [jira] Deleted: (STDCXX-33) Implement C++0x regular expressions References: <711621612.1212610365026.JavaMail.jira@brutus> <4846F901.6090109@roguewave.com> <4846FB3C.80809@roguewave.com> <4847077B.3040002@roguewave.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Eric Lemings wrote: > > >> -----Original Message----- >> From: Martin Sebor [mailto:sebor@roguewave.com] >> Sent: Wednesday, June 04, 2008 3:22 PM >> To: dev@stdcxx.apache.org >> Subject: Re: [jira] Deleted: (STDCXX-33) Implement C++0x >> regular expressions >> >> Eric Lemings wrote: >>> >>> >>>> -----Original Message----- >>>> From: Eric Lemings >>>> Sent: Wednesday, June 04, 2008 2:58 PM >>>> To: 'dev@stdcxx.apache.org' >>>> Subject: RE: [jira] Deleted: (STDCXX-33) Implement C++0x >>>> regular expressions >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Martin Sebor [mailto:sebor@roguewave.com] >>>>> Sent: Wednesday, June 04, 2008 2:30 PM >>>>> To: dev@stdcxx.apache.org >>>>> Subject: Re: [jira] Deleted: (STDCXX-33) Implement C++0x >>>>> regular expressions >>>>> >>>>> Martin Sebor wrote: >>>>>> Could we move issues instead of deleting them? >>>>> Also, we're still discussing what the plan is WRT how these >>>>> components will be organized so these kinds of changes seem >>>>> premature. In fact, I'm not sure I see why any issues need >>>>> to be deleted or moved. Why can't the existing ones can be >>>>> changed? >>>> They are subtasks and subtasks can't be moved. I tried. >>> Also, subtasks can't be broken down into smaller issues. Some of >>> these issues will likely need to be subdivided into smaller chunks >>> of work. >> As a courtesy to the rest of us working on the project it would >> be nice to let us know what restructuring changes you'd like to >> make, and wait for feedback before making them. Especially >> deleting issues should be brought up because doing so not only >> permanently removes them from the database but also breaks any >> links pointing to such issues. > > Jira is pretty smart. It allows you to relink such issues before > deleting issues so there are no broken links. This is now a broken link: http://issues.apache.org/jira/browse/STDCXX-33 > > And the issues are still in the database. I just moved them from > subtasks into individual issues. Or you'd prefer to keep the > duplicate issues? I would prefer us to have a plan before we start moving issues around or permanently deleting them. As it is, the rest of us are left to guess what's happening with the existing issues, why they're being deleted, why new ones are being created, or where you plan to stop. If you want to change/improve things you need to let us in on your plan ahead of time to make sure your changes don't adversely affect anyone or that there isn't a better way to go about implementing them. It's possible that we'd end up doing exactly what you did in the end. The big difference is that we'd all understand and (hopefully) agree with what's going on. Martin