> 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.
True. As OpenBSD aims for POSIX compatibility, I'm thinking about document of missing features, known anomalies, known bugs and reasons for those. Example, if some certain standard feature is simply crap, or there is legacy reasons why things works differently or there is known bugs or some features are not just implemented, these can be checked from single document, there are possible workarounds, OpenBSD specific #ifdef / #endif etc. After I fully review my self all those millions error messages, end result is less than 50 relevant issues. And after that data is reviewed together, @tech there may be left less than 20. And if issues are fixed, new features done, list can be cleaned up, or if new problems are found these can be added. 2014-09-24 21:54 GMT+03:00 Ingo Schwarze <schwa...@usta.de>: > 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
