Re: lei-managed pseudo mailing lists

Konstantin Ryabitsev wrote: > I'm just worried that if we overuse the alternates, then we may find ourselves > in a situation where when we repack the "every blob" shared repository, we'll > end up with a pack that isn't really optimized to be used by any of the > member repos. So, in a situation

Re: lei-managed pseudo mailing lists

On Mon, Apr 26, 2021 at 06:47:17PM +, Eric Wong wrote: > > I'm thinking we need the ability to make it a real clonable repository -- > > perhaps without its own xapian index? Actual git repositories aren't large, > > especially if they are only used for direct git operations. Disk space is > >

Re: lei-managed pseudo mailing lists

Konstantin Ryabitsev wrote: > On Mon, Apr 26, 2021 at 05:37:26PM +, Eric Wong wrote: > > > The latter is specifically something I think would be of interest to > > > kernel > > > folks, so I envision that we'd have something like the following: > > > > > > - a maintainer publishes a

Re: lei-managed pseudo mailing lists

On Mon, Apr 26, 2021 at 05:37:26PM +, Eric Wong wrote: > > The latter is specifically something I think would be of interest to kernel > > folks, so I envision that we'd have something like the following: > > > > - a maintainer publishes a configuration file we can pass to lei > > The

Re: lei-managed pseudo mailing lists

Konstantin Ryabitsev wrote: > Hello: > > One of the services I think would be interesting to provide is ability for > people to subscribe to "curated saved searches". For example, a kernel > subsystem maintainer can define a set of query parameters (a thread mentions > these

lei-managed pseudo mailing lists

Hello: One of the services I think would be interesting to provide is ability for people to subscribe to "curated saved searches". For example, a kernel subsystem maintainer can define a set of query parameters (a thread mentions these files/functions/terms, etc), and allow others to follow this

[PATCH] URIimap: canonicalize uppercases UIDVALIDITY parameter

And the UID one, too, as well. This simplifies future comparison and matching code once case is no longer taken into account. --- lib/PublicInbox/URIimap.pm | 3 +++ t/uri_imap.t | 8 2 files changed, 11 insertions(+) diff --git a/lib/PublicInbox/URIimap.pm

[PATCH] lei p2q: exit with failure if format-patch fails

Merely redirecting the failure message from git to our stderr is insufficient. --- lib/PublicInbox/LeiP2q.pm | 7 +-- t/lei-p2q.t | 4 +++- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/lib/PublicInbox/LeiP2q.pm b/lib/PublicInbox/LeiP2q.pm index

[PATCH] lei_input: support PublicInbox::WWW mboxrd URLs

This gives "lei import", "lei tag", and similar commands the ability to use URLs recognized by our PSGI frontend directly. This is more convenient than an equivalent shell pipeline since "set -o pipefail" is not portable and errors may be lost. --- MANIFEST| 1 +

[PATCH] lei_input: support PublicInbox::WWW mboxrd URLs

This gives "lei import", "lei tag", and similar commands the ability to use URLs recognized by our PSGI frontend directly. This is more convenient than an equivalent shell pipeline since "set -o pipefail" is not portable and errors may be lost. --- MANIFEST| 1 +

[PATCH] www: missing /$INBOX/$MSGID/raw returns 404

Don't attempt to return HTTP 300 via Extmsg on it, since whoever uses /raw is likely piping it to some other command. --- lib/PublicInbox/WWW.pm | 2 +- t/plack.t | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/lib/PublicInbox/WWW.pm b/lib/PublicInbox/WWW.pm