RE: [LinuxBIOS] lnxi-merge complete

[Lu, Yinghai]

I don't think two trees are needed, that will create more work.

I mean every committer must not break the current code at least it can
compile through before the commit can be made. Just need he to spend 5
more minutes to double check it.

YH

-----Original Message-----
From: Stefan Reinauer [mailto:[e-mail]] 
Sent: Wednesday, October 26, 2005 10:47 AM
To: Eric W. Biederman
Cc: Lu, Yinghai; Jason Schildt; [e-mail]
Subject: Re: [LinuxBIOS] lnxi-merge complete

* Eric W. Biederman  [051026 19:35]:
> > Bad idea?
>
> Nope.  I don't think so.

Richard's objection that a checkin will take a couple of minutes more is
true though. This might become annoying.

Sounds like we really might want a development tree and a stable tree
and have a 2 step process for merging into stable. But then again I see
it coming that noone will really use the stable tree as it is the least
common denominator
> I think abuild.sh will need some improvements so it can build all of

the
> boards, and this won't replace code reviews.

Or fixing the build process might help. Image sizes are really
sensitive and get adjusted from time to time. This looks wrong to me.
The image size is something that I might want to decide when everything
built correctly and I compose the final image.
Then abuild might check and tell "minimum image size: 512k" or whatever
but not just fail.

As for the code reviews you are completely right. Code quality is
nothing that can be ensured by a bunch of automated tools. 
But it can't be guaranteed by code reviews either, since even by careful
looking I can't guess if a certain piece of code will actually compile
unless it is reaaally nasty stuff.

We all agree that the LNXI merge is a good thing, but it is causing us
a little headache now and then. Nothing to worry, nor to argue about - 
but still something that needs a little fixup.

Do you have a time frame for getting things into shape, or shall anyone
else try to fix up their own builds? (I'd prefer the first ;))

Stefan

[LinuxBIOS] lnxi-merge complete

[Richard Smith]

On 10/26/05, Lu, Yinghai  wrote:
> I don't think two trees are needed, that will create more work.

I see that I sent my reply only to Stefan rather than the list. Oops. 
Gotta quit cranking out e-mails right before lunch *grin*
> I mean every committer must not break the current code at least it can
> compile through before the commit can be made. Just need he to spend 5
> more minutes to double check it.

Well the trick here is how to do this effectively across the board. 
Can any one developer be effective at dealing with all the chips
supported and platforms supported?  And how far can you run this
before you swamp a developer?  Its LB's goals to try and expand the
number of chipsets we support right?

Consider that in the power-pc or ARM cross-compile setup the compiler
may not even be installed on the developers system.  Making it really
hard to verify if you broke things.

And even if the code compiles that's still only the first step.  Those
are the _easy_ fixes. Its when you tickle a subtle hardware bug that
things will get icky.

Things like autobuilders and code reviews are big helps but ultimately
somebody has got to try and compile and run the code on the hardware
and do some tests.  The best person for that job is a developer
working on that platform.  And for that to happen the patches have to
be available prior to commit.  In absence of a different tree then
perhaps there is an RFC period for patches?  A lot like the kernel
does.  Post the patch(s) let people mess with it and then apply them
when the developers for that platform are cool with the results.