oh, wow, what a mess. There's a lot to fix still. We'll be looking at each of these in turn, to try to get them to build. The last batch of patches from people left the tree in a very unhealthy state.
We're going to have to watch this a lot more closely. If we can't improve the situation somehow, the only thing I can think of to do is limit people to sending in patches via the issue tracker, and shrinking the set of people who can commit down to a very small circle. Based on what I'm seeing here, the current setup is not working. I have not wanted to do this as we here at LANL don't have tons of free time to monitor patches, but the current situation can not continue.
I think the earlier suggestion, of requiring positive evidence that abuild works after a patch, might be right. only problem -- abulid is making mistakes. The digital logic msm586 bulid fails in abuild, and works fine otherwise. oops.
thanks
ron
I think the earlier suggestion, of requiring positive evidence that abuild works after a patch, might be right. only problem -- abulid is making mistakes. The digital logic msm586 bulid fails in abuild, and works fine otherwise. oops.
I think abuild should use the target config file as possible instead of generating its own unrealistic target.
Ollie
On 11/22/05, Li-Ta Lo ollie@lanl.gov wrote:
I think abuild should use the target config file as possible instead of generating its own unrealistic target.
yes, stepan, is that doable?
ron
* ron minnich rminnich@gmail.com [051123 06:13]:
On 11/22/05, Li-Ta Lo ollie@lanl.gov wrote:
I think abuild should use the target config file as possible instead of generating its own unrealistic target.yes, stepan, is that doable?
ron
Your approach of having a seperate abuild configuration file is a lot better since the target configuration files tend to be very specific and require certain payloads in certain very developer specific locations.
We could check a couple of binary payloads in the tree or into a different tree that is supposed to sit next to LinuxBIOSv2 or something and have that referenced by default so we don't have to use /dev/null or /etc/hosts as payload.
Stefan
* ron minnich rminnich@gmail.com [051123 05:55]:
oh, wow, what a mess. There's a lot to fix still. We'll be looking at each of these in turn, to try to get them to build. The last batch of patches from people left the tree in a very unhealthy state.
We're going to have to watch this a lot more closely. If we can't improve the situation somehow, the only thing I can think of to do is limit people to sending in patches via the issue tracker, and shrinking the set of people who can commit down to a very small circle. Based on what I'm seeing here, the current setup is not working. I have not wanted to do this as we here at LANL don't have tons of free time to monitor patches, but the current situation can not continue.
I think the earlier suggestion, of requiring positive evidence that abuild works after a patch, might be right. only problem -- abulid is making mistakes. The digital logic msm586 bulid fails in abuild, and works fine otherwise. oops.
This is mostly because abuild assumes a certain image size while some of the builds break if you choose a too small or too big image. IIRC the DL MSM586 breaks because it doesn't build with 512k rom images.
Stefan
Stefan Reinauer wrote:
This is mostly because abuild assumes a certain image size while some of the builds break if you choose a too small or too big image. IIRC the DL MSM586 breaks because it doesn't build with 512k rom images.
yes, but that still leads to false negatives. MSM586 builds on on 256K ROMs, and that's all that you can use anyway. See my later patch to abuild and see what you think.
ron
-
Li-Ta Lo -
ron minnich -
Ronald G Minnich -
Stefan Reinauer