[U-Boot-Users] AT91 NAND om AT91SAM9260EK

[Ulf Samuelsson <ulf@atmel.com>]

> I promise that we will provide the infrastructure (git repos) for the
> custodians as fast as possible. As far as I can see,  at  the  moment
> this  affects  only  ARM  boards,  so please run this throught he ARM
> custodian then (Peter Pearse). If it's acceptable to him, and  nobody
> else complains, I will accept this, too.
>

OK, acceptable

>> > 2) That people make sure that they do not destroy the U-boot
>> >     support for at91 by providing untested patches.
>>
>> Well, I do agree that submitting totally untested patches is
>> unacceptable unless they are clearly marked as such. On the other
>> hand, it's also totally unreasonable to demand that people submitting
>> patches test them on boards they don't have.
>
> It's unreasonable, and impossible.

If you are working on, let's say, "common" files, then
you affect all boards, and then you should test on a reasonable subset.

If you enter and do significant modification on a file in the
board area, then I think things changes.
A contributor has no business changing  a board file
if he cannot reasonably verify that this will not break a board.

The same for files in the cpu/xxx directories.
You should not be changing those without testing on boards using that CPU.

If someone spends time to thoroughly test boards and has this included
in the mainstream, then anyone changing this code should be
aware that breaking this code has a price to end users.

Splitting a driver for a peripheral into several files just because
a few subroutined can be shared has a price
to the maintainer, since this will reduce the overview of the code.

A few kB of duplication is not a high price to pay for  working
U-Boot and easier maintenance.
If I look at the PowerPC/NIOS code, this is exactly how it is done.
Duplications in several areas.

>
> We have a pretty big selection of boards in our lab, but nevertheless
> I've never been able to test any  change  on  all  architectures  and
> boards. And nobody else will ever do that.
>
>> If someone submits a patch that's not fully tested, we'll just have to
>> test it before it enters mainline. It's really that simple.
>
> And actually in some cases we  will  simply  have  to  push  it  into
> mainline - in the past, there has often been very little of even zero
> feedback  for patches or test branches. Some people simply don't wake
> up before their board does not compile any more in the standard tree.
> I cannot help this, and we will definitely not wait to see an ACK for
> each and every board that is listed in the U-Boot tree.

No, but as mentioned above, different parts of U-Boot should require
the submitter to focus on different subsets of boards.

The proposed dataflash patches in our other heated discussion
for instance should only be accepted once proven that it actually
works with dataflash memory chips.
The proposer seemed to be happy if the stuff compiled...
Since that mainly affects Atmel boards, he should make
sure to get Atmel boards or sign up testers for it,
and have it tested before even thinking about submit patches.

It really does not make sense to test his patches only?
on boards which does not use the dataflash.

>
>


Best Regards
Ulf Samuelsson