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