[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Was 2.9, let's talk 3.0



There are actually a few things that I would like to see improved in the
system, but it's very hard to get a very clear plan about them: half the
job is understanding the issues, and coming up with the correct design.

There are some compliance issues to grasp (have a C99 library).
There are some deficiencies (finding out what the hell ld.so does not that
breaks mozilla)
There are some completely unimplemented features that would be handy (locales).

And then, there's ongoing work (bsd.port.mk, make, pkg_*).

The order in which things are done highly depend on the release schedule.
make just got bumped through 1 year of development, in order for all the
potential problems to be fixed before the next release.

I hope to have some bugs fixed, and some better pkg_* infrastructure
finished before 2.10/3.0 (2.9 is already a huge step compared to 2.8).

IF you want to help, a very, very large part of what you can do is take
up maintenance work. There IS a very small team that handles an
astoundingly large part of the system. There are just a few kernel
developers. The ports team is amazingly small compared to the number of
ports.

Turning out complete ports, without bugs, helps.

Testing out ports and patches helps as well.

Doing small source contributions help.

In general, doing the very menial work that's needed to make the project
work frees developers from doing other things.

Note that there is no actual `hierarchy' of developers. Everyone does
things according to his likes/disklikes and skills. But every developer
who contributes a lot to OpenBSD (say, over 500 commits) DOES a large
proportion of menial work that requires little technical skill.

This means that there is ample room for fledgling developers to come
aboard, and `grow' with the project.

ALL CURRENT DEVELOPERS HAVE COME ABOARD ALONG THE SAME PATTERN:
- install OpenBSD,
- look throughout the system, learn parts and pieces,
- find an area you don't like, or would like to improve,
- DO IT.


e.g., all developers are people who sent CONCRETE patches at some point in
the past. Not bla, bla, bla on a mailing-list, but actual code, or VERY
concrete suggestions (this manpage is inaccurate. A file that would say
such and such would be cool, should I write it ?)