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<nikko...@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
