[U-Boot] Mainlining android fastboot support to upstream u-boot

[Wolfgang Denk]

Dear John Rigby,

In message <BANLkTikMfdknySqnOe6KvGJpdK2bUxtiVQ at mail.gmail.com> you wrote:
>
> > If you are discussing requirements for U-Boot, and plan to get these
> > merged in to mainlineU-Boot one day, it would probably be a good idea
> > to discuss these plans on the U-Boot mailing list as well - ideally
> > before any design is cast in iron.
...

> As you can see from this discussion, Linaro is considering applying
> resources (probably me) to upstreaming Android Fastboot features into
> mainline u-boot.  What suggestions do you have for making this process
> as painless as possible?

I already wrote this above: discuss the _design_ early with the
respective community. Don't define some design and implement it and
then confront the community with your solution which you consider
ready at this point: this is guaranteed to cause frustration, because
you think you are done but we may think the design should be done
differently and ask you to restart from scratch.

> An implementation exists for omap4/panda on gitorious:
> git://gitorious.org/pandaboard/u-boot.git in the omap4_panda_es2.0
> branch.  There is also a version for omap3 somewhere else on
> gitorious.

Ah, cool.  So we already have the situation I warned about above.

> To bring this to mainline one would have to:
> 
> 1) Bring code up to current mainline revision.
> 2) Fix any coding standards issues.
> 3) Document the new features.
> 
> What else?  I know one issue maybe why does this need to exist when
> other solutions exist.  I think that since Android uses it, it is
> somewhat of a de facto standard.
 
Oh. Android uses it. It must be The Right Thing (TM), then, I guess.
Probably like some of the Linux kernel code they use.

This is the killer argument I really like. Thank you very much.

I don't exactly feel motivated to accept just any stuff just because
company A or project B uses it (even if they appear to be really
big), or because already lots of efforts have been spent to implement
something.  On contrary.  Usually an argumentation like that means
that the design or the implementation are poor. Often both are.

It's 14 years or so that ESR formulated the RERO principle of
software development; one could really think this is time enough to
sink in.  Alas, I know I'm an optimist...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It's not an optical illusion, it just looks like one.   -- Phil White