From dev-return-8651-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org Fri Sep 7 02:52:31 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 BBE35D839 for ; Fri, 7 Sep 2012 02:52:31 +0000 (UTC) Received: (qmail 90917 invoked by uid 500); 7 Sep 2012 02:52:31 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 90878 invoked by uid 500); 7 Sep 2012 02:52:31 -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 90870 invoked by uid 99); 7 Sep 2012 02:52:31 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Sep 2012 02:52:31 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates 209.85.210.54 as permitted sender) Received: from [209.85.210.54] (HELO mail-pz0-f54.google.com) (209.85.210.54) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Sep 2012 02:52:25 +0000 Received: by dadr6 with SMTP id r6so1390105dad.41 for ; Thu, 06 Sep 2012 19:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=EsCrOg161lzdSlzRM2RVOxMVGCanWLw1fkCCiyo7JrE=; b=kLKDF9OlBpmvof9NBvwFwlpqoy759C4altwuA2hoxUpoLqhHnSq0TqvthJEucSPH/I V9cfgsOeZBSiRmlbgxmEKOku6fZetVorCKuteQ//uOwCUn2t+6vDfvGuB8z+d31DiTuX pA4qpdgGfMgv0jZoPy1riy++/YXE2/7lErUFt4DrMaKlzZ2AKdujiL/dax7IBBVupuuq CUToaF7C1Hgos+OnfArYFMPr/09SEvYJ6LJZwWeJFgKCR+KPRSY5cQcH9T7z0pXQq2VL 7Ih1WMwGjfqzQW4jv80gQncTcSMob9WAv1bXRlmt2l1wH0kU6S+w6zbqq/vc6ZBR6RKB e/nw== Received: by 10.68.217.69 with SMTP id ow5mr8010470pbc.35.1346986325576; Thu, 06 Sep 2012 19:52:05 -0700 (PDT) Received: from [10.99.105.173] (72-163-0-129.cisco.com. [72.163.0.129]) by mx.google.com with ESMTPS id qo8sm2364813pbb.19.2012.09.06.19.52.04 (version=SSLv3 cipher=OTHER); Thu, 06 Sep 2012 19:52:04 -0700 (PDT) Message-ID: <50496153.5030407@gmail.com> Date: Thu, 06 Sep 2012 20:52:03 -0600 From: Martin Sebor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: dev@stdcxx.apache.org CC: Wojciech Meyer Subject: Re: A question (or two) of procedure, etc. References: <5048E63F.8090603@hates.ms> <50495DBE.4010208@gmail.com> In-Reply-To: <50495DBE.4010208@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org One thing I forgot to mention: we have three active branches, and, for better or worse, most changes tend to get committed to 4.2.x first. It's easy to forget or delay committing the same change to 4.3.x and trunk. Having an issue in Jira serves as a reminder to also commit the change to the other branches. (At least until we start doing development on trunk.) On 09/06/2012 08: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. > > 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. > > 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. > > 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. > > Martin > > On 09/06/2012 12:37 PM, Wojciech Meyer wrote: >> Liviu Nicoara writes: >> >>> 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. >> >> 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. >> >> 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. >> >> So the general consensus from my experience with other project was: not >> sure - ask. >> >> That's my experience, also I don't have full rights to express my >> opinion right now about stdcxx. >> >>> 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? >> >> 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). >> >>> >>> Also, besides the Linux, FreeBSD, Windows, Solaris builds hosted on >>> Apache (Jenkins) is anybody building on HP-UX, AIX, etc.? >>> >>> Thanks. >>> >>> Liviu >>> >> >> -- >> Wojciech Meyer >> http://danmey.org >