[BusyBox] Division of work.

[Mark Whitley]

A few belated replies...

On Tue, Mar 06, 2001 at 02:12:09PM -0500, Gennady Feldman wrote:
> On Fri, 2 Mar 2001, Mark Whitley wrote:
> 
> > Lemme tell ya what Erik and I have discussed, mingled with what ideas from
> > folks on the mailing list, and further mingled with stuff I would like to see:
> >
> >  - Leave networking apps in busybox (i.e. no netkit-tiny as we had previously
> >    announced)
>   Are we going to get rid of netkit-tiny CVS branch, mailing
> list(s),etc..?

Yep. Right after the 0.50 release.

> >  - Merge tinylogin into busybox. (I would like to see this happen, but opinion
> >    is divided.)
> >
> 	TinyLogin and netkit-tiny will need +s in order to operate
> properly, which is another thing to consider. And from the previous
> discussions it seems that this issue is still open.

One of the things Erik and I have discussed is converting the 'enum Location'
set into a more general-purpose 'flags' listing, which would allow us to add
an entry called _BB_DROP_PERMS to all of the applets that need to be +s. Then,
in busybox_main we would have code like tinylogin that tests if that bit is
set and drops permissions accordingly

While I'm on the topic of merging tinylogin, I also think it would be a good
idea to merge it into Busybox, because Busybox is much more actively developed
while tinylogin is kind of stagnant. Merging it with Busybox would (hopefully)
give it more attention.

> >  - Possibly create subdirectories for logical groups (i.e. fileutils,
> >    shellutils, netutils, loginutils, etc.). Undecided as to which
> >    subdirectories will be made, or whether we will do it at all.
> >
> 	I think that a lot of people on this list were for creating
> separate branches and maybe even having certain people track those
> branches and update CVS, review patches, etc..

I know a number of people on the list favored the idea of subdirs for grouping
applets, but I didn't hear too much vocal support for a "subdir maintainer"
type of arrangement.

> >  - Turn utility.c into libbusybox.
> 	This is probably a good idea, but we might need 2 options: dynamic
> and static linking. Esp. if we can link everything into 1 binary file
> (login+busybox+netkit)

Yep. Supporting both dynamic and static linking will be a priority.

> >  - No new configuration system. The preprocessor-based one works well enough
> >    for all involved.
> 	I am currently working through the changes in configuration and
> macros. (Feedback on new layout coming soon)

Cool. I'd like to see it when it's to a presentable stage.

> I am also reviving my syslogd Circular buffer patch for the "new" version of
> busybox. Anybody willing to test it? The only thing I am not sure is that I
> use shared memory in my code to contain/hold the buffer which might not be
> portable, but then again you can turn that feature off.

Erik is probably the best one to review that patch.

> >  - Auto-generate SGML documentation from usage.h. This means the examples in
> >    the current docs will be grafted into usage.h. (Don't worry, you'll still
> >    be able to leave them out of the binary.) I'll be working on this as I find
> >    time. The autodocifier.pl script in docs/ and written by John Beppu is a
> >    great help for getting us there.
> >
> 	Actually one nice thing we could try to do is to use a syntax
> similar to javadoc. I remember that I was really impressed when I was
> using Java for some of my work. Essentially programmers need to comment
> their code and with a bit of "magic tokens" we can extract and format
> those comments into HTML documentation or some other format.

Yes, I'm familiar with Javadoc. I actually proposed the idea of generating
documentation from sources. The reasons for not taking the javadoc-type of
approach is because 90+% of what we need to put in the documentation is
already in utility.h. (It's also a little hard to get everyone to go along
with the "documentation mingled with source code" idea. See "herding cats",
below.)

If you want to press the case for javadoc-style documentation, you're welcome
to do so...

> >  - Applets will not be assigned. (This turned out to be an unpopular idea.)
> >    Instead, people can voluntarily speak up if they want maintain a particular
> >    applet. A person who does the initial write / rewrite of an applet gets
> >    first dibs on being the maintainer. If an applet is unowned but somebody
> >    has made numerous edits to it and is familiar with the codebase, they're
> >    probably best qualified to be the maintainer and are encouraged to speak up
> >    if they want to be maintainer.
> >
> 	Actually I propose to have people maintain branches to help out
> "applet writers" with proof-checking the code and checking for style-rules
> and such things.

It's a great idea in theory, but it's just hard to get volunteers on a Free
Software project organized to that degree. (You've heard the saying about
"herding cats"?) On the other hand, if _you're_ volunteering to do proof &
style checking... well, we'd love to have your help. Send patches to the
mailing list and I'll look at 'em.

> Btw, nice work on style-guide (maybe we should post it on
> the website? together w/ other text files?)

All the docs in the Busybox source tree can be browsed on-line right here:

	http://busybox.net/cgi-bin/cvsweb/busybox/

> >  - We're not going to do any of this until 0.50 is out the door. Which reminds
> >    me: we'd like to get 0.50 out the door pretty soon. I've been trying to
> >    triage the bug list to help make this happen. If there are any bugs that
> >    anyone would like to see fixed before 0.50, please speak up now.
> >
> 	When is 0.50 scheduled for release?

Glad you asked. Erik has told me that he would like to get it released today.
I think we've got most of the big, glaring bugs fixed and I don't think there
are any on the buglist that should hold up the release. Anyone who feels
differently is invited to speak up now. Patches to fix any open bug reports
are, as always, welcome.


Mark Whitley
markw at lineo.com