Is there a list similar to Linux kernel janitors also for OpenBSD? It's a list

of tasks for which you don't have to be experienced in the particular OS

internals to be able to complete them properly.
CL<

No, there isn't.
There are, however, two de-facto janitors for the OpenBSD kernels:

martin@ and I. Those janitors, however, are experienced developers.
Quite frankly, the idea of the janitor being a rookie scares the hell

out of me. How can you trust people if these people admittedly do not

know what they are doing, or why they are doing things one way and not

another?
That said, I have a huge todolist, as a brain dump in text format. A

good quarter of it are simple tasks, which one may consider janitor

level.
I am even considering posting it to tech@ on a rainy day with a bit more

details.
I am adamant I'll find volunteers to work on the various items.
But in order to be able to trust their work, I'll need to share

knowledge and make sure these people are smart and bold enough to

understand what they are doing.
This is not a problem, per se. The problem is - as usual - time. There

are items on my list I don't have time to do, which would take me N

hours.
If I need to talk to someone and ``hold his/her hand'' and guide

him/her for 4*N hours, I've lost even more time.
I am not reluctant to share my experience. I just don't have enough time

to do this, and I can not guarantee I'll be able to devote those 4*N

hours to someone to help him/her get started and work on nice things.
That's a waste, because these janitoring tasks make you learn a lot of

things in no time.
But I don't want to betray the trust of people willing to help, as long

as I am able to help them get started until they can fly by themselves,

by not being there enough time in the beginning.
Working on the kernel is not something you can do with a ``1 hour every

week or every month'' rate. You need to dive for a longer time,

especially at the beginning, because there are many things to get

acquainted with. That's when you need as much support as possible. And

that's the kind of support I, as an individual, can not provide.
Miod

You cannot, of course. But janitor being a rookie doesn't imply he doesn't know

what he's doing. He could be doing a job that doesn't require any special

knowledge - like rewriting documentation into a different format, fixing HTML

correctness, fixing typos and unclear places in text - or who asks if he isn't

sure how to continue properly.
CL<

So, start by sending diff's then. Almost every diff's I saw sent in, got

reply one way or an other. In case this is not clear to you then. You

don't need to asked someone, send your diff's and you will get reply to

them if worth it.

Hi!
My recent experiences differ, for my last 2 submissions (an issue with

swig, sent to ports@ after interaction with the maintainer; the sendmail
Kind regards,
Hannah.

That will be fixed within the next ten minutes, at least for your

swig patch ;-)
It's true -- sometimes submissions don't get feedback in time or

are just dropped. This sucks, but it happens, and I've no idea how

to deal with this problem in general. (personally, if I'm short of

time, I tend to ask submitters to send me a reminder if nothing

happens within a few days or weeks).
Ciao,

	Kili

This include example and full diff's below as well.
May be this is a waist of time, but will see.
Some say they needs some details, then here is an example, and this took

me only about 30 minutes or so from start to finish, including getting

the source tree.
Doesn't mean it will be pick up, but it sure is not that hard to do and

doesn't need years of experience.
Start by getting the tree:
http://openbsd.org/anoncvs.html#starting
Some example on how to get the tree:
http://openbsd.org/anoncvs.html#EXAMPLE
Then pick something you want to work on or do. Previously explain as

well as an easy example. Just style (9)
man 9 style
Just as an example, pick:
1. Use a space after keywords (if, while, for, return, switch).
or may be even:
2. Indentation is an 8 character tab.  Second level indents are four spaces.
or even:
3. Do not add whitespace at the end of a line, and only use tabs

followed by spaces to form the indentation.  Do not use more spaces than

a tab will produce and do not use spaces in front of tabs.
Or anything else to start with that you want.
Then go from there. Use what ever editor you want and go hunting.
Just as an example, I will hunt for <space>...<space><tab>
I just pick anything.
Just for the sake of argument or example, I pick the first one:
/usr/src/bin/csh/init.c for fun. and look for the above.
Then you create a diff from that from your favorite cvs, or the one you

downloaded the source from obviously.
Just as an example, I did it form one find in the explications page

pointed out in the URL above. You email the diff to you, check it out to

make sure it does look right and then you can forward it to the list

with explications of what it does. Try to keep it simple and small as

this is easiest and will most likely get picked up faster and specially

if you address one thing only per diff, it make it that much easier for

the devs to check.
Then if it is good, it will be put in and if ...
[ message continues ]

Let me say this. I am not native English, but doesn't the word

"interaction" mean a level of communications between two party? So, you

got feedback to start with from the maintainer.
If that diff's is not in, may be the devs are busy and haven't picked it

up yet, or may be you didn't follow the advise of the maintainer for it.

Or may be the person that usually deal with sendmail is not available at

the moment. Looking at the various changes in that section,
http://www.openbsd.org/cgi-bin/cvsweb/src/gnu/usr.sbin/sendmail/cf/ostype/
It sure is not a very active one and may be, just may be it might take a

bit more time to get review by the right person, or the person

interested in it.
Your diff was sent: 2007-11-01 22:19:19
http://marc.info/?l=openbsd-tech&m=119395606819644&w=2
Less then 48 hours and on weekend as well. So you expect anyone to just

jump right away to put it in?
May be it's just wrong, or may be it wasn't looked at yet.
Searching on marc for pass one, I don't see a huge amount of them to see

if you can judge yet as to put a complete judgment on it.
If you diff is good, it will be in, if not, it will not. Doesn't mean

you shouldn't send in some diff's.
Don't expect each and every one of them to be put in.
Best,
Daniel

I had a similar problem at work.
After investing a lot of time training a new engineer to accomplish

[database, servers, network] administration tasks, taking his/her

hand, guiding him/her through the steps I want him/her to make things

the-way-I-want-it... they leave.
And I have to start all over again with the next engineer. I was tired of that.
The last time, I made her write the documentation in Docbook,

foolproof guides, for the next engineer. Problem solved, more or less.
Marc Espie is so good at that for example. Anybody with basic skills

and enough interest can port software to OpenBSD.
My point is that maybe instead of tutoring a person, time is better

used writing documentation or guidelines about where to start, what

steps to follow and how to do things the-way-you-want. These documents

will reach more people and have more impact than tutoring someone.
I would bring art@ to the discussion too, who has been reluctant to

tutoring people but that has a lot of knowledge that would be a pitty

that he gets hit by a truck before sharing some! ;-)
Or probably the documentation of the kernel itself as a project would

help. [Recalling...] which was Espie's idea sometime ago. Well Karel,

you may start with this.
Just my 20 centavos.
--

Gerardo Santana

Alternatively, perhaps 'Kernel Janitor' is the wrong way to put it. In

my mind, two of the big wins for OpenBSD are the documentation, and the

fact that the system is but together as a whole, kernel and binaries.

Whilst the kernel itself may be too high a jumping-off point for

inexperienced people, might some of the simpler bits of userspace be a

gentler introduction?
One thing I have noted on the commit list, is the number of commits of

documentation/comment typo fixes, bringing things in line with style(9),

and the like. I will freely admit that I can't code for toffee, but I am

an experienced proofreader, and I can generally pick my way through

existing code and  follow what it does. If there were a list of 'These

man pages need proofreading', or 'These source files could do with a

style(9) audit', I could (and would, oh dear...) give hours of my time

to the project.
I would hope that proofreading-type tasks would require minimal

hand-holding from the experienced devs, barring looking at completed

diffs and giving feedback. I would not wish to take away any time from

those more capable than I, but I do believe with a small amount of

assistance I and people like me could make a contribution.
With respect to 'Foolproof guides for new engineers', if anyone is

considering such a thing I would happily help lay them out and collate

them. Perhaps you don't want engineers who would like a foolproof guide

though? :-)
This is me chucking my hat into the ring, to try and do my duty

according to the last two points under

http://www.openbsd.org/faq/faq1.html#Support :-D
Si1entDave

i believe the task list itself would be positive , even if not much

happens around it.  they are good for the community as well as the

codebase.
you are not commiting yourself to mentoring and tutoring every idiot

who wants a crack at the kernel, you're simply saying, "look if you

think you're good enough to do the work, here are some things that i

know, from my experience, need done".  the learning and effort comes

from interested parties.  this sort of delegation does work in other

projects, perhaps if we have a good list we can figure out how to make

it work here too.
--

        t

 t

                 w

Agreed....
I needed to peek OpenBSD code a couple months ago and found it

extremely readable. Doing simple tasks can be a better path leading

to new kernel engineers.
Just posting your task list on this list isn't a commitment to coach

new developers, but can provide a solid material to start coding.
Obviously patches will be subject to peer review. Even if a patch isn't

approved, the coder should have learned something new and useful.

They don't need a list.  They could already have started coding.  Yet

we see how few people actually do start coding.  Instead, they choose
Yeah, right.

How can we get started on the code unless we have some idea of where

to start on the code? Sure we could just code whatever, but why would
I don't understand. Is newbies learning new things a waste to you? Do

you think they won't really learn anything unless the patch is

approved? Or will the patches not be subject to peer review? Or are

you worried at who would pass for peer review getting overwhelmed by a

huge volume of poor quality patches?
-Nick

Men,
This is a long list of emails. I read them all for fun. You want to know

where to start, then you can simply do very simple things if you want as

simple as taking the code and check for very simple style(9) stuff as

simple as.
<space><space><space><tab>
for example. style(9) is very specific about that. This is so simple and

no brain at all is needed to do it and the patch are simple to review.
Start there and do that. Then do more of style(9) and keep going.
Get ready to get hit too in the process.
I did a lots of clean up in apache for example. Took me months to do and

was no fun, but I stick with it. It got put in and I wanted to do more

of it as I earn part of my living with apache, so it's important to me.
But the fact is that the code suck big time. Much cleaner to read now,

but men it suck! No one will tell you otherwise here. I would invest way

more time to replace it with lighttpd instead, but that decision haven't

be done and I have no say in it either.
There is also plenty of patches that comes to tech@ that needs testing.

So, do that, test them and send feedback. This is as important as coding.
If you find bugs, stick with them and test them well. Try to fix. You

can't always do it. I know I try some, but still no reason not to try.
And keep at it, or find something you need or like and do it.
I did. It's been almost two years now that it started and it's not

finish, far from it. It's hard to do right, it pretty darn expensive

thank you! Hopefully when it will come out if will be well receive, but

that doesn't mean you can't start doing very simple things and keep going.
All the time spend sending lots of emails about it, may have given you

plenty of patch already.
Download the source and search for the very simple brainless example

provided and see if you can come up with that.
Again, I am not a developers here and nor do I have commit, so you sure

can say I talk to my ass, but again, just do it a...
[ message continues ]

Remember the motto guys: it's ``shut up and hack'', not whine about

getting something to do, then whine about how to do it, and hack.
If you don't know what to do, read source code, then hack.

If you don't know how to read source code, then learn by reading books,

then read source code, then hack.

If you don't want to read, just shut up.
Pierre Riteau

-- a modest contributor who like the way it is.

Here I'd like to warn before substituting reading code for reading interface

specification. What happened on the Linux kernel shows that code cannot be by

principle substituted for interface specification:
1. Person A wrote a nonblocking function X performing a task T. The spec

   in his mind was "X does T, whether it blocks or not is undefined."

2. Person B looked into the code, saw X does T in a nonblocking way and

   inferred: "the spec for X is that it does T in a nonblocking way"

3. B wrote a caller function that called X with an assumption that X doesn't

   block, everything was OK

4. A rewrote X in a way that now it blocks

5. Since now a hidden deadlock is in the kernel and noone has the slightest

   idea that anything wrong has happened.

All the developers currently active in OpenBSD have followed the same

process: scratch their own itch.
Start using OpenBSD. Notice things which are not perfect (there are a lot

of them), fix them. Get noticed. Once you send enough correct fixes, you

get an account. If your fixes are bogus, we will usually tell you they're

bogus. It's not our job to hold your hand.
We value autonomy a lot. It's fairly easy to find things to do: just look

on the various mailing-lists. It's very easy to find stuff at your level,

whatever that might be.
Don't expect to become a rock-star overnight. All people in OpenBSD have

grown over the years. The best way to do sexy things is to start with

the grunt work, and to move up from there.

Why not start with the PR database?  Pick a category and class that

appeals, do a search or two, and off you go with problems to solve.

The fact that they're in the PR database would seem to indicate that

fixing them would be useful for *someone*.
In my experience at my day job, good fixes for "janitor" issues can

often require a broad vision for all the interacting parts.  If they

were simple nits, they would have been fixed on the spot.  Instead,

they're still irksome because the solution isn't completely obvious.

(Maybe my definition for "janitor issue" doesn't match yours...)
Philip Guenther

No, newbies learn something by reading code. and finding

something they are interested and passionate enough in to learn

how something very difficult works, then realizing that they are

a complete idiot and it doesn't work that way, and then doing it
	Yes, and yes.
	Basically look, when it comes to the kernel there are two

types of student, the self taught, and the hopeless. While we

will more than be willing to help people who take the initiative themselves

to look for something and work on it. This takes a significant amount

of our time and energy. A lot of it actually.  Yes, learning the kernel

and how the basics work is a barrier to entry. It needs to be so, people

without the motivation to get over that hump on their own will simply

sap too much time from the people who have otherwise. 
	Basically I'm telling you, if you want to play in this area, you need

to earn your stripes. *earn* - not have shown to you. Sorry if that

sounds elitist, but that's the simple fact. Already overworked senior

developers do not have time to spoon feed people who already

demonstrate that they will not take the initiative to learn things on

their own. Sorry, that's just the facts guys. It's the difference between:
1) Help me, I don't know how this works but it's cool I want to do things.

   - Did you try to figure it out?

   No please show me. Tell me what to do... <sit and wait for direction>
and
2) Ok, I think this is important, and I think it works this way...

   - No you're not quite right, your assumptions are wrong at a, b, and c

     go back and try again

   Oh, ok <goto top>
Number 2 gets to doing useful things a hell of a lot faster, and the

time spent by the person giving the "-" reply is a heck of a lot more

productive.
	-Bob

Thanks. *that's* clear. It's good to be elitist about code quality,

that's what attracts me to OpenBSD. I just didn't see the connection

right away.

Sorry for wasting your time but thanks for shining a light upon how it works.
-Nick

It's almost like

If you've gotta ask,
I do not speak for the developers,

but I think maybe I know where they are coming from.

You get into this, not to do some good and useful,

but as a violent and visceral reaction to bad code.

(bad something anyway)

Essentially: This stinks. There's gotta be a better way.

Or this has to be easy.

And go to enourmous trouble to show that it is easy.

On 31.10-08:20, Theo de Raadt wrote:
on the counter-side we appear to have people who can code but are

unable to communicate productively otherwise.
surely there must be _some_ merit to creating a list of lower level

development tasks (as dictated by those with experience to judge) to

encourage people to enter the development cycle.  of course, there

will be a large attrition rate, most people like the idea but can't

stick the learning curve.  others may be intelligent and able but less

confident and just need pointed in the right direction.
obviously the intention should be to try and capture the latter without

loosing energy on the former.

On 2007 Oct 31, at 8:01 AM, ttw+bsd@cobbled.net wrote:
 > surely there  must be _some_ merit  to creating a list  of lower

 > level development tasks (as dictated by those with experience to

 > judge) to encourage people to enter the development cycle.
First,  you're  assuming that  there  exists  amongst the  OpenBSD

developers a desire ``to encourage people to enter the development

cycle.'' I kinda doubt that that's the case. More developers often

isn't a good  thing; see ``The Mythical Man-Month''  for a popular

treament of the problem.
But,  if you're  serious,  one good  way would  be  to follow  the

changes made to the code -- after all, that's the whole point of a

public CVS repository. When you find  something that you can point

to and  say, ``I know  why so-and-so did  that,'' then you  can go

looking  for  other  things  that  would  benefit  from  the  same

treatment.
And if  you don't understand why  the changes are being  made, you

need to improve your coding skills to the point that you do.
Cheers,
b&
[demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]

The most amusing thing about this thread is that such a list has been

published for years (it's somewhat short right now, but there's some

simple stuff in it) and is the first search hit when you search on one

of the obvious queries on google.
//art

On 31.10-16:44, Artur Grabowski wrote:
i didn't find it on google (i am a google retard), if you post me the

link not only will i offer to maintain it for the developers but will

endeavour to link-up with the website team to ensure it is easily

found.
--

        t

 t

                 w

Unless I'm very mistaken what art was talking about is even linked

from the www.openbsd.org front page.
This discussion begs the question: Why is it so important to find

handholding to start kernel hacking?  Kernel hacking isn't for

everyone, and as far as I can tell it isn't necessarily such a

glorious existence either.  The only way to find out if it /is/ for

you, is the hard way: Put in the time needed to understand how to

solve a particular problem, code your fix and submit the patch to

tech@. If you do manage to put together a halfway useful patch and

post it on tech@, you will get some measure of feedback.  How you

respond to that feedback will help determine if you are cut out for

kernel hacking.
And again, why focus narrowly on the kernel?  There's a whole base

system out there, and it would be deeply unfair to forget about

packages.
And of course, if your coding skills aren't all that hot, there are

several types of activities that would benefit the project which may

not even involve contributing code.
--

Peter N. M. Hansteen, member of the first RFC 1149 implementation team

http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/

"Remember to set the evil bit on all malicious network traffic"

delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

you're mistaken. :) art was talking about searching for "openbsd todo list".

list".
the term "openbsd todo" came up with the following link at art@'s

website:
http://www.blahonga.org/~art/openbsd/todo.html.
If someone's looking for things to do, try those.
-0-
--

This is the ____LAST time I take travel suggestions from Ray Bradbury!

For anyone still searching for art@'s mystical, elusive list, here's how

to find it...
                 G o o g l e
[OpenBSD_TODO_____________________________________]

  ^   [ Google Search ] [ I'm Feeling Lucky ]

  |                              ^

  |                              |

1. type here                  2. click here
--

Darrin Chandler            |  Phoenix BSD User Group  |  MetaBUG

dwchandler@stilyagin.com   |  http://phxbug.org/      |  http://metabug.org/

http://www.stilyagin.com/  |  Daemons in the Desert   |  Global BUG Federation

Surely they are too busy whining at us for lists, to actually search

for the lists.
I'll say it again more clearly -- all of you whiners just plain suck.

We know you'll never write diffs, and it is up to you to prove us

wrong.  If you don't write diffs, we have a difficult time feeling any

loss.

Who do you mean with whiners? People who report bugs? Those people save you

work, because instead of having to run time-consuming tests to find the
I fixed some bugs in BRL-CAD (a 30 year old oldschool C-only 3D modelling

system from the US Army) because BRL-CAD people are friendly and helpful.

Instead of "you suck", they tell you "this XX you wrote cannot work because of

YY".
I asked here for janitor list, got a reply that it doesn't exist. I looked

into the PR database into documentation section but there were 0 hits. I looked

into other sections but that seemed to be complicated, I don't want to invest

significant time into learning OpenBSD internals at the moment.

In the quoted sentence "Surely they are too busy whining at us for

lists, to actually search for the lists", Theo appears to refer to

people who are too busy whining at the devlopers for lists, to

actually search for the lists.

The problem is that people have limited spare time to look into

OpenBSD matters, and these threads often don't result in much happening.
Sending bug reports and such information is of course useful, but isn't
Try fix something that bothers you, that is the way most people get

involved.  In terms of kernel code, drivers are mostly seperate from

everything else and don't require an understanding of all the internals

to work on.

On 31.10-09:49, Theo de Raadt wrote:
a software community is made of more than developers.
--

        t

 t

                 w

Clearly, you have no idea what represents the OpenBSD community then.

Pardon me - but isn't this specific thread about newbie developers?
--

"This officer's men seem to follow him merely out of idle curiosity."

-- Sandhurst officer cadet evaluation.

http://www.youtube.com/watch?v=tGvHNNOLnCk

Yes, a software community needs a logo, a wiki and mailing list.

There is no need for developers if the comunity can write mails, change

the wiki and hold logo contests from time to time. The code will

materialize himself -- it is as simple as saying "let there be code" and

there will be code.

What hinders you to start looking at interesting spots in the OpenBSD

source code and send in diffs for stuff you found and think their wrong?

Hmm....

Yeah, sounds like work!

"we appear to have people who can code"
we do?
the source code is out there.
the problem is not our lists.
it is motivation.  the minute they are motivated to stop whining and

actually look in the code, then they might do something useful.
if you wanted us to not lose energy, a lot of you would have shut up

and started looking at the source a couple messages ago.

On 31.10-10:05, Theo de Raadt wrote:
where you get the "your fault" from is unfathomable.  neither is anyone

suggesting that the problem is "our lists", simply that a list of

"simpler" tasks _may_ encourage younger/new developers to participate.
anyway, this really is taking me away from coding now so i'm going to

drop off and let us all get back to something productive.
p.s: i started looking at the source code some weeks ago.  i'm a

good way from having a handle on it

--

        t

 t

                 w

as opposed to a majority of people who talk and not code anything?

here is a solution for you -- read http://openbsd.org/query-pr.html

and start fixing those. pretty simple solution if you get no bugs

of your own.

cu

--

    paranoic mickey       (my employers have changed but, the name has remained)

Good point.

I was wondering what to do next, once/if I can finish fixing a wi

driver issue...
Let me raise one question... There are quite a few books written about how

certain things work on a kernel level, but they're for other operating systems.
If we had such documentation, even if it isn't kept up-to-date, it would be a

start point. As I stated in an earlier message, OpenBSD code is very, very

readable. It could be used in lots of college classes around the world. A

book could provide an additional way to fund the project. Obviously, it is not

an easy task, particularly from the commercial side. Deals would have to

be made and they tend to be more attractive to the publisher side....

for one thing, it would always be out of date.
and the thing people need to learn is not specifics, but principles.

not so much priniciples of operating system development (though that

is important), but openbsd principles.
take pf.  every release it does more, but the principle is that it

should be as simple as possible.  this principle is more important

than any discussion of binary trees vs hash tables vs cryptographic

checksums or whatnot.

start writing a book then...

cu

--

    paranoic mickey       (my employers have changed but, the name has remained)

On Wed, 2007-10-31 at 13:41 -0200, Marcus Andree wrote:
Design and Implementation of the 4.4. BSD Operating System

On 31.10-15:25, mickey wrote:
anyone, who thinks that learning and development need nothing more

than web web access to PR database is mistaken.  development is a

complex process, one that requires a great number of things not least

which is an idea of where to start.
one can also look to the large numbers of patches that are created

but never used (yes this is complicated network of reasons too).
why must we railroad ourselves to a decision before the discussion

has even happened?  it would appear that most do not want the discussion

to happen even though they are neither obligated to participate or

action the ideas within it.  that is strange to me but as i've said,

i'm new.
--

        t

 t

                 w

mickey gave you a place to start. i know of at least one developer who
you should read the mail archives for this "discussion that has never

happened". you're not the first to write a mail in this vein.
just start using the system. if it suits you, stick with it. when you

find a problem, try and fix it. everything you need is there, if you

look.
or think of another way to contribute. just buying CDs and t-shirts helps.
jmc

yes development of yourself is a complex process

to which only yourself can do any help (or harm).

nobody here is your mother and will not do anything

about what you want to get. get it yourself!

cu
--

    paranoic mickey       (my employers have changed but, the name has remained)

the discussion has already happened.  many times. you missed it.