a simple request: apply all outstanding patches.
Rob Landley
rob at landley.net
Thu May 18 14:18:46 UTC 2006
On Thursday 18 May 2006 2:46 am, Rob Sullivan wrote:
> I think it's important to remember that most people here tend to have
> other developing jobs besides Busybox too, so we need to spread the
> load a little, or at least change the process by which Busybox is
> developed. That can mean more people, or it can simply mean greater
> efficiency; if a *good* bugtracker is set up, it should be so logical
> and useful that people will actually want to use it, and will easily
> be able to do so. The current mailing list patch submission system
> works, but its most obvious flaw is that it doesn't do the "tracking"
> part of bugtracking - only the reporting and fixing parts.
>
> Surely there must be some OSS project out there that has been through
> the same situation and found/wrote a decent bugtracker...
The problem isn't a bug tracker. Lots of patches I see either need cleanup
(#ifdef removal), have a bug that needs squashing, have some subtle
interaction with obscure platforms (like nommu) or planned upcomming work,
could be made obviously smaller (well, obviously to me), or are just
generally "I see what you're trying to do but I think _this_ would be a
better solution"...
If we had more people doing _that_ kind of review, life would be good. It's
why BusyBox is so small. Unfortunately, the number of people who can do it
are also small, and the number of people willing to is even smaller. (When I
tarted doing busybox development, Erik, Manuel, and Glenn were all optimizing
the patches that came in.) I've tried to write documentation (the
Programming section of http://www.busybox.net/FAQ.html) to help, but so far
what I've got there is introductory material at best...
Some of it's design. For example, if I'd ported hdparm to busybox I'd have
started without about 3 features and then added more as people complained
about their absence. I think that the limitation of having more than 26
options is a design problem with hdparm rather than a problem with
bb_getopt_ulflags(). (And the phrase "the real hdparm" coming up in
conversation is symptomatic. People need a tool that pokes at their hard
drive, and they expect a certain user interface. But usually I don't look at
the old implementation at ALL if I can avoid it. I look at the man page and
the specification, and I think "what's the minimum amount of code I can get
away with implementing"...)
Yesterday a marvelous patch for mdev.c came in adding shellout support.
Except it's not configurable, and it adds a flag to conditionally disable
some behavior in make_device which is the wrong way to go about it; it would
be better to break make_device into two functions so we could call what we
needed with fewer ifs in the code. So at the very least I have to refactor
that, and add configuration markup. The end result should be smaller,
although I have to test with make bloatcheck to be sure... (I _love_ that
tool, by the way. Saves me lots of poring over make sizes output, which is
another command I added because I was sick of running nm --size-sort by hand,
which is a trick I got from Manuel Nova way back when...)
The patches I just have to read and apply unmodified, which don't even raise a
design issue, are the easy ones.
Rob
--
Never bet against the cheap plastic solution.
More information about the busybox
mailing list