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

[Grant Likely]

On 10/11/06, Wolfgang Denk <wd at denx.de> wrote:
> 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.
>
> > 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.

Who's talking about hundreds of unrelated repositories?  We're talking
about a handful of *related* repositories.  Plus, it must be
understood that if anyone uses a non-mainline tree, it is *their*
responsibility to keep that repo up to date.

Anyone who asks to merge an out of sync repo should rightly be flamed.

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

True, but that's not your issue.  Flame away when someone posts out of
date patches.  The holder of the non-mainline tree is responsible to
make sure his submissions to mainline are clean.

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

<digress>Why are you so concerned with a manual CHANGELOG file?  Isn't
that part of the reason to use a good scm?  Updating the Changelog by
hand is just busywork when the tool will generate changelog
information for you.</digress>

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

Which is what I want to do.  What I'm hearing from you is that I am
not welcome to do so on this list.  I respect the fact that you are
the maintainer of this list, and therefore can choose the list
policies.  However, I do think you are being short sighted in not
welcoming discussion that is indirectly related to mainline (ie. under
development, not ready for integration)

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

But you are not the only person on this list.  There are others who
are interested.

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

Thank you for making your position clear.  I think your position is
unreasonable and short sited, but this is your list and I will respect
how you want to run it.

Cheers,
g.

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