public inbox for overseers@sourceware.org
 help / color / mirror / Atom feed
From: Bernd Edlinger <bernd.edlinger@hotmail.de>
To: Gerald Pfeifer <gerald@pfeifer.com>, overseers@sourceware.org
Subject: Re: Can we please have the old mailing list back
Date: Thu, 2 Apr 2020 23:25:00 +0200	[thread overview]
Message-ID: <AM6PR03MB517008115FEE9E5B2EE91C0EE4C60@AM6PR03MB5170.eurprd03.prod.outlook.com> (raw)
In-Reply-To: <alpine.LSU.2.21.2004022122270.5927@anthias.pfeifer.com>

On 4/2/20 10:34 PM, Gerald Pfeifer wrote:
> On Thu, 2 Apr 2020, Bernd Edlinger via Overseers wrote:
>>> I'm not going to respond to most of the other points.  Having a public
>>> discussion about someone's inconvenience with my email address is silly.
>> how about also apologizing for the silly-word here?
> 
> May I suggest to take a deep breath?
> 
> This thread started on the wrong foot, and while I think I understand 
> where you came from, Bernd, I also believe some of your statements 
> came across stronger and more emotional than you may have intended.
> 
> Many of us here are volunteers, doing this on our own time, and all
> of us want to improve GCC and the infrastructure (gcc.gnu.org and
> otherwise) - in our different ways.
> 
> I, for one, appreciate the work you have been doing and equally how
> Christopher and others have been taking care of our infrastructure.
> 

Thanks Gerald, and once again apologies Christopher.
FYI: We are here trapped in our home, and cannot leave when we want.

And by the way where is the new data center located, and how do you
expect to be affected by corona?

What I said to Christopher is how I feel, but I believe everybody
feels a bit depressed, when mails bounce.  That can easily avoided,
but my recommendations to avoid that was ignored.  And the s-word was
used, which makes me feel kind of really sorry.

BTW: meanwhile I got a feed-back from Hank Leininger of marc.info.

It turns out, that the mail I observed on gdb-patches was not
received in the normal way, but from the web-gui, they crawled that
that back-filling, I may have misunderstood how that happens.
So the issue will fix itself, more or less, once they subscribed
the gdb-patches archive, that archive was just added yesterday on my
request, apparently.

I quote from Hank's mail which I just received:

> 
> Aha, OK this is because of where/when/how we got that data - it's one
> that we downloaded from an existing archive and bulk-inserted.
> 
> Pipermail has two ways it can publish old list traffic:
> 
> 1) One single raw-ish .mbox file, fairly unmolested. In my experience
>    almost no Pipermail admins enable this any more (spam concerns?
>    resource concerns? removed from recent Pipermail versions by default?
>    I do not know).
> 
> 2) A .txt(.gz)? file for each month. These are less raw - they have
>    attachments stripped out and replaced with a URL as you saw; they
>    also cook some mail headers, maybe do some s/@/ at / mangling, etc.
> 
> Since in practice we can never get #1 any more, we do #2.
> 
> But we don't try to follow and fetch each attachment-link and then fuss
> with it until it looks like a regular attachment again.  I agree with
> you it's a shame to not have it all in one place. MARC is only an
> unofficial archive (for most projects anyway), but still it would be
> nice to be complete. But I don't have the bandwidth to implement the
> attachment snarfing and re-attaching.
> 
> And it'd indeed be smarter for sourceware's pipermail to output https://
> versions of those links; it appears the server does support that fine.
> It may be either an overlooked default setting, or a deliberate
> resource-constraint choice.
> 
> MARC's policy on various things (like message-removal or -editing) is
> usually to follow the lead of the official list archives/admins - so if
> they switch their config to publishing https:// versions, I'll make an
> effort to go through our sourceware.org-origin mailing list archives and
> convert attachment URLs from http:// to https://. (That will be a little
> bit painful to implement though, so I might not be fast.)
> 
>> My question, did I understand right, that you just subscribe to a mailing
>> list, then receive the mails and store them on your hard drive(s) ?
>>
>> So what you show as raw message is 1:1 what you recived from sourceware.org ?
> 
> Yup, once we are subscribed, when we get new messages we'll preserve
> them entirely[*].
> 
> So:
> 
> - Messages with inline patches that were never attachments, we've got.
> 
> - Messages sent once we've subscribed that have attachments, we've got,
>   for example:
> 
>     https://marc.info/?l=gdb-patches&m=158584046107542&w=2
> 
> - Messages we bulk-inserted that had stripped attachments, we have only
>   what was in the .txt(.gz)? version of the message.
> 
> [*] For some version of "entirely". We don't preserve all mail headers
>     for instance, only the ones I thought were worth keeping back in
>     1997 and a few added since then 


One final question, can we provide them with
"1) One single raw-ish .mbox file, fairly unmolested."
with the data they need to fill the gaps in the history?


Thanks
Bernd.

      parent reply	other threads:[~2020-04-02 21:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <AM6PR03MB51706DF91E0ECE88B07C0389E4CE0@AM6PR03MB5170.eurprd03.prod.outlook.com>
     [not found] ` <CAH6eHdSvT1TsvQDTnUBU2J-bz8frGPdxeEPUH2MN0YHwEY0OCQ@mail.gmail.com>
     [not found]   ` <AM6PR03MB51707CDB1C1A796575F0BD11E4CE0@AM6PR03MB5170.eurprd03.prod.outlook.com>
     [not found]     ` <AM6PR03MB5170F2D588FE7BA176D4336AE4CE0@AM6PR03MB5170.eurprd03.prod.outlook.com>
     [not found]       ` <23b63bb3-9156-5a28-30b0-8fe557b33df1@gmx.com>
     [not found]         ` <20200325185527.GB8416@cgf.cx>
     [not found]           ` <AM6PR03MB5170D00AC63E74872A13A54FE4CE0@AM6PR03MB5170.eurprd03.prod.outlook.com>
     [not found]             ` <20200326151602.GA8097@cgf.cx>
     [not found]               ` <AM6PR03MB51700731D3005C747ADFED54E4CF0@AM6PR03MB5170.eurprd03.prod.outlook.com>
     [not found]                 ` <AM6PR03MB5170559115186755A61B9414E4C90@AM6PR03MB5170.eurprd03.prod.outlook.com>
     [not found]                   ` <AM6PR03MB5170CA4732A66BF9E240FA9CE4C90@AM6PR03MB5170.eurprd03.prod.outlook.com>
     [not found]                     ` <mptftdm45xk.fsf@arm.com>
2020-04-02  9:33                       ` Bernd Edlinger
2020-04-02  9:48                         ` Richard Sandiford
2020-04-02 10:01                           ` Bernd Edlinger
2020-04-02 16:00                             ` Christopher Faylor
2020-04-02 16:12                               ` Bernd Edlinger
2020-04-02 20:34                                 ` Gerald Pfeifer
2020-04-02 20:47                                   ` Christopher Faylor
2020-04-03  5:25                                     ` Bernd Edlinger
2020-04-02 21:25                                   ` Bernd Edlinger [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AM6PR03MB517008115FEE9E5B2EE91C0EE4C60@AM6PR03MB5170.eurprd03.prod.outlook.com \
    --to=bernd.edlinger@hotmail.de \
    --cc=gerald@pfeifer.com \
    --cc=overseers@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).