Hi Matti, Matti Karnaattu wrote on Wed, Sep 24, 2014 at 09:14:45PM +0300:
> Thanks for your patience. I feel like I'm querying preferred > coding style by this way. That's not the *goal*, but it's an unavoidable side effect, and the more it succeeds, the easier everuthing gets for both sides. [...] > I have about million lines of build and other errors under review > where I have found anomalies. Some of them seems to be errors > in OpenBSD, most of them are errors in code. It is likely that a sizeable fraction is just false positives, too; but i don't doubt some things hide in there that merit improvement. > It just not work if I point out every single anomaly, bug, missing > parameter etc. > > Example, I think it would be best if I write proper document where I > collect ALL known issues related to POSIX conformance that can be > reviewed and made to public knowledge. Not really. Usually, the main effort when approaching a list of hundreds or thousands of potential issues is - to figure out what is most relevant - to figure out whether it is really an issue - to figure out how exactly it can be improved If you try to write down a long list, that is not ideal. You will waste a lot of time, and others may not even find the time to read the whole list. So really try to pick - out of your huge pile of potential issues - some of those that you consider among the most serious and at the same time the most easy to fix and start with those. Once you found something that is confirmed to be an actual issue and a fix was committed, sweep the tree for it, then move on to the next class of issues. There is no way anyone can fix the world. Everybody has to pick something. Picking something relevant one is able to fix is part of the art - actually, a very important part of the art. Yours, Ingo
