Gerardo Santana Gsmez Garrido wrote:
2007/10/30, Miod Vallat <[EMAIL PROTECTED]>:
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.
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
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.
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
