[U-Boot-Users] [PATCH] Fix possible uninitialized variable compiler warning.

[Wolfgang Denk]

In message <528646bc0610102309j6fcf7ed4n74e6af179d21f42b at mail.gmail.com> you wrote:
>
> Ok, which leads to the issue of which patches are allowed to be posted here.

Patches against the "official" U-Boot source tree. 

> > But on the other hand, I think it makes no sense if we start posting
> > patches here that are against N private repositories somewhere else.
> 
> And this is where we diverge.  Why not?  Many other projects do so,
> the Linux kernel being the most notable example.

Why not? I want to have the information all in one place, and not
scattered around in hundrets of unrelated repositories, all in a
different state, all with diferent problems and issues to track.

> The whole point of git is that we *can* develop features off of
> mainline in N private repos and easily merge them back in when they
> are ready.  The off-mainline work needs peer-review just as much as
> patches for mainline (especially when they're my patches).  As you
> agree, patches to the mailing list is the easiest way to discuss
> changes, but they don't always directly map to an increment to another
> patch.  Once the off-mainline tree is ready, a patch can easily be
> generated that describes the sum of changes.  Individual commits don't
> matter, only the sum of commits (for a single off-mainline tree).

This assumes that the "other" repository is kept in  a  clean  state,
but  this  is  usually  not  the case. What happens is this: somebody
starts working in his own repo, and does so for a long  time  without
review  on  the  list. Over time, a lot of problems in his code sneak
in. When he finally announces his repo and ask to have it merged into
the public tree he says: Ummm, now it's too late,  it  would  be  too
much  work  to  fix  all  these  issues and to re-do all the checkins
[remember the case of the missing CHANGELOG entries in Jon's  tree  -
this  cannot  be  fixed  afterwards as these have to be done for each
checkin].

> Also, I think your contradicting your original statement:
> 
> > > > Please do NOT post patches here against code that is not in the
> > > > official source tree"
> 
> Are you saying that patches to non-mainline code is only acceptable if
> it's are reply to a mainline patch?  That seems rather arbitrary to
> me.  What if I have a change that builds on an off-mainline tree; but
> isn't a bug fix or enhancement.  (for instance; I'm working on fdt

Ummm... I don't understand. If it's neither a fix nor an  enhancement
I  see  no  need for a change at all ;-) And if it's againt someboidy
else's tree, then please discuss it with the maintainer of that tree.

> support for the 5200; it builds on the fdt support that isn't in
> mainline, but it isn't a change to it).  The off mainline tree is not
> yet accepted for merging, but I still want to get my changes out there
> for others to see/comment on.

It's simple: if you cange code that's in the "official" tree, then
post patches here. Maybe even patches on top of other patches that
have been posted here.

If you are using some other repository, then please discuss this with
the maintainer of this other repo. I'm not willing to comment on code
which is unknown to me.

> Surely we can come to a compromise on this.  Can we agree on a way to
> label non-mainline patches so that it is *explicit* that they are not
> for mainline?

If the patches that lead to this "non-mainline" tree  have  not  been
posted   here  before,  I  don't  want  to  see  discussion  of  this
"non-mainline" tree here either.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"If you'll excuse me a minute, I'm going to have a cup of coffee."
- broadcast from Apollo 11's LEM, "Eagle", to Johnson  Space  Center,
Houston July 20, 1969, 7:27 P.M.