From dev-return-7767-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org Wed Jun 04 23:04:44 2008 Return-Path: Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: (qmail 26089 invoked from network); 4 Jun 2008 23:04:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Jun 2008 23:04:44 -0000 Received: (qmail 73824 invoked by uid 500); 4 Jun 2008 23:04:47 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 73812 invoked by uid 500); 4 Jun 2008 23:04:47 -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 73801 invoked by uid 99); 4 Jun 2008 23:04:47 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jun 2008 16:04:47 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.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 23:03:58 +0000 Received: from nebula.bco.roguewave.com ([10.70.3.27]) by moroha.roguewave.com (8.13.6/8.13.6) with ESMTP id m54N4CB0022715 for ; Wed, 4 Jun 2008 23:04:13 GMT Message-ID: <48471F6D.1030908@roguewave.com> Date: Wed, 04 Jun 2008 17:04:13 -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> <48470F24.3090706@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:55 PM >> To: dev@stdcxx.apache.org >> Subject: Re: [jira] Deleted: (STDCXX-33) Implement C++0x >> regular expressions >> >> 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. > > Initiative...momentum got the better of me I suppose. :) Sorry. > > So what is it, in particular, that we all do NOT understand or agree > with? I'll clarify if I can... or haven't already. I thought I already said that I don't agree with deleting issues or making these types of structural changes w/o having a plan in place. What is your plan? What if someone else has a different plan? We discussed integrating the Jira TR1 components into the others (deleting issues wasn't mentioned). You proposed adding "(C++ 0x)" to the subject and I suggested adding a field for the version of the standard instead. We haven't finished the discussion yet but you've already created a number of new issues that don't follow either of the two proposed conventions. There's no "(C++ 0x)" in the Summary and no new field indicating the version of the standard, and links to the deleted issues are now irreparably dead. Martin