inbox.sourceware.org experiment

Mark Wielaard mark@klomp.org
Sun Aug 21 17:41:43 GMT 2022


Hi Simon,

On Thu, Aug 18, 2022 at 10:40:00AM -0400, Simon Marchi via Overseers wrote:
> For me it's:
> 
>  - Being able to download the raw emails in order to apply patches or to
>    properly reply to messages on lists I'm not subscribed to
> 
>  - I never thought about the feature Mark mentioned, about download an
>    mbox for a given query.  But if you want to download a very long
>    patch series to apply it locally, it could be useful.

Note that b4 (and piem if you use emacs) help with this. It will
create a local mbox containing the whole series based on any
message-id in the thread. It can also look for a newer series and
collect (and add) Reviewed-by tags looking through the messages.

>  - Better display and browsing to read longer threads that span multiple
>    months.  For example, trying to follow this thread on Mailman would
>    be complicated:
> 
>      https://inbox.sourceware.org/gdb-patches/20220428033542.1636284-1-simon.marchi@polymtl.ca/T/#r5f31e373eeb958095add41686e0ae7d1dcac9f1a
> 
>  - Search: I find it useful to be able to find a message by Message-ID.
>    For instance, I'm reading the message in my client, and I want to
>    send someone the link to that message in the web interface.  In my
>    instance (pi.simark.ca) I can paste the Message-ID in the search box
>    and it gets me directly to the right message.  On
>    inbox.sourceware.org, I don't see the same search box, maybe it is
>    because of the V1/V2 thing you have been talking about?

You can always add the message-id to the URL directly, as you did
above (add /T/ to get the full thread that message belongs to). You
didn't see the search box because the lists have not been full
indexed. I reimported some lists (see below) and now you should also
be able to use the search box in most lists.

>  - Not super important, but I like that the URLs to messages contain the
>    Message-IDs.  This way, in a distant future where
>    inbox.sourceware.org does not exist anymore, someone with the archive
>    can still find out which message a given URL refers to.  A bit like
>    if I give you this URL:
> 
>      https://gitlab.com/gnutools/binutils-gdb/-/commit/243cf0f69c36c4ee09c3c2b0bc7a97dc16119c51
> 
>    and Gitlab does not exist anymore, you can still find you which
>    commit I am talking about if you have a copy of the binutils-gdb git
>    repo.

Yes! It do think that is super important. It also allows you to add a
message link: in a commit message pointing to the original patch
submission and discussion.

> Also, you were talking about space.  If you want to save some space, I
> don't think it's very useful to have the *-cvs lists on there.

Yeah, there are also -prs/-bugs lists which are better searched
through bugzilla and -testresult lists that can be index/searched
through bunsen.

> And there are lists that are pretty much dead that you could skip
> too.

To preserve history lets not skip "dead" lists unless they are
archived at some new location. I think we are responsible for keeping
the history of old projects/lists.

I did reimport some of the lists as V2 archives with full indexing. So
you can now easily search through the following cygwin lists:

cygwin, cygwin-announce, cygwin-apps, cygwin-developers,
cygwin-licensing, cygwin-patches and cygwin-talk

The following gcc lists:

fortran, gcc, gcc-announce, gcc-help, gcc-patches, gcc-rust,
gnutools-advocacy, java, java-announce, java-patches, jit and
libstdc++

But https://inbox.sourceware.org/libstdc++ doesn't work, I suspect the
++ should be URL escaped somehow.

And the following sourceware lists:

archer, bfd, binutils, buildbot, bunsen, bzip2-devel, c++-embedded,
cgen, crossgcc, debugedit, docbook-tools-announce,
docbook-tools-discuss, dominion-hackers, dwz, eclipse, ecos-announce,
ecos-devel, ecos-discuss, ecos-maintainers, ecos-patches,
elfutils-devel, elix, elix-announce, frysk, gas2, gdb, gdb-announce,
gdb-patches, gnats-announce, gnats-devel, gnu-gabi, gsl-announce,
gsl-discuss, guile-emacs, guile-gtk, infinity, insight,
insight-announce, installshell, kawa, libabigail, libc-alpha,
libc-announce, libc-hacker, libc-help, libc-locales, libc-ports,
libc-stable, libffi-announce, libffi-discuss, mauve-discuss,
mauve-patches, mingw-dvlpr, netresolve, newlib, patchutils-list,
prelink, pthreads-win32, rda, rhdb, rhdb-admin, rhdb-cc, rhdb-explain,
rhug-rhats, sharutils-alpha, sid, sid-announce, sourcenav,
sourcenav-announce, sourceware-announce, springfield, systemtap,
xconq-announce and xconq7

See also the
mailman.lists/{cygwin.com,gcc.gnu.org,sourceware.org}.lists.full lists
and import_{cygwin,gcc,sourceware}_from_mbox scripts in the inbox
homedir.

I did remove the "test" list, and the cronjob that kept it
populated. But all other lists have been kept as V1 and basic
indexing.

There are some lists which never seen any messages. I think we should
remove them because they probably won't see any messages ever. And it
makes looking for real lists more difficult (it is ~25% of the lists,
97 out of the total 260 lists are just empty).

anonymous, autobook-cvs, autobook-webpages-cvs, autoconf-cvs,
autoconf-webpages-cvs, binutils-webpages-cvs, bzip2-cvs,
bzip2-webpages-cvs, catapult-cvs, catapult-webpages-cvs,
c++-embedded-cvs, c++-embedded-webpages-cvs, cgen-prs,
cgen-webpages-cvs, cluster-webpages-cvs, cygwin-webpages-cvs, dm-cvs,
dm-webpages-cvs, docbook-tools-hackers, docbook-tools-webpages-cvs,
dominion-announce, dominion-cvs, dominion-discuss,
dominion-webpages-cvs, ecos-webpages-cvs, elix-cvs, elix-webpages-cvs,
gcc-cvs-testrun, gcc-maintainers, gcc-ppc, gcc-sc, gcc-testlist,
gdb-webpages-cvs, gettext-alpha, gettext-announce,
gettext-webpages-cvs, glibc-webpages-cvs, global, gnats-admin,
gnats-webpages-cvs, gsl-webpages-cvs, guile-emacs-cvs,
guile-webpages-cvs, insight-cvs, insight-webpages-cvs, inti-cvs, inti,
inti-webpages-cvs, ip-over-scsi-cvs, ip-over-scsi-webpages-cvs,
java-cvs, jffs2-webpages-cvs, kawa-cvs, kawa-webpages-cvs, libaio,
libaio-webpages-cvs, libc-alpha1, libffi-cvs, libffi-webpages-cvs,
libstdc++-webpages-cvs, mailer-daemon, mauve-announce, mauve-cvs,
mauve-webpages-cvs, newlib-webpages-cvs, piranha-webpages-cvs,
postmaster, prelink-svn, psim-cvs, psim-webpages-cvs,
pthreads-win32-cvs, pthreads-win32-webpages-cvs, rhdb-installer,
rhdb-jdbc, rhdb-utils, root, rpm2html, rpm2html-prs,
sharutils-announce, sharutils-cvs, sharutils-webpages-cvs,
sid-webpages-cvs, sourcemaster, sourcenav-prs, sourceware-cvs,
sourceware-cvs-sourceware, sourceware-cvs-sourceware-webpages,
sourceware-infra-cvs, sourceware-webpages-cvs, systemtap-webpages-cvs,
testcvs-cvs, testcvs-webpages-cvs, webmaster, win32-x11-cvs,
win32-x11-webpages-cvs, xconq-prs and xconq-webpages-cvs

There are also the following 9 lists, which are either private (in
which case they show up as empty above) or not publicly advertised
lists:

cygwin-xfree, cygwin-xfree-announce, gcc-sc, mailman, overseers,
postmaster, root, sourcemaster and test-list.

The cygwin lists might still be interesting. Likewise for this list
overseers. But the others probably should be removed.

Opinions?

Thanks,

Mark


More information about the Overseers mailing list