stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: A question (or two) of procedure, etc.
Date Fri, 07 Sep 2012 11:26:19 GMT
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 <msebor@gmail.com> 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<nikkoara@hates.ms>  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
> 


Mime
View raw message