Hi Matti, Matti Karnaattu wrote on Thu, Sep 11, 2014 at 02:14:25AM +0300:
> 1. Is there any preferred way to post diffs? * cvs diff -Nup * send inline in the mail body, not as MIME attachments * if you are already in contact with a particular group of developers who want to review diffs in that area, send directly to them (two to four people is ideal), otherwise and in case of doubt, send to tech@ * make sure every single diff makes the system better, that is, can be justified on its own, even if it actually is part of an ongoing project * make sure each patch does exactly one thing, and does that completely, avoid diffs doing five different things at the same time, and do not split one logical change into two diffs * keep diffs small, in particular at the beginning * make diffs easy to review * never ever send quilt patchsets or similar things > 2. Is there any preferred framework to write tests? bsd.regress.mk(5), /usr/src/regress > 3. If I wrote a bit more code and there is need to separate it, > is there any ready guidelines/templates for software modules, folder > structure etc? Don't start with that, start with small things where this question does not arise. Getting in stuff that requires new files or even new directories is *much* harder than changing existing files and certainly not recommended for beginners. That said, no, it really depends on the individual case, and which part of the system you are talking about. > 4. What kind of test suites are used to ensure that changes don't > break thigs or causes bugs? I mean others that are found in sources. /usr/src/regress > 5. What is the licence policy in toolchain? I mean, it is clear to me > that platform itself conforms much as possible > http://www.openbsd.org/policy.html but how about development tools which > are used only to produce ISC code? Is the policy relaxed to allow then > more restricted open source code? Let's say, GPL code in some > verification tool or testsuite? The policy is "no new GPL code below /usr/src", no exceptions. Deleting existing GPL code from /usr/src will result in much cheering. What you do on your private machines is up to you. > However, OpenBSD default FVWM look is like Motif. See /usr/xenocara/app/fvwm/COPYING for the license(s), fvwm is mostly close to ISC with an advertising clause. Admittedly, a few parts are GPL. [... large snip about GUI stuff ...] > If offer is accepted, what is the preferred way to do the task? I have no idea, and i'm not interested. I wouldn't even use the result. There are problems with fvwm, yes. It is old, crufty code of horrible quality. But regarding functionality, i would rather call it bloated than ask for more features. Then again, i don't care enough about GUIs to waste my time trying anything else. Yours, Ingo
