From dev-return-8656-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org Fri Sep 7 11:27:01 2012 Return-Path: X-Original-To: apmail-stdcxx-dev-archive@www.apache.org Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4F271D92A for ; Fri, 7 Sep 2012 11:27:01 +0000 (UTC) Received: (qmail 4650 invoked by uid 500); 7 Sep 2012 11:27:00 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 4434 invoked by uid 500); 7 Sep 2012 11:26:54 -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 4357 invoked by uid 99); 7 Sep 2012 11:26:51 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Sep 2012 11:26:51 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: 76.96.62.24 is neither permitted nor denied by domain of jim@jagunet.com) Received: from [76.96.62.24] (HELO qmta02.westchester.pa.mail.comcast.net) (76.96.62.24) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Sep 2012 11:26:42 +0000 Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta02.westchester.pa.mail.comcast.net with comcast id wB3A1j0011ap0As51BSSZa; Fri, 07 Sep 2012 11:26:26 +0000 Received: from [192.168.199.10] ([69.251.80.74]) by omta22.westchester.pa.mail.comcast.net with comcast id wBSo1j0131cCKD93iBSqjh; Fri, 07 Sep 2012 11:26:50 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Subject: Re: A question (or two) of procedure, etc. From: Jim Jagielski In-Reply-To: <50495DBE.4010208@gmail.com> Date: Fri, 7 Sep 2012 07:26:19 -0400 Cc: Wojciech Meyer Content-Transfer-Encoding: quoted-printable Message-Id: <6161DAF7-34A9-4AF6-9301-00EEAFEE0930@jaguNET.com> References: <5048E63F.8090603@hates.ms> <50495DBE.4010208@gmail.com> To: dev@stdcxx.apache.org X-Mailer: Apple Mail (2.1486) Just a few points: 1. No single individual can "make a process more formal". If the project itself wants more process, and to make it more formal, then all is good. If a single committer decides on his/her own to add process *which is not formally required by the ASF* then committers are free to discuss and even ignore that process. If in doubt, ping others and, eventually, board@ 2. ASF Projects are, well, ASF projects. They are external adjuncts of corporate projects, and so having processes "flow" into the ASF project due to "requirements" from one's employer is *definitely* a NoNo. With all that said, Martin's process flow is a Good One and should the PMC decide it is the official procedure to follow, then the project would be the better for it. On Sep 6, 2012, at 10:36 PM, Martin Sebor wrote: > Anyone is welcome to express their opinion here, especially > if you are or have in the past contributed to the project. > The weight of the opinion is (or should be) commensurate to > the value of the contributions. I think the ASF calls this > Meritocracy. >=20 > I made the stdcxx process increasingly more formal as I learned > from my own past mistakes that a loose process makes it harder > to track changes and find the root cause of the problems they > sometimes introduce. In practical terms, I've made an effort > to have an issue, with a test case if possible, for every > change made to the code, and commit a regression test into > the test suite for every bug fix. >=20 > FWIW, in my day to day job, this is a requirement. Cisco > doesn't make a change to its code without an issue. My team > does the same with GCC changes. We find that projects that > don't follow this practice as closely (e.g., GNU Binutils), > tend to be more difficult for us to work with than those > that do. >=20 > That being said, when it comes to the stdcxx configuration > machinery, or to the test suite, I think it's fine to be > somewhat less formal. We don't need test cases for problems > in configuration tests, or necessarily even test cases > reproducing failures in library tests (although small tests > can often be more useful than the large tests we have in > the test suite). We also don't need tests for makefile bugs. > Outside of that, when it comes to changing the library, I > do recommend making an effort to create test cases and open > issues for all changes. >=20 > Martin >=20 > On 09/06/2012 12:37 PM, Wojciech Meyer wrote: >> Liviu Nicoara writes: >>=20 >>> What is the latest policy in what regards trivial fixes, e.g., the >>> volatile qualifier for the max var in LIMITS.cpp we discussed = earlier, >>> etc.? It seems excessive to create a bug report for such issues. >>=20 >> My advice based on some observations with other projects, is that in >> these cases we go just go on and apply fix. Non invasive code quality >> improvements over the codebase should be promoted not hindered. More >> risky patches, should be discussed on the list, the ones that needs >> either serious changes, attention, re-factoring, feature or fixes = that >> may break something should be logged in Jira. >>=20 >> So I vote for keeping the changes as lightweight as possible, and = avoid >> extra bureaucracy if it makes sense. This assumption is based that >> developers here trust their selves, and run the tests often. I'm not >> subscribed to the commit list here, but if I do - I usually follow >> people's changes and assume that developers do read commit lists. >>=20 >> So the general consensus from my experience with other project was: = not >> sure - ask. >>=20 >> That's my experience, also I don't have full rights to express my >> opinion right now about stdcxx. >>=20 >>> Also, IIUC from reading previous discussions, forward and backward >>> binary compatible changes go in 4.2.x, followed by merges to 4.3.x = and >>> trunk. Am I getting this right? >>=20 >> Every project has certain branch strategy, I'm not sure about this so >> maybe Martin can advice. I prefer to develop on trunk and cherry pick >> to the other branches avoiding bulk merges (and that's in both >> directions). >>=20 >>>=20 >>> Also, besides the Linux, FreeBSD, Windows, Solaris builds hosted on = Apache (Jenkins) is anybody building on HP-UX, AIX, etc.? >>>=20 >>> Thanks. >>>=20 >>> Liviu >>>=20 >>=20 >> -- >> Wojciech Meyer >> http://danmey.org >=20