stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wojciech Meyer <>
Subject Re: A question (or two) of procedure, etc.
Date Fri, 07 Sep 2012 03:57:39 GMT
Martin Sebor <> 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!


Wojciech Meyer

View raw message