feature requests

feature requests

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 2401 bytes --]

I am seeing your new mailing list manager and I am all excited
because I like ezmlm, want something not as bloated as mailman, and
given that mlmmj is still young, I hope I can contribute to get
important features in.

One such feature is the ability to add and remove mailing lists
without the need to edit /etc/aliases. The best way to do this would
be to provide transport/directors that take messages at stdin and
handle them accordingly. Then I could set, e.g. postfix to have
lists.my.domain use the mlmmj transport, which would be this script.

The next feature that I think is paramount is the ability to add
aliases to an account, like majordomo2. With subscriber-only lists,
it is a pain to be restricted to a single address for posting.
mailman "solves" this by allowing subscriptions to be NOMAIL. this
is also painful. majordomo2 is nice. you subscribe, then register
a bunch of aliases with your address, which can also post.

The last feature was sent to Mads privately. Here is is for
completeness. Not sure whether this can be done, or should rather be
done in a separate programme. But I think it's a cool idea (it's
mine...) ;^>

Here it is:

> Also, please make sure you implement a nice moderation interface
> as it's the only thing that mailman is lacking, really. i suggest
> an IMAP server with subfolders for accept, reject, discard. then
> you simply move messages in the queue accordingly. Only remaining
> problem: locking for multiple moderators, and the possibility to
> undo, or to do batched commits.

For your information, I am a mailing list administrator with quite
some experience in majordomo, ezmlm, and mailman, even with sympa...
I use mailman and I hate it. All the others are worse though. ezmlm
mainly because of its licence.

I am particularly looking for a special mailing list manager to
handle:

  http://marc.theaimsgroup.com/?l=mailman-users&m=109508403307185&w=2

Maybe mlmmj can be made flexible enough from the start to be able to
support this.

Cheers,

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: madduck.bogus@madduck.net
 
the only difference between a car salesman and a computer salesman
is that the car salesman knows he's lying.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: feature requests

[Mads Martin Joergensen]

* martin f krafft <madduck@madduck.net> [Sep 20. 2004 21:19]:
> The next feature that I think is paramount is the ability to add
> aliases to an account, like majordomo2. With subscriber-only lists,
> it is a pain to be restricted to a single address for posting.
> mailman "solves" this by allowing subscriptions to be NOMAIL. this
> is also painful. majordomo2 is nice. you subscribe, then register
> a bunch of aliases with your address, which can also post.

High on the TODO is the ability when posting to a subscribers only
posting list to get a reply whether one wants to be able to post from
this address in the future. A simple reply to that mail will subscribe
the address to the nomail list which is already implemented, just not
released yet.

This way one can have one address subscribed getting the mail, and a
bunch of addresses subscribed without getting any mail.

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.

Re: feature requests

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1361 bytes --]

also sprach Mads Martin Joergensen <mmj@mmj.dk> [2004.09.20.2133 +0200]:
> High on the TODO is the ability when posting to a subscribers only
> posting list to get a reply whether one wants to be able to post from
> this address in the future. A simple reply to that mail will subscribe
> the address to the nomail list which is already implemented, just not
> released yet.

Yeah, that would be nice.

However, please take care with automatic replies and the like.
Challenge Response systems (of which this is one) are very painful
if not done right; and I know not aof a single one done right.

http://kmself.home.netcom.com/Rants/challenge-response.html

> This way one can have one address subscribed getting the mail, and
> a bunch of addresses subscribed without getting any mail.

Please allow for manual setting of such aliases as well. The nice
thing about majordomo2's approach is that the addresses lose their
right to post when someone unsubscribes. I don't think you can do
that with the challenge system.

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: madduck.bogus@madduck.net
 
gentoo: for when you finally find out
that overclocking can kill your processor.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: feature requests

[Mads Martin Joergensen]

* martin f krafft <madduck@madduck.net> [Sep 20. 2004 21:56]:
> > High on the TODO is the ability when posting to a subscribers only
> > posting list to get a reply whether one wants to be able to post from
> > this address in the future. A simple reply to that mail will subscribe
> > the address to the nomail list which is already implemented, just not
> > released yet.
> 
> Yeah, that would be nice.
> 
> However, please take care with automatic replies and the like.
> Challenge Response systems (of which this is one) are very painful
> if not done right; and I know not aof a single one done right.
> 
> http://kmself.home.netcom.com/Rants/challenge-response.html

We send mails to the envelope from (Return-Path:) for confirmation of
subscription. I'm sure you want that?

> > This way one can have one address subscribed getting the mail, and
> > a bunch of addresses subscribed without getting any mail.
> 
> Please allow for manual setting of such aliases as well. The nice
> thing about majordomo2's approach is that the addresses lose their
> right to post when someone unsubscribes. I don't think you can do
> that with the challenge system.

With mlmmj there's a seperate 'version' of the list, just like the
way digests are done in ezmlm.

If you send a mail to listname+subscribe-nomail@domain.tld you subscribe
to the list without getting any email from it ever. Handy if you read
your lists via the web, or through a news gateway.

So what could be done simply treat postings to a subscribers only
list from emails not subscribed, as if they were trying to subscribe to
the nomail version of it.

This way they only need one reply, and they are allowed to post from
this address.

To do it right, the mail that was originally sent, will of course be
posted to the list, if the person subscribes to the nomail version--a
little bit like moderation.

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.

Re: feature requests

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1912 bytes --]

also sprach Mads Martin Joergensen <mmj@mmj.dk> [2004.09.20.2204 +0200]:
> We send mails to the envelope from (Return-Path:) for confirmation
> of subscription. I'm sure you want that?

it does not matter. Automatic replies are evil. Moreover, too many
legitimate users have invalid Return-Paths. But it is a far better
means than using the From header. I am just saying: do not rely on
the challenges only.

> So what could be done simply treat postings to a subscribers only
> list from emails not subscribed, as if they were trying to
> subscribe to the nomail version of it.
> 
> This way they only need one reply, and they are allowed to post
> from this address.
> 
> To do it right, the mail that was originally sent, will of course
> be posted to the list, if the person subscribes to the nomail
> version--a little bit like moderation.

Wait, you said it would automatically subscribe them? I also think
that's a bad idea. If I get a confirmation request when I did not
consciously subscribe anywhere, I will delete it.

Whatever you do, please allow majordomo2-style aliases. You can do
challenges on top. Power-users will want to set aliases. In fact,
I have scripts to set it all up for me.

That said, I subscribed to the mailing list and have not received
a confirmation yet. Nor am I getting mail. What could be wrong?
The address I used was mlmmj=mmj.dk@mass.madduck.net

You are using cryptographic confirmations for subscriptions, right?

Thanks,

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: madduck.bogus@madduck.net
 
"one should never trust a woman who tells her real age.
 if she tells that, she will tell anything."
                                                        -- oscar wilde

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: feature requests

[Mads Martin Joergensen]

 [ forgot to Cc: list, so resend ]

* martin f krafft <madduck@madduck.net> [Sep 20. 2004 22:10]:
> also sprach Mads Martin Joergensen <mmj@mmj.dk> [2004.09.20.2204 +0200]:
> > We send mails to the envelope from (Return-Path:) for confirmation
> > of subscription. I'm sure you want that?
> 
> it does not matter. Automatic replies are evil. Moreover, too many
> legitimate users have invalid Return-Paths. But it is a far better
> means than using the From header. I am just saying: do not rely on
> the challenges only.

I'm not going to subscribe people without them confirming.

> > So what could be done simply treat postings to a subscribers only
> > list from emails not subscribed, as if they were trying to
> > subscribe to the nomail version of it.
> >
> > This way they only need one reply, and they are allowed to post
> > from this address.
> >
> > To do it right, the mail that was originally sent, will of course
> > be posted to the list, if the person subscribes to the nomail
> > version--a little bit like moderation.

> Wait, you said it would automatically subscribe them? I also think
> that's a bad idea. If I get a confirmation request when I did not
> consciously subscribe anywhere, I will delete it.

Sure, so delete it. But IF you want to be able to post from this address
you can reply to it, and be able to.

> Whatever you do, please allow majordomo2-style aliases. You can do
> challenges on top. Power-users will want to set aliases. In fact.
> I have scripts to set it all up for me.

What does majordomo2 style aliases look like?

> That said, I subscribed to the mailing list and have not received
> a confirmation yet. Nor am I getting mail. What could be wrong?
> The address I used was mlmmj=mmj.dk@mass.madduck.net

There was no mail from mass.madduck.net delivered to the mmj.dk MX, are
you sure you sent it to the right address? You can subscribe such an
email just fine.

> You are using cryptographic confirmations for subscriptions, right?

No.

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.

Re: feature requests

[Mads Martin Joergensen]

* Mads Martin Joergensen <mmj@mmj.dk> [Sep 20. 2004 22:24]:
> > That said, I subscribed to the mailing list and have not received
> > a confirmation yet. Nor am I getting mail. What could be wrong?
> > The address I used was mlmmj=mmj.dk@mass.madduck.net
> 
> There was no mail from mass.madduck.net delivered to the mmj.dk MX, are
> you sure you sent it to the right address? You can subscribe such an
> email just fine.

Correction; it was recieved, but no To: header was present, so it was
discarded.

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.

Re: feature requests

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 759 bytes --]

also sprach Mads Martin Joergensen <mmj@mmj.dk> [2004.09.20.2228 +0200]:
> Correction; it was recieved, but no To: header was present, so it
> was discarded.

Is that necessary? I always use /usr/sbin/sendmail for mailing list
subscriptions. The To header is completely useless anyway, isn't it?
Why require it?

Anyway, I resent the subscription request.

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: madduck.bogus@madduck.net
 
during the voyage of life, remember to keep an eye out for a fair
wind; batten down during a storm; hail all passing ships; and fly your
colours proudly!

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: feature requests

[Mads Martin Joergensen]

* martin f krafft <madduck@madduck.net> [Sep 20. 2004 22:38]:
> also sprach Mads Martin Joergensen <mmj@mmj.dk> [2004.09.20.2228 +0200]:
> > Correction; it was recieved, but no To: header was present, so it
> > was discarded.
> 
> Is that necessary? I always use /usr/sbin/sendmail for mailing list
> subscriptions. The To header is completely useless anyway, isn't it?
> Why require it?

No, it's not not necessary. It's a bug--allthough quite harmless. It'll
be fixed in next version--we already use Delivered-To: for sanity
checks, so might as well use it exclusively if present.

> Anyway, I resent the subscription request.

Welcome :)

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.

Re: feature requests

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 754 bytes --]

also sprach Mads Martin Joergensen <mmj@mmj.dk> [2004.09.20.2254 +0200]:
> No, it's not not necessary. It's a bug--allthough quite harmless.
> It'll be fixed in next version--we already use Delivered-To: for
> sanity checks, so might as well use it exclusively if present.

Right. Please consider that Delivered-To is non-standard. Postfix
and qmail do it. exim and sendmail don't, I think.

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: madduck.bogus@madduck.net
 
"alle vorurteile kommen aus den eingeweiden."
                                                 - friedrich nietzsche

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: feature requests

[Mads Martin Joergensen]

* martin f krafft <madduck@madduck.net> [Sep 20. 2004 22:59]:
> also sprach Mads Martin Joergensen <mmj@mmj.dk> [2004.09.20.2254 +0200]:
> > No, it's not not necessary. It's a bug--allthough quite harmless.
> > It'll be fixed in next version--we already use Delivered-To: for
> > sanity checks, so might as well use it exclusively if present.
> 
> Right. Please consider that Delivered-To is non-standard. Postfix
> and qmail do it. exim and sendmail don't, I think.

Yeah, if it's there it's used, if not fallback to To: is done. It's a
shame it didn't make it into the standards.

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.

Re: feature requests

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

also sprach Mads Martin Joergensen <mmj@mmj.dk> [2004.09.20.2300 +0200]:
> Yeah, if it's there it's used, if not fallback to To: is done.
> It's a shame it didn't make it into the standards.

Why don't you just rely on the envelope recipient?

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: madduck.bogus@madduck.net
 
it may look like i'm just sitting here doing nothing.
but i'm really actively waiting
for all my problems to go away.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: feature requests

[Mads Martin Joergensen]

* martin f krafft <madduck@madduck.net> [Sep 20. 2004 23:04]:
> also sprach Mads Martin Joergensen <mmj@mmj.dk> [2004.09.20.2300 +0200]:
> > Yeah, if it's there it's used, if not fallback to To: is done.
> > It's a shame it didn't make it into the standards.
> 
> Why don't you just rely on the envelope recipient?

Which header is that? I've looked through the RFCs but didn't find it,
so please educate me, there's nothing I would rather do.

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.

Re: feature requests

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

also sprach Mads Martin Joergensen <mmj@mmj.dk> [2004.09.20.2305 +0200]:
> Which header is that? I've looked through the RFCs but didn't find
> it, so please educate me, there's nothing I would rather do.

Return-Path, I think.

Alternatively, you could not go via /etc/aliases and pass recipient
as argument to a transport/director script.

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: madduck.bogus@madduck.net
 
"not the truth in whose possession any man is, or thinks he is, but
 the honest effort he has made to find out the truth, is what
 constitutes the worth of man."
                                                   -- gotthold lessing

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: feature requests

[Mads Martin Joergensen]

* martin f krafft <madduck@madduck.net> [Sep 20. 2004 23:15]:
> also sprach Mads Martin Joergensen <mmj@mmj.dk> [2004.09.20.2305 +0200]:
> > Which header is that? I've looked through the RFCs but didn't find
> > it, so please educate me, there's nothing I would rather do.
> 
> Return-Path, I think.

Return-Path is the envelope from. RFC{,2}821.

> Alternatively, you could not go via /etc/aliases and pass recipient
> as argument to a transport/director script.

In that case you might as well set the Delivered-To: in case you don't
have, because in case you do have it, it's the envelope to.

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.

Re: feature requests

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 919 bytes --]

also sprach Mads Martin Joergensen <mmj@mmj.dk> [2004.09.20.2317 +0200]:
> > Return-Path, I think.
> 
> Return-Path is the envelope from. RFC{,2}821.

ah, right. sorry, i mixed that up.

> > Alternatively, you could not go via /etc/aliases and pass
> > recipient as argument to a transport/director script.
> 
> In that case you might as well set the Delivered-To: in case you
> don't have, because in case you do have it, it's the envelope to.

True. But how will you make it work reliably with exim and sendmail
(and zmailer, I think)?

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: madduck.bogus@madduck.net
 
"sometimes the urge to do bad
 is nearly overpowering"
                                                          -- ben horne

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: feature requests

[Mads Martin Joergensen]

* martin f krafft <madduck@madduck.net> [Sep 20. 2004 23:21]:
> > > Alternatively, you could not go via /etc/aliases and pass
> > > recipient as argument to a transport/director script.
> > 
> > In that case you might as well set the Delivered-To: in case you
> > don't have, because in case you do have it, it's the envelope to.
> 
> True. But how will you make it work reliably with exim and sendmail
> (and zmailer, I think)?

When Delivered-To: is not there, I'm relying on the To: header.

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.

Re: feature requests

[Morten K. Poulsen]

On Mon, Sep 20, 2004 at 11:21:12PM +0200, martin f krafft wrote:
> > > Alternatively, you could not go via /etc/aliases and pass
> > > recipient as argument to a transport/director script.

How do you do that? Remember, we need the extended part (+stuff) as
well.

> > In that case you might as well set the Delivered-To: in case you
> > don't have, because in case you do have it, it's the envelope to.
> 
> True. But how will you make it work reliably with exim and sendmail
> (and zmailer, I think)?

When you configure your mail server for mlmmj, just make sure to set it
up to add a Delivered-To: header. Thats reliable.

Morten

-- 
Morten K. Poulsen <morten@afdelingp.dk>
http://www.afdelingp.dk/

Re: feature requests

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]

also sprach Morten K. Poulsen <morten@afdelingp.dk> [2004.09.21.1242 +0200]:
> On Mon, Sep 20, 2004 at 11:21:12PM +0200, martin f krafft wrote:
> > > > Alternatively, you could not go via /etc/aliases and pass
> > > > recipient as argument to a transport/director script.
> 
> How do you do that? Remember, we need the extended part (+stuff)
> as well.

The mailers can pass arguments to the transporters. For an example
of how I do it with postfix/mailman right now:

  http://mail.python.org/pipermail/mailman-users/2004-January/033730.html

> When you configure your mail server for mlmmj, just make sure to
> set it up to add a Delivered-To: header. Thats reliable.

I don't think sendmail/exim/zmailer can do that. But I would be
happy to be proven wrong.

In any case, this was just a heads-up. I am never going to use
anything but postfix anyway.

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: madduck.bogus@madduck.net
 
it is better to have loft and lost
than to never have loft at all.
                                                       -- groucho marx

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: feature requests

[Morten K. Poulsen]

On Tue, Sep 21, 2004 at 04:22:19PM +0200, martin f krafft wrote:
> The mailers can pass arguments to the transporters.

OK, so adding an optional argument to mlmmj-receive with the envelope-to
will solve this issue for all mailers. If your mailer does not support
adding Delivered-To: you can pass it as an argument and have
mlmmj-receive add it. That should work for all cases, right?

> > When you configure your mail server for mlmmj, just make sure to
> > set it up to add a Delivered-To: header. Thats reliable.
> 
> I don't think sendmail/exim/zmailer can do that. But I would be
> happy to be proven wrong.

I know Exim can, but I think sendmail needs to be patched to do it. I
don't know about zmailer.

> In any case, this was just a heads-up. I am never going to use
> anything but postfix anyway.

Some people might be using sendmail, and we want them to be able to use
mlmmj too :-)

Morten

-- 
Morten K. Poulsen <morten@afdelingp.dk>
http://www.afdelingp.dk/

Re: feature requests

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]

also sprach Morten K. Poulsen <morten@afdelingp.dk> [2004.09.21.1654 +0200]:
> OK, so adding an optional argument to mlmmj-receive with the envelope-to
> will solve this issue for all mailers. If your mailer does not support
> adding Delivered-To: you can pass it as an argument and have
> mlmmj-receive add it. That should work for all cases, right?

Yeah, sure. And that argument should be available by the time of
/etc/aliases.db parsing.

> > In any case, this was just a heads-up. I am never going to use
> > anything but postfix anyway.
> 
> Some people might be using sendmail, and we want them to be able
> to use mlmmj too :-)

Clearly a necessity. I mean, people seem to like retro-technology.

/me ducks

(Eric Allman is a good acquaintance of mine)

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: madduck.bogus@madduck.net
 
"computer science is no more about computers
 than astronomy is about telescopes."
                                                 -- edsgar w. dijkstra

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Feature requests

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1906 bytes --]

On Fri, Dec 09, 2022 at 04:09:32PM -0500, Konstantin Ryabitsev wrote:
> On Tue, Dec 06, 2022 at 11:52:25PM +0000, Mark Brown wrote:

> > I've had another look at potentially adopting b4 prep/send as a
> > replacement for the bits of my scripting that it covers.  I did
> > find a couple of gaps that are causing friction though:
> > 
> >  - Some command line options for extracting the metadata for the

...

> >    comparing the current version with the last sent version.  An
> >    equivalent of git config get/set for the series metadata would
> >    cover all this and more.

> I believe the latest master should have what you need:

>     $ b4 prep --show-info
>     branch: b4/bupkes-bogus
>     cover-subject: [RFC] Another completely bogus series, ignore
>     prefixes: RFC
>     change-id: 20221205-bupkes-bogus-8f0db5172091
>     revision: 6
>     cover-strategy: commit
>     base-branch: master
>     base-commit: bce9332220bd677d83b19d21502776ad555a0e73
>     start-commit: 8398c66ced5379a8b84d59ec7f703e9809b17c12
>     end-commit: ae4436d441721dd884355b637f02dbc620ad422d
>     commit-ae4436d44172: Rename linux into pengux
>     commit-c0075ed67f3f: Makefile: Make it a ninja penguin

That does the read side great, thanks - the write side would still be
useful, mainly for the base-branch which can change during the lifetime
of a series (it's common to move between mainline and topic branches in
the upstream repo in both directions).

> >  - It would be nice if there was an option to sign the tags used
> >    when tagging sent branches, especially when signing the actual
> >    sent patches.

> Theoretically, this is already possible via tag.gpgSign = yes. Would that be a
> suitable approach?

Yes, that should work for me for now - I guess there will be some people
who do use unsigned tags who'd want to sign these particular tags.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Feature requests

[Konstantin Ryabitsev]

[-- Attachment #1: Type: text/plain, Size: 1969 bytes --]

On Tue, Dec 06, 2022 at 11:52:25PM +0000, Mark Brown wrote:
> Hi Konstantin,
> 
> I've had another look at potentially adopting b4 prep/send as a
> replacement for the bits of my scripting that it covers.  I did
> find a couple of gaps that are causing friction though:
> 
>  - Some command line options for extracting the metadata for the
>    series would be helpful - the main one I'm looking for is
>    series.revision, some of my scripts operate on all the
>    branches I've got that have unsent changes which I could do by
>    comparing the current version with the last sent version.  An
>    equivalent of git config get/set for the series metadata would
>    cover all this and more.
> 
>  - Being able to get the commit ID of the metadata commit would
>    be useful so I can do testing on the actual commits in the
>    branch (when using the commit cover strategy).  Alternatively,
>    I'd use this to generate a list of commits in the branch so
>    that list would also do the job, but getting the ID for the
>    metadata commit seems more general.

I believe the latest master should have what you need:

    $ b4 prep --show-info
    branch: b4/bupkes-bogus
    cover-subject: [RFC] Another completely bogus series, ignore
    prefixes: RFC
    change-id: 20221205-bupkes-bogus-8f0db5172091
    revision: 6
    cover-strategy: commit
    base-branch: master
    base-commit: bce9332220bd677d83b19d21502776ad555a0e73
    start-commit: 8398c66ced5379a8b84d59ec7f703e9809b17c12
    end-commit: ae4436d441721dd884355b637f02dbc620ad422d
    commit-ae4436d44172: Rename linux into pengux
    commit-c0075ed67f3f: Makefile: Make it a ninja penguin


>  - It would be nice if there was an option to sign the tags used
>    when tagging sent branches, especially when signing the actual
>    sent patches.

Theoretically, this is already possible via tag.gpgSign = yes. Would that be a
suitable approach?

-K

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Feature requests

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

Hi Konstantin,

I've had another look at potentially adopting b4 prep/send as a
replacement for the bits of my scripting that it covers.  I did
find a couple of gaps that are causing friction though:

 - Some command line options for extracting the metadata for the
   series would be helpful - the main one I'm looking for is
   series.revision, some of my scripts operate on all the
   branches I've got that have unsent changes which I could do by
   comparing the current version with the last sent version.  An
   equivalent of git config get/set for the series metadata would
   cover all this and more.

 - Being able to get the commit ID of the metadata commit would
   be useful so I can do testing on the actual commits in the
   branch (when using the commit cover strategy).  Alternatively,
   I'd use this to generate a list of commits in the branch so
   that list would also do the job, but getting the ID for the
   metadata commit seems more general.

 - It would be nice if there was an option to sign the tags used
   when tagging sent branches, especially when signing the actual
   sent patches.

Thanks for working on b4, it's really useful.

Thanks,
Mark

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]