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

They should.  If they do not, then the off-mainline tree is irrelevant
to those who lurk here.

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

Hopefully this is fixable.  It would certainly make developers lives
easier.  Alternately, can the changelog be generated at the time of
tarball extraction?  Of course, this would mean that the changelog no
longer exists in the git repo.  What are you using as a pre-commit
hook?

Jon, do you have any experience with this?

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

Fair enough.  However it is not always easy to do so.  Let's take
jdl's git tree as an example.  The patches in that tree have been
submitted to the mailing list over the last 6 months or so.  I don't
necessarily have that mailing list history in my inbox.  Nor would I
be familiar with those patches if I recently joined the ML.  Also,
additional patches have gone in overtop of the original patches so
which do I reply to?  Finally, while using git; if you apply a patch
off the mailing list in mbox format; it uses the subject line and
message body as the commit message.  In which case you don't want the
clutter of earlier patch fragments; those fragments are already in the
tree!

So, the question still remains "How do I provide the appropriate
context for an off-mainline patch?"

Some possible ideas:
1. Track down the original patch email.
- Context is inline
- labor intensive
- In many cases it doesn't really capture the context.  In the case of
a working tree like jdl's, because such a long period of time has gone
by, there is probably not a single logical patch to derive from.
Patches have since gone in on top of the original patch.  The context
has changed, and the patch is only relevant against the context of the
*sum of the changes*
2. Clearly label the patch as to which tree it applies to
- Context is implicit in the target tree; but not in the email.
- This assumes that the off-mainline maintainer/users are responsible
to respond.
3. Keep the patches off the mailing list entirely and wait for the
whole thing to be fully baked before reposting.
- Discussion does not happen on the ML until the patches are reposted
4. Don't worry about it and post w/ no context
- Gets you flamed.  :-)

My preference is definitely #2.  I guess my opinion is: development is
going to occur in off-mainline trees regardless.  Most of them are
private (and therefore irrelevant to this discussion), but some like
jdl's and the freescale trees are public.  The changes have been
around a long time, but they are still not in mainline.  In this case,
I do not think replying to one of the original patches is relevant or
convenient due to additional changes applied on top, the amount of
time that has passed, and the git workflow.

Also as an aside, I'm also assuming the that the mainline maintainer
is *not* expected to comment on off-mainline patches (but is certainly
welcome to).

Please note:  I'm not talking about accepting those patches into
mainline.  The off mainline changes still need to be approved by you
before being accepted into mainline.  If I understand you correctly,
you require that 'clean' patches be extracted from an off-mainline
tree and posted to the ML before they will be accepted into mainline.
Eventually, the patches I'm talking about will appear in mainline as
part of the 'fully baked' patchset; submitted by the off-mainline
maintainer; and subject to approval for mainline.

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

Understood, and in most cases they probably have

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

On rereading my comment here, I realize it's harsher than I intended.
I'm sorry.  I just wanted to state my disagreement, but this statement
could be read as a personal comment.  I apologize.

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

Okay, then I misunderstood and I apologize.

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

I think that's fair (and probably already being done)

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

agreed.

Cheers,
g.

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