Hi Matti, i don't know about "safety critical" and have no idea whether what you are saying / trying to do there makes any sense, so i'm snipping that. Replying to your other questions...
Matti Karnaattu wrote on Wed, Sep 10, 2014 at 04:29:14PM +0300: > Is there any centralized static analysis in OpenBSD QA process? No. Our only "process" is code review, and knowing (without writing it down) who is responsible for what. If you really need to know whom to talk to for something *specific* (like, a patch), it's usually easy to find out without a list if you know the culture. If not, ask here. Static analysis tools are just tools, and variety is an asset. Besides, some of them aren't free, so they cannot be centralized. > Honestly, goals.html describe current state of project. It doesn't > describe long term goals/roadmap what developers are interested > to do. I understand that every one has personal aims but I'm looking > something like list of: "we must get rid of or rewrite this peace of > crap in next/following cycle". That doesn't exist, intentionally. It just doesn't work if you try to do it that way. You will mostly fail, and even if you succeed now and then, it will feel like a chore in retrospect. The best stuff gets done when people do, creatively, what they enjoy and feel is important right now, whenever they find the time. Remember, almost all of us work on OpenBSD in our free time. Well, there are exceptions. Like, in a security emergency, everybody knows what will get done within 24 hours, even though it may not be clear yet who does it. I certainly do know a few things i will do within one year from now, but i'm *not* going to commit to it. And Theo *will* sometimes be fiercely determined that something must get done the sooner the better, even if he ain't gonna do it personally, and he may even say so. But that's the exception rather than the rule, and even then, it does unfortunately happen now and then that nobody acts on it. > I'm looking all defined requirements for OpenBSD code and features. No way you are going to get that, even though unwritten standards are rather high. The most important aspect is common sense, and experience. You will learn from feedback you get when sending patches, so start with small ones to avoid wasted effort. Well there is style(9), but that is *not* the essential part but merely scratching the surface, maybe not even that. There is a quote about it in usr.bin/mg/theo.c IIRC. Actually, there are two, both very drastic. All the same, stuff not conforming to KNF will not get committed, because a consistent coding style *is* one minor aspect of code quality. Yes, that will unavoidably seem confusing to you at this point, but it's likely to become clear with time. Point is, it is completely impossible to write down what is needed to write high quality code in a high quality style as a set of rules that you just need to follow. It is no doubt possible to write down part of that, but whatever parts you write down, it will always be both horribly incomplete and much too restricting at the same time. Like, using "goto" in C code is a bad idea. Except that it is often the best idiom for prematurely erroring out of a moderately complex function. And yet, i have used it for other purposes, rarely, but multiple times, even in OpenBSD base. Like, mktemp(3) is almost obsolete, you should really use mkstemp(3). Yet, it *can* be used correctly, and sometimes, there is no other correct way, i once had to use it in OpenBSD base, and sure as hell, people did ask me to replace it, but i explained and it was confirmed to be the right thing to do in that exceptional case. You won't ever get away with using strcat(3), and you definitely won't get away without being yelled at for even trying to use gets(3), but such unambiguous, unconditional truths are the rare exception. Ultimately, the requirement is that code be correct, in particular using interfaces correctly and safely, as simple and as readable as possible, and using safe, common idioms wherever possible. Only human review, using common sense, experience, and good judgement, can check that. > I assume that contributions are accepted, not only some bug patches but > it make things easier (for new developers and users) if the mindset is > defined. It should also define priority what is more important. Work on what is important for *you*, and where *your* competence lies. We are not going to tell you what to spend your time on. > -Is license purity more important than following standards? An acceptable, fully free license is an absolute requirement, and /usr/share/misc/license.template is strongly preferred. Coming as close as possible to standards is one goal, but sometimes has to be balanced against other goals, like sanity and safety of interfaces. In that sense, the statement "license purity is more important than following standards" can be construed as true, but it is misleading. Code needlessly diverging from the relevant standards is completely inacceptable, no matter how nice the license may be. > -What are standards to follow (even partially) The main standards are ISO C and IEEE Std 1003.1-2008 (``POSIX.1''). Others may apply, too, depending on what you are working on. > and what are not? I don't think it is feasible to provide a list. The nice thing about standards is there are so many to choose from, is it not? > -Preferred targets. Embedded hardware and security applications, > but what else? Whatever developers are interested in. Developers are more likely to be interested in well-documented hardware than in hardware that requires reverse engineering. > -"Hey, I like to create GUI application, what is the preferred API?" That question is unrelated to OpenBSD. The OpenBSD base system does not contain any GUI API. Well, Xenocara does contain the bare X11R6 API, but we certainly don't recommend using that for application programming. There are lots of people *porting* GUI applications to OpenBSD. Some OpenBSD developers also contribute upstream to projects involving GUIs. But i'm not aware of anybody developing a GUI application *as an OpenBSD subproject*. > I think that programming should be mandatory in elementary school > because it force to describe what you wan't without ambiguity. > For this reason, I know this is easy task developers to do. The problem is not to *technically* describe what needs to be done (even though that isn't a trivial task either, or you wouldn't need to teach it). The problem with drafting a list is a social one. You can't know ahead of time what people want to spend their free time on. > However, I can't do that task because I don't know the OpenBSD > developers mindset and I don't know yet is this the right community. > I'm interested to put effort in controlled manner and help to remove > ambiquity. If you want to get involved, don't try to improve processes or set up lists. Get some concrete work done. If that works out, you can worry about improving processes in three years from now, if you then wish to. > I'm still probing this community. Let me be blunt: If you write ten more emails wondering about how to contribute (not counting mails on how to use OpenBSD, which are always on topic on misc@) without including a patch that is worth committing (or worth being tweaked such that it becomes ready for commit), you are not worth talking to. Beware, this is not meant as an insult. It is meant constructively, as a hint how this community works. There is a saying here, "shut up and hack". You looked at the code and liked how it looked. It looks as it does, among other reasons, because we work the way described above. Yours, Ingo
