RE: [LinuxBIOS] lnxi-merge complete

[Lu, Yinghai]

Don't block me, I never broke the code.

YH

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stefan Reinauer
Sent: Wednesday, October 26, 2005 8:15 AM
To: Jason Schildt
Cc: [e-mail]
Subject: Re: [LinuxBIOS] lnxi-merge complete

* Jason Schildt  [051026 00:14]:
> All,
>
> The LNXI mega patch merge is complete.  Note that lnxi-patch-14 and 16
> were not committed.  #14 was ommitted because it was no longer

relevant
> due to the apic_id lifting.  #16 was ommitted because it wasn't all

that
> important and it needs to be regenerated before we commit.  I will

make
> necessary comments on Issue Tracker next.
> Thanks for being patient.
> Regards,

I don't think this can be considered complete. All builds are broken at
the moment except the arima hdama.

There needs to be more to it than just code reviews. If nothing else
helps I will block commits that break any compiling target.

Stefan

[LinuxBIOS] lnxi-merge complete

"Lu, Yinghai"  writes:
> Don't block me, I never broke the code.

I totally object to the tone of this response.

This shouldn't be about blocking anyone but about what things
we can do to make the process work better for everyone.  What
tools can we build that will cut down on the number of brown
paper bag incidents.

A checkin hook that calls abuild.sh and ensures everything succeeds
may be one way to stop build problem from ever being checked in.
Which is what I believe Stefan was suggesting.

Completely blocking people will make the problem worse as merges
won't happen and the patch pressure will just build up.  Or else
changes will get dropped.

Eric

[LinuxBIOS] lnxi-merge complete

[Stefan Reinauer]

* Eric W. Biederman  [051026 19:02]:
> A checkin hook that calls abuild.sh and ensures everything succeeds
> may be one way to stop build problem from ever being checked in.
> Which is what I believe Stefan was suggesting.

Exactly.

Bad idea?

Stefan

[LinuxBIOS] lnxi-merge complete

Stefan Reinauer  writes:
> Eric W. Biederman  [051026 19:02]:
> > A checkin hook that calls abuild.sh and ensures everything succeeds
> > may be one way to stop build problem from ever being checked in.
> > Which is what I believe Stefan was suggesting.
>
> Exactly.
>
> Bad idea?

Nope.  I don't think so.

I think abuild.sh will need some improvements so it can build all of the
boards, and this won't replace code reviews.

Eric

[LinuxBIOS] lnxi-merge complete

[Stefan Reinauer]

* 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

[Ronald G Minnich]

Stefan Reinauer wrote:
> Eric W. Biederman  [051026 19:02]:
> > A checkin hook that calls abuild.sh and ensures everything succeeds
> > may be one way to stop build problem from ever being checked in.
> > Which is what I believe Stefan was suggesting.
>
> Exactly.
>
> Bad idea?

it's ok as long as we can cover the cross-compile case.

ron

[LinuxBIOS] lnxi-merge complete

[Ronald G Minnich]

we might want to have a release tree and a devel tree, though. We've got 
to get out of this 'break it for everyone' release cycle.

ron

[LinuxBIOS] lnxi-merge complete

[Richard Smith]

On 10/26/05, Ronald G Minnich  wrote:
> we might want to have a release tree and a devel tree, though. We've got
> to get out of this 'break it for everyone' release cycle.

I think I'd call it more of a merge rather than a release.  And I
think the breakage is to be expected.  This is really complex stuff. 
The issues are more about how do you manage the breakage and how to
you make the pieces easy to pick up.

I suggested multi trees earlier but YH thought that it might be too
much work.  I use the multi-tree method a lot now that I've (mostly)
moved over to DARCS and doing trees is easy.

Seperate  dev and release trees (or branches) just seem to make sense
and examples of them are all over the place.

If patches are kept well defined and focused then I don't see a lot of
extra work since they should apply to a copy of the developers
internal tree with minimal fixups.

If they don't apply easily then thats a warning flag and things need
to be looked at.