> As you saw on the last week we have been sending a big number of patches in > order to sync both repositories. We have also been taking many of the > patches that have been made by the community. Our goal is to have the same > code base, and then patches will be applied easily.
This is a problem. We shouldn't have a significant amount of changes done outside the main repository, with a request that all those changes go in at once. The result is that you can end up building a series of changes on a concept that the community may reject. The repository is painfully slow for us as well - we need to host the software somewhere else. What we're ending up with are patches that either make no sense by themselves or patches containing multiple, independent changes. Both of these are hard to review. Since code review finds more bugs faster than testing, it's in everyone's best interest to encourage and take advantage of code reviews, and the earlier this is done the better the code quality will be and the faster it will be completed. > Please also note that when doing changes to our code, we try to be on the > safe side. We are trying very hard not to be in a place where customers > will reach a BSOD because of a small bug. This is the reason for checkins > that are very defensive like the memory allocation checkin. Masking bugs is really not the answer. It leaves the bug there, but makes it even harder to find. Without knowing the cause of a bug, we have no idea the extent of problems that it causes. IBAL is filled with so much 'defensive' code, abstractions, and work-arounds that it's extremely difficult to read and maintain. _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
