svn commit: trunk/busybox: scripts

[Rob Landley]

On Saturday 13 May 2006 3:20 pm, Bernhard Fischer wrote:

> >You were pointing out "make help" breakage and recommending I adopt a
> >technique that wouldn't have caught the "make help" breakage.  This is why
> > I was confused.
>
> No, i wasn't suggesting this. I suggested two completely unrelated
> things:
>
> a) isolate patches to be checked in into a vanilla checkout and *test*
>   your changes.

I do test my changes.  The tests unfortunately don't catch everything.  That's 
why it's called a development branch.  When things change, things break.  A 
recent Rules.mak change from Mike broke the e2fsprogs build, and he's fixing 
it, and this is normal.

Would you like me to just send you all patches from now on so you can review 
and apply them?  Am I allowed to point and laugh when something you check in 
inevitably breaks something?

>   Checkin from this tested copy where only 1 change lives.

So I'd be checking in at most one change per day then?

>   This avoids leaking unrelated stuff into trunk when comitting tested
>   patches.

Your current gripe, once again, is not about leaking.  Your current gripe is 
that shuffling the debug flags around led to a condition where they're not 
set appropriately, although the code built out of tree and the test suite ran 
against it.  Will taking extra steps to prevent unrelated changes from 
leaking into the busybox tree also address the US budget deficit and the rise 
in oil prices?

> b) If you want to checking stuff which is *not* tested (like r15043

Bernhard?  You're not helping your case here.  "There was something wrong with 
it" is not the same as "you didn't do any testing on it at all".

> http://busybox.net/cgi-bin/viewcvs.cgi/trunk/busybox/Rules.mak?rev=15043&r1
>=15038&r2=15043 which results in a completely unoptimized thus useless
> binary)
>   or is not finished, then create you own branch:

You mean stop applying stuff to the original branch, so that the development 
tree becomes about as useful as your -stable cvs branch which simply isn't 
what releases are cut from?

I can do that.  I can even combine it with the suggestion that I email you 
each change as I apply it to my tree, so you can see if you want to apply it 
to your tree.  I wouldn't recommend going there, but if you're insistent 
enough I could set it up.

I realize you want me to change how I work to a way that makes you happy.  The 
way you want me to work is considerably more work for me without noticeable 
benefit.  It would not actually directly address the last two problems you've 
brought up as justifications for doing it.  I set up a script to check out 
and test clean copies of the public tree.  This wasn't good enough for you.

>   svn cp svn+ssh://busybox.net/trunk svn+ssh://busybox.net/branches/rob
>   and check in the unfinished work in your "rob" branch there.

In that case I would stop updating the other branch, and would cut releases 
from the new one.  I've mentioned this before, I pay attention to one branch 
at a time.  If it would make you happier, I can do this.  Makes very little 
difference to me.  I'd have to figure out how to update where the nightly 
snapshots are generated from, and I think it's useless churn and kind of 
stupid.  But it's an option.

>   This avoids breaking trunk by checking in untested or unfinished
>   stuff.

Because I would no longer be checking anything into that tree.

I check stuff in when I'm not seeing any more bugs in it here, haven't got any 
more work I want to do with it.  If I wait too long to check stuff in it gets 
buried under other stuff.

I spent five hours driving to visit a friend friday, and five hours driving 
back sunday, and the time in between working on something other than busybox.  
As a result 40 new messages have accumulated in the busybox list that were 
_not_ cc'd to me, and of the ones cc'd to me I've already queued up a new 50k 
patch from Tito I need to review.

My testing on the tar coalesce writes patch found what might be a preexisting 
bug in busybox tar, that I need to track down and fix before I can apply 
that.  Then I need to review, test, and apply the tar uname/gname patch.  And 
_then_ I need to poke at tar's wildcard filename matching (have a window open 
with an old email about that.)  I also I have windows open on my desktop 
telling me to look at various older patches from tito, adding Elf segment 
garbage collection as a config option, endianness cleanups, a patch to let 
syslogd detect repeated messages, Shaun Jackman's lash patch, some pending 
cleanups for uclibc, Rich Felker's changes to 
bb_get_chomped_line_from_file(), tracking down Alexander Krause's problem 
with loop devices...  That's just the tip of the iceberg.  My busybox folder 
has 323 messages marked "unread", only 40 of which are actually new.  The 
rest I have to get back around to dealing with.

I work as fast as I can, and I review as best as I can, and I'm sorry that's 
not good enough for you, but if I'm not keeping up now how the heck am I 
supposed to switch to something slower and make it work?

I never _wanted_ to review and merge other people's patches, but NOBODY ELSE 
WOULD.  I have a huge list of busybox projects I'd rather be working on, and 
I'd love to be able to spend time on each one until it was a polished gem 
before anybody else saw it.  But I CAN'T KEEP UP _NOW_, let alone working 
more slowly.

This email's only as long as it is because I wrote most of it on the bus ride 
in to work this morning, when doing anything CPU-intensive (like compiling 
stuff) drains the battery pretty quickly.  And now, I have other things to 
do...

Rob
-- 
Never bet against the cheap plastic solution.