Martin Sebor <mse...@gmail.com> writes: > 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.
Thanks, that sounds sensible. > 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. I can understand the reasons, system library programming is not a piece of cake, and must be taken with a great care. However, IMHO it's more important for the propriety projects to log everything in bug tracker, then just in the rcs, within the absence of commercial type of management. Maybe my opinion is a bit biased (I've never been a real tech lead so it's difficult to say), but please see below. > 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. In my day time job it's also a requirement. At ARM we do put so much efforts to get the processes right, and no change is allowed without being logged in the tracker, peer reviewed, validated etc. It makes sense for the projects kind of compiler, kernel, or system library - no doubt I fully agree. However, I believe that it has other side of story, it comes with an overhead, sometimes it's just very difficult to do anything because it all needs to go through the process. It's really pleasant feeling (which is perhaps an attribute of open source), when you just go to the code, feel true confidence, fix the bug and commit. Of course it makes sense in a certain cases and with the complexity of stdcxx is just very difficult to feel that true confidence :-) By looking at what kind bugs Liviu, Stefan, and you have fixed/discussed, I had an impression that lot of this stuff is tweaking, and smaller re-engineering work which just takes a lot of time and experience, and notoriously difficult to get right. I hope I will also have a taste of stdcxx, perhaps I might look at something this weekend. I still need to commit (somewhat) the bigger patches for armcc. > > 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. I fully agree with the test cases and the rest of the paragraph. It's really good to know your opinion! Thanks. -- Wojciech Meyer http://danmey.org
