Re: [edk2-devel] [PATCH v3 0/4] OvmfPkg: CSM boot fixes

["Laszlo Ersek" <lersek@redhat.com>]

On 06/26/19 14:33, David Woodhouse wrote:
> On Wed, 2019-06-26 at 14:18 +0200, Laszlo Ersek wrote:
>>
>> Yes, it can be turned off. It is a common hiccup for new subscribers
>> (the groups.io default is broken). I think we meant to document it
>> somewhere (outside of the mailing list archive), and I guess we may have
>> even done so, but currently a non-list reference escapes me.
>>
>> Anyway, please see the attached messages -- and then please log in to
>> your groups.io account, locate
>>
>>   Account
>>     Preferences
>>       Email Preferences
>>         My Posts
>>           I always want copies of my own emails
>>
>> and *uncheck* it.
> 
> Thanks.
> 
>> Because, in reality, that checkbox stands for "munge my Message-IDs so
>> that GMail doesn't de-duplicate my own emails when the list reflects
>> them to me". But, two wrongs don't make a right :/
> 
> Wow, this is just completely brain-damaged on so many levels. So people
> who do, and who don't, have that box checked will receive the same
> message with *different* Message-Id: headers?
> 
> If one of them replies, the In-Reply-To: threading header in their
> reply will refer to a message that *doesn't* exist in the other
> person's mailbox. This kind of explains why threading was so broken for
> messages on the list, with some response getting 'lost' because they
> were detached from the thread. This does not facilitate effective
> communication.
> 
> Did nobody at groups.io ever stop and think this through? Can it really
> not be turned off for the whole list? Why on earth did we move the list
> to somewhere that can't even get the *basics* right?

We did evaluate groups.io quite carefully, before moving to it. I
proposed a ~15 step plan for the evaluation, and after some tweaking,
groups.io passed it. The eval plan targeted basic mailing list
functionality, and in my judgement, groups.io has worked as a suitable
replacement for the prior lists, ever since we moved.

There were two (sets of) motives for migrating away from the previous
(01.org-based) list, as I recall.

One, list administration for the 01.org owners had been too much of a
chore -- our traffic had been too high for 01.org proportions, spam was
a constant problem, and moderation / whitelisting for non-subscribers
could never be handled effectively. <groups.io> is a lot more flexible
in that regard -- the list / subscriber / messages management that I get
from groups.io is far better than I got from 01.org *in practice*, for
example.

Two, the community wanted a "groupware" solution, with calendars, a
space for uploading/storing design documents (presentations, PDFs),
actually working email attachments, and such. The community also
requested WebUI-based thread filtering / message tagging, IIRC. <01.org>
offered nothing of the sort; <groups.io> looks viable thus far.

My personal requirement was that, with all the above features in place,
groups.io should primarily continue working as a (drop-in replacement)
mailing list. With some account tweaking, I think it functions well in
that regard.

Its web archive for the mailing list has a disastrous UI, admittedly,
but that has been solved by feeding the traffic to other (independent)
archives. <mail-archive.com> is one, and I happen to run another at
<https://www.redhat.com/archives/edk2-devel-archive/> (this latter is
plain mailman2).

Mail-archive.com in particular offers message-id-based search, which is
a hugely useful feature.  Whenever I need to capture a message reference
somewhere, I usually include two -- a msgid-based one, from
mail-archive.com, and another, native to groups.io.


> Should I offer to set one up @lists.infradead.org?

<lists.infradead.org> looks like standard Mailman2.

Mailman2 is good for development mailing lists, and its moderation
features are quite good in my experience -- as long as the list owner
makes those available to list moderators anyway (I'm looking at you,
01.org). However, mailman2 does not offer the "groupware" aspect.

I think we should stick with groups.io for now -- it's not ideal as a
*development* mailing list, but it looks like a suitable compromise,
between multiple goals. There is some pain associated with it when
someone subscribes and tweaks stuff initially, but then it's relatively
painless.

Thanks
Laszlo