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

Wolfgang Denk wd at denx.de
Wed Oct 11 22:10:47 CEST 2006


In message <528646bc0610110830k7f29ab8jf319886dfa98683b at mail.gmail.com> you wrote:
>
> 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.

Agreed.  Will  they  also  take  responsibility  to  answer   related
questions here on the list?

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

Many of the users (at least many of those I have to deal with)  don't
use any SCM, at least not to work with the U-Boot code. Many of them
just download a snapshot, typically a tarball from the FTP server.

The CHANGELOG file is important for such users to know what's  there;
I"m usually happy if they know how to run "diff" against two versions
of  that  file to see what was changed :-( For me it's also important
as I've seen quite a number of situations where  the  CHANGELOG  file
was  the  only  way  to  reliably  identify  which  exact  version  a
(modified) tree was branched off.

I agree that we don't need it as long  as  everybody  has  an  intact
repository  available.  Unfortunately this is not always the case. At
least not with the people I have to deal with :-(

Finally, I find it much faster to grep in the CHANGELOG than  to  run
"git log" and search in the output.


Maybe there is a clever way to auto-generate the CHANGELOG  from  the
commit  message;  I  tried  this  once and failed. Ummm... just tried
again and found that it's actually working  when  I  use  git-commit;
however,  it  seems  that cg-commit does not run the pre-commit hook.
Maybe a cogito issue. I'll ask...


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

I understand your argument. But I'd rather have that we were all able
to see the code  we're  discussing  without  need  to  clone  another
repository  and to analyze what they changed and why, and which parts
of this are intended for mainstream and which not,  and  which  parts
are ready or incomplete or under work. It's like the netiquette rules
for  quoting  when  replying to a message: it gives you some context.
With a repo somewhere else it's  IMHO  more  difficult  to  get  such
context  than  when  you can reply to a message with a patch included
and simply quote the relevant parts of that patch.

Maybe I'm not flexible enough, but I'd really prefer if  the  patches
we're discussing have been posted to this list before.

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

You are right. Maybe we should just try how it works.

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

No, this is actually not what I want. I'm interested  to  reach  some
agreement  we  all  can  live  with.  If  you  (and others?) think my
position is unreasonable I would at least like to understand  why.  I
don't  promise  to  change my mind ;-), but I do promise to seriously
consider your arguments.

git makes it easy to generate and send patches, so what's wrong  with
asking  that  such patches have been posted here? At least this makes
clear what this specific patch is intended for.

Also, it makes sure this stuff is archived somewhere.  Such  external
repositories tend to disappear without notice, and I would like to be
able to track down history any time later.

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
Man is the best computer we can put aboard a spacecraft ...  and  the
only one that can be mass produced with unskilled labor.
                                                  - Wernher von Braun




More information about the U-Boot mailing list