[U-Boot] The way the list manages patch submission

[Karl O. Pinc]

Dear Wolfgang,

On 08/04/2012 08:35:49 AM, Wolfgang Denk wrote:

> In message <1344041771.12337.2 at mofo> you wrote:
> >
> > The trouble is getting a patch message back from the list when you
> > send a patch in.  For example I sent
> 
> Why would you want to get your own messages back?  You already know
> what you sent, don't you?   

Because I always get all my own messages back, except for patches.
Duplicate elimination is different from whether the list
sends you back your own messages.

> 
> > <1344017124-5749-1-git-send-email-kop at meme.com>
> > [PATCH v2] README: Add handy kermit primer
> 
> Yes, and as you can see for example from the list archive at gmane
> that has been properly deliverd; also your V2 of it:

Yes.  That was never an issue.  (I can see how you might think
it is an issue.  People say their messages "do not go to the list"
because they look in their email inbox and do not see the list sending
them the message.)

> > The mail logs show the message going out, but nothing
> > ever comes back with that message id.
> 
> Why should it?

See above.

> 
> > Perhaps it's because git send-email automatically cc-s me,
> > so the list decides not to send the patch back?
> > I've added myself as a cc to this message to see
> > if that matters.
> 
> Your registration in the mailing list has the "nodupes" flag set,
> which is documented as:
> 
> 	Avoid duplicate copies of messages?
> 
> 	When you are listed explicitly in the To: or Cc: headers of a
> 	list message, you can opt to not receive another copy from the
> 	mailing list. Select Yes to avoid receiving copies from the
> 	mailing list; select No to receive copies.
> 
> 	If the list has member personalized messages enabled, and you
> 	elect to receive copies, every copy will have a
> 	X-Mailman-Copy: yes header added to it. 
> 
> You selected that you don't want dupes, so you should not complain
> that you don't get dupes.

Ah, but I didn't "select" this configuration.  I got 
the default configuration without ever knowing what I got.

> 
> > In any case it's not a big deal.  It's just, odd.
> 
> It is the configuration you selected. If you don't like it, then go
> to the list page, click on "edit options", and change your settings.
> Most people prefer it tis way, though.

Really, it's more of a problem with _git_ on my end always cc-ing
me.  Although duplicate elimination on the list side makes sense
it the combination of this default and git's behavior that
makes for never-before-seen behavior that leads to questions.
After all, how often is it that I cc myself when sending
email to a list?  (If ever, I'd bcc.)   It's git's cc-ing
that's introducing a new factor and making odd things happen.

Come to think of it, most (all?) of the lists I'm subscribed
to have duplicate elimination turned off by default.
Now that I think of it
I was also surprised when my conversations with others
that cc-ed the list did not show up on the list -- to be
precise, _I_ was not able to see them show up on the list
by looking at my email inbox.  But that didn't really
raise alarm bells in the same way that sending patches
and then not "seeing" them on the list raises alarms.
Patches represent real work and when they seem to
disappear it's disconcerting.  Because of the moderation
delay (maybe?) by the time u-boot messages start showing up
in my inbox I've already forgotten about the cc-ed conversation;
but patches are memorable.

So perhaps the u-boot list default that has
duplicate elimination turned on,
where other lists do not, is factor contributing 
to the confusion.  I've never had
to think about configuring my list subscriptions.
I send email; the list delivers the email to all it's
recipients, including me.  The operation is very transparent.
When things did not work that way on the u-boot list
it raised questions.  My very first post was a patch.
It took me about a month to realize that the patch was
received by the rest of the list and by then I'd
already re-sent it.

If I had confusion and Andy had confusion there
must also have been some other people in the past
who didn't speak up who had confusion too.

Anyway, problem solved.  We know what's happening,
what happened, and why.  You can decide if there's
any sort of issue that you want to address by
frobbing defaults on your end.

I hope this has been more helpful than annoying.

Regards,

Karl <kop at meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

P.S.  As long as we're on the subject of the list,
the moderation delay was initially confusing when
sending in my first post.  (My first post
was actually 2 emails, sent by 
git send-email --compose, so was 2 emails:
a patch and a regular email.  The regular
email was, after delay, sent back to me by the list,
the patch was not.)  No getting around the moderation
delay, just thought I'd mention it.  Perhaps you could
alter the list welcome message to note that the
list is moderated.  This won't help; nobody
reads the instructions.  :/  But at least you'll
have something to point to if anybody complains.

P.P.S. It occurs to me that it might be less confusing
if the list default was to not send emails back to
the original sender, as well as having duplicate
elimination turned on.  This seems to me to be
more consistent -- you never get messages you
otherwise see.  I can't say I like this as a default,
I'm just saying it would be a more consistent user interface.
It would not violate the principal of least surprise
by treating messages potentially seen because of cc differently
from messages seen otherwise.