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

[Grant Likely]

On 10/10/06, Wolfgang Denk <wd at denx.de> wrote:
> In message <528646bc0610100013h7a7fd1d3pe66473431000dc28 at mail.gmail.com> you wrote:
> >
> > Where then should I take discussion that is directly related to
> > improving the quality of the flattened device tree code held in that
> > tree?  Would you really prefer that discussion to be taken off line
>
> No, definitely not. Discussing the stuff  here  is  just  fine.  Also
> posting  patches  here is fine (and the only "official" way for patch
> submissions so far).

Ok, which leads to the issue of which patches are allowed to be posted here.

>
> > and then a full patch set be dumped on the mailing list wholesale?
>
> If this is a clean set of patches this is just fine with me. Actually
> this is the current "official" way to do it. Even if  you  provide  a
> git  repo for easy merging, you are still required to post the set of
> patches here on the list so everybody can see and discuss these.
>
> It is MUCH easier to review a patch than analyzing what might have
> been change in another repo.

Agreed

> > The fdt support patches are non-trivial.  You've already rejected them
> > here.  Why do you want to eliminate an effort to improve them from
> > this list?
>
> I definitely don't want to do this.
>
> 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.

>
> If  you  find  a  problem  with  the  code,  then  post  a  follow-up
> (eventually  including an incremental patch) against a patch that was
> posted here on this mailing list.

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).

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
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.

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?

Cheers,
g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195