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
