{"thread":{"id":"18785","subject":"Re: [PATCH RFC 1/6] send-email: Add --delay for separating emails","startedAt":"2009-04-08T14:25:25Z","lastAt":"2009-04-09T21:02:35Z","messageCount":15,"participants":["Michael Witten","Jeff King","Junio C Hamano","Nicolas Sebrecht","Nicolas Pitre"],"isPatch":true,"patchVersion":1,"patchTotal":6},"messages":[{"id":"110832","messageId":"49dcb464.06d7720a.66ca.ffffbd30@mx.google.com","threadId":"18785","inReplyTo":null,"subject":"Re: [PATCH RFC 1/6] send-email: Add --delay for separating emails","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2009-04-08T14:25:25Z","receivedAt":"2009-04-08T14:25:25Z","isPatch":true,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Tue, Apr 07, 2009 at 04:25:17PM -0500, Michael Witten wrote:\n>> When sending a patch series, the emails often arrive at the final\n>> destination out of order; though these emails should be chained\n>> via the In-Reply-To headers, some mail-viewing systems display\n>> by order of arrival instead.\n>>\n>> The --delay option provides a means for specifying that there\n>> should be a certain number of seconds of delay between sending\n>> emails, so that the arrival order can be controlled better.\n\nOn Tue, Apr 7, 2009 at 16:51, Jeff King wrote:\n> I'm a little dubious how well this works in practice. Have you done\n> any experiments?\n\nI have indeed, and I got better results. Whether that was a fluke,\nI can't say for sure.\n\n> [Delivery delays] can be much larger than a few seconds, and this\n> won't help at all there.\n\nand\n\nOn Tue, Apr 7, 2009 at 18:17, Junio C Hamano wrote:\n> I do not think giving N second interval at the sending end would\n> help much in the real world. Between your submitting MUA (that's\n> \"git-send-email\") and the client MUA, there are many hops involved...\n> any single hop can batch the messages that arrive within a small time\n> window before passing them to the next hop, and it can reorder the\n> messages when it does so.\n>\n> In short, the only thing your --delay can control is the arrival\n> interval at your outgoing MSA. The arrival interval and order of\n> messages are outside your control for later hops.\n\nFor the most part, yes, I am operating under the assumption that email\nis sent as soon as it is received by any intervening hop (no batch\naccumulation). However, I'm also postulating that there always exists\nan N that serves as an upperbound on the transit time, regardless of\nbatching.\n\nThat's where these comment comes into play:\n\nOn Tue, Apr 7, 2009 at 16:51, Jeff King wrote:\n> The reason I am dubious is that you are presumably delaying only a few\n> seconds (since anything more would be quite annoying to the user).\n\nOn Wed, Apr 8, 2009 at 01:03:\n> A multi-second delay is downright annoying. As a sender, I don't think\n> I would enable this option.\n\nHowever, this sentiment doesn't make sense to me.\n\nFirstly, I presume that someone is electing to use this option, so it is\nalmost by definition not annoying for that person.\n\nSecondly, it seems reasonable to drop into another VC, screen window, or\nterminal instance, and then set send-email a-running. For instance, with\na 14-patch series, one could set `--delay 60' and then let send-email\nrun happily for the next 14 minutes with nary a thought.\n\nHowever, I think you're coming at it from a different angle:\n\nOn Wed, Apr 8, 2009 at 01:03, Jeff King wrote:\n> But apparently many readers sort by date received. See this subthread:\n> \n>  http://article.gmane.org/gmane.comp.version-control.git/110097\n> \n> I am generally of the opinion that if it is a big problem for people,\n> they should get a better mail client. But I am also open to suggestions\n> for helping receivers on crappy mail clients as long as those\n> suggestions do not put a burden on the sender.\n\nand\n\non Tue, Apr 7, 2009 at 17:08, Nicolas Sebrecht wrote:\n> If the receiver wants the patch series be in a good ordered _for\n> sure_, he has to switch to a client mail supporting the In-Reply-To\n> chains.\n\nFrankly, I don't care how other people's patch series appear to me. I care\nabout how mine appear to others. Is this irrational? Probably, but I'm kind\nof OC; I want my patch series to look like it's in order for everyone.\n\nThis has nothing to do with what the receiver wants. This has everything\nto do with what the sender wants. I want my patch series to be in order\neven for wrongheaded receivers.\n\nSo, I never had any intention of forcing a delay on the sending end. It is\nstrictly for the sending end to use if desired.\n\nOn Tue, Apr 7, 2009 at 18:17, Junio C Hamano wrote:\n> I think send-email already has hacks to timestamp the messages at\n> least one-second apart by shifting the Date: field, so that the\n> recipient MUA can sort by the departure timestamp if it wants to (and\n> if it can), instead of the arrival timestamp. Is it not working well\n> for you?\n\nI have worked with 2 major mail clients that both display by date received:\n\n  * Mac OS X's Mail\n  * Gmail\n\nI assume that a not-insignificant number of others also use these clients.\nI don't mind letting send-email run in the background for a few minutes if\nit means my patch series appear in order.\n\nAs you say, Jeff:\n\n> On Wed, Apr 08, 2009 at 12:08:54AM +0200, Nicolas Sebrecht wrote:\n>> IMHO, this improvement is broken by design. We try to fix a\n>> receiver-only issue by a sender side fix.\n> \n> I almost said the same thing: it is really the receiver's problem.\n> However, that doesn't mean the sender can't do simple things to help\n> hint the right thing to the receiver. For example, we already munge the\n> date fields to make sure the timestamp in each patch is increasing.\n\nThere's nothing simpler than slowing the rate of outgoing email. It doesn't\neven have to be used; it is completely unintrusive and fully automated. It\neven works with the confirmation. Best of all, it didn't take much code to\nimplement.\n\nSincerely,\nMichael Witten\n"},{"id":"110833","messageId":"b4087cc50904080735i6d56212fke3072a22da488fb@mail.gmail.com","threadId":"18785","inReplyTo":"49dcb464.06d7720a.66ca.ffffbd30@mx.google.com","subject":"Re: [PATCH RFC 1/6] send-email: Add --delay for separating emails","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2009-04-08T14:35:02Z","receivedAt":"2009-04-08T14:35:02Z","isPatch":true,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Wed, Apr 8, 2009 at 09:25, Michael Witten <mfwitten@gmail.com> wrote:\n> For instance, with\n> a 14-patch series, one could set `--delay 60' and then let send-email\n> run happily for the next 14 minutes with nary a thought.\n\nAs implemented, it would only take 13 minutes.\n\nFor a 5-patch series:\n\n* Patch 1/5 sent\n* delay 60 seconds\n* Patch 2/5 sent\n* delay 60 seconds\n* Patch 3/5 sent\n* delay 60 seconds\n* Patch 4/5 sent\n* delay 60 seconds\n* Patch 5/5 sent\n* send email exits immediately\n"},{"id":"110897","messageId":"20090409081443.GB17221@coredump.intra.peff.net","threadId":"18785","inReplyTo":"49dcb464.06d7720a.66ca.ffffbd30@mx.google.com","subject":"Re: [PATCH RFC 1/6] send-email: Add --delay for separating emails","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-04-09T08:14:44Z","receivedAt":"2009-04-09T08:14:44Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 08, 2009 at 09:25:25AM -0500, Michael Witten wrote:\n\n> Firstly, I presume that someone is electing to use this option, so it is\n> almost by definition not annoying for that person.\n\nSure, obviously only people who enable it will be affected. I was\nthinking of it more in terms of group economics: how many people _will_\nenable it, because they think the payoff outweighs the annoyance.\n\nAnd perhaps you can argue that it has negligible group cost. The\ncode is small and not likely to introduce new bugs. So the only costs\nare whatever any sender is willing to pay themselves. And in that sense,\nif even one person uses it, it is a net win.\n\n> Secondly, it seems reasonable to drop into another VC, screen window, or\n> terminal instance, and then set send-email a-running. For instance, with\n> a 14-patch series, one could set `--delay 60' and then let send-email\n> run happily for the next 14 minutes with nary a thought.\n\nExcept for your 10-minute \"no activity, so let's suspend to ram\"\ntimeout. ;) But I think we can assume since the user is opting in to the\nfeature that they don't have a problem with it.\n\n> Frankly, I don't care how other people's patch series appear to me. I care\n> about how mine appear to others. Is this irrational? Probably, but I'm kind\n> of OC; I want my patch series to look like it's in order for everyone.\n\nNo, it's not irrational. We spend time proofreading, cleaning up\npatches, etc, because we know other people will read them. And a little\neffort by the sender can often save a lot of effort by many readers. And\npeople do it out of politeness, perhaps, or altruism, or simply because\nit encourages others to spend the effort for them.\n\nBut I would personally find such a delay annoying (especially 60\nseconds, which I consider to be huge), and I feel that by threading and\nusing sane date fields, I have done enough for the reader.\n\n> I have worked with 2 major mail clients that both display by date received:\n> \n>   * Mac OS X's Mail\n>   * Gmail\n\nSomebody reported in the thread I referenced earlier that gmane's web\ninterface has the same problem; I didn't check it myself, though.\n\n> There's nothing simpler than slowing the rate of outgoing email. It doesn't\n> even have to be used; it is completely unintrusive and fully automated. It\n> even works with the confirmation. Best of all, it didn't take much code to\n> implement.\n\nI disagree that it's unintrusive (and I understand that you don't think\nit is, and that there may be others like you, but I am pointing out\nthere are others who think the opposite). But given that it's optional,\nand it's not very much code, I don't have a strong objection. My\noriginal comment was that I was dubious whether it would work: however,\nI was thinking you would set it to a few seconds. Setting it to 60\nseconds, I can imagine it would have an impact.\n\n-Peff\n"},{"id":"110904","messageId":"7v3aci43g2.fsf@gitster.siamese.dyndns.org","threadId":"18785","inReplyTo":"20090409081443.GB17221@coredump.intra.peff.net","subject":"Re: [PATCH RFC 1/6] send-email: Add --delay for separating emails","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-04-09T08:49:17Z","receivedAt":"2009-04-09T08:49:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I disagree that it's unintrusive (and I understand that you don't think\n> it is, and that there may be others like you, but I am pointing out\n> there are others who think the opposite). But given that it's optional,\n> and it's not very much code, I don't have a strong objection. My\n> original comment was that I was dubious whether it would work: however,\n> I was thinking you would set it to a few seconds. Setting it to 60\n> seconds, I can imagine it would have an impact.\n\nHeh, then why not make the option specify the number of _minutes_ not\nseconds to delay?  That would help clarifying what this option is meant to\ndo.\n\nThe description for this new feature in the manual page should make it\nabsolutely clear that the maintainer who accepts such a feature is not\nclueless to think that such a delay will guarantee something.  It is\nmerely for people who believe it would help guaranteeing the delivery\norder _in practice_ and are willing to background the slow sending.\n"},{"id":"110927","messageId":"20090409161756.GA12910@vidovic","threadId":"18785","inReplyTo":"49dcb464.06d7720a.66ca.ffffbd30@mx.google.com","subject":"[PATCH RFC 1/6] Re: send-email: Add --delay for separating emails","fromName":"Nicolas Sebrecht","fromEmail":"nicolas.s-dev@laposte.net","sentAt":"2009-04-09T16:17:56Z","receivedAt":"2009-04-09T16:17:56Z","isPatch":true,"sender":{"key":"nicolas.s-dev@laposte.net","avatar":null},"body":"On Wed, Apr 08, 2009 at 09:25:25AM -0500, Michael Witten wrote:\n\n\n> This has nothing to do with what the receiver wants. This has everything\n> to do with what the sender wants. I want my patch series to be in order\n> even for wrongheaded receivers.\n\nThe --delay option may have an undesirable side effect. In case of\nnon-chained emails, unrelated mails could be insterted between patches\nwhere *all* MUA would be affected. It's not only true for very high\nvolume message mailing-lists (million monkeys receiving...). FMPOV, it's\nworse than all display issues we already know or have with the current\nbehaviour. \n\n-- \nNicolas Sebrecht\n"},{"id":"110933","messageId":"b4087cc50904091027l4656a6adv6a72bad0a747cdc1@mail.gmail.com","threadId":"18785","inReplyTo":"20090409161756.GA12910@vidovic","subject":"Re: [PATCH RFC 1/6] Re: send-email: Add --delay for separating emails","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2009-04-09T17:27:18Z","receivedAt":"2009-04-09T17:27:18Z","isPatch":true,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Thu, Apr 9, 2009 at 11:17, Nicolas Sebrecht\n<nicolas.s-dev@laposte.net> wrote:\n>\n> The --delay option may have an undesirable side effect. In case of\n> non-chained emails, unrelated mails could be insterted between patches\n> where *all* MUA would be affected. It's not only true for very high\n> volume message mailing-lists (million monkeys receiving...). FMPOV, it's\n> worse than all display issues we already know or have with the current\n> behaviour.\n\nBut it's already impossible to protect against this scenario. In that\nsituation, the smallest delay possible is desired, so --delay wouldn't\neven be used (that is, its value would be zero). However, the transit\ndelay could never be small enough to guarantee that no other emails\nare inserted into the patch series, so the only solution is to chain\nthem. At this point, we're back to the problem of arrival time, and\nhence --delay becomes useful.\n\n:-D\n"},{"id":"110936","messageId":"b4087cc50904091038v46f7f42bj844ba3a87ee28821@mail.gmail.com","threadId":"18785","inReplyTo":"b4087cc50904091027l4656a6adv6a72bad0a747cdc1@mail.gmail.com","subject":"Re: [PATCH RFC 1/6] Re: send-email: Add --delay for separating emails","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2009-04-09T17:38:15Z","receivedAt":"2009-04-09T17:38:15Z","isPatch":true,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Thu, Apr 9, 2009 at 12:27, Michael Witten <mfwitten@gmail.com> wrote:\n> On Thu, Apr 9, 2009 at 11:17, Nicolas Sebrecht\n> <nicolas.s-dev@laposte.net> wrote:\n>>\n>> The --delay option may have an undesirable side effect. In case of\n>> non-chained emails, unrelated mails could be insterted between patches\n>> where *all* MUA would be affected. It's not only true for very high\n>> volume message mailing-lists (million monkeys receiving...). FMPOV, it's\n>> worse than all display issues we already know or have with the current\n>> behaviour.\n>\n> But it's already impossible to protect against this scenario. In that\n> situation, the smallest delay possible is desired, so --delay wouldn't\n> even be used (that is, its value would be zero). However, the transit\n> delay could never be small enough to guarantee that no other emails\n> are inserted into the patch series, so the only solution is to chain\n> them. At this point, we're back to the problem of arrival time, and\n> hence --delay becomes useful.\n\nI do agree that --delay could exacerbate the spreading out of patches.\n"},{"id":"110938","messageId":"20090409174547.GA15767@vidovic","threadId":"18785","inReplyTo":"b4087cc50904091027l4656a6adv6a72bad0a747cdc1@mail.gmail.com","subject":"[PATCH RFC 1/6] Re: send-email: Add --delay for separating emails","fromName":"Nicolas Sebrecht","fromEmail":"nicolas.s-dev@laposte.net","sentAt":"2009-04-09T17:45:47Z","receivedAt":"2009-04-09T17:45:47Z","isPatch":true,"sender":{"key":"nicolas.s-dev@laposte.net","avatar":null},"body":"On Thu, Apr 09, 2009 at 12:27:18PM -0500, Michael Witten wrote:\n> \n> On Thu, Apr 9, 2009 at 11:17, Nicolas Sebrecht\n> <nicolas.s-dev@laposte.net> wrote:\n> >\n> > The --delay option may have an undesirable side effect. In case of\n> > non-chained emails, unrelated mails could be insterted between patches\n> > where *all* MUA would be affected. It's not only true for very high\n> > volume message mailing-lists (million monkeys receiving...). FMPOV, it's\n> > worse than all display issues we already know or have with the current\n> > behaviour.\n> \n> But it's already impossible to protect against this scenario.\n\nBut we could forbid the use of --delay with non-chained emails, no? Or\nat least, warn it should not be used.\n\n-- \nNicolas Sebrecht\n"},{"id":"110939","messageId":"alpine.LFD.2.00.0904091342170.6741@xanadu.home","threadId":"18785","inReplyTo":"20090409081443.GB17221@coredump.intra.peff.net","subject":"Re: [PATCH RFC 1/6] send-email: Add --delay for separating emails","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2009-04-09T17:48:23Z","receivedAt":"2009-04-09T17:48:23Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 9 Apr 2009, Jeff King wrote:\n\n> On Wed, Apr 08, 2009 at 09:25:25AM -0500, Michael Witten wrote:\n> \n> > Firstly, I presume that someone is electing to use this option, so it is\n> > almost by definition not annoying for that person.\n> \n> Sure, obviously only people who enable it will be affected. I was\n> thinking of it more in terms of group economics: how many people _will_\n> enable it, because they think the payoff outweighs the annoyance.\n\nMy ISP doesn't allow me to send more than 20 emails at once.  So if a \npatch series has more than 20 patches, send-email will be denied the \nsending of the end of the series, which is rather anoying.\n\nI didn't test this option (have no large patch series to post at the \nmoment), but if it could allow me to easily work around the ISP \nrestriction then I would be happy.\n\n\nNicolas\n"},{"id":"110940","messageId":"alpine.LFD.2.00.0904091349150.6741@xanadu.home","threadId":"18785","inReplyTo":"7v3aci43g2.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH RFC 1/6] send-email: Add --delay for separating emails","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2009-04-09T17:51:02Z","receivedAt":"2009-04-09T17:51:02Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 9 Apr 2009, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > I disagree that it's unintrusive (and I understand that you don't think\n> > it is, and that there may be others like you, but I am pointing out\n> > there are others who think the opposite). But given that it's optional,\n> > and it's not very much code, I don't have a strong objection. My\n> > original comment was that I was dubious whether it would work: however,\n> > I was thinking you would set it to a few seconds. Setting it to 60\n> > seconds, I can imagine it would have an impact.\n> \n> Heh, then why not make the option specify the number of _minutes_ not\n> seconds to delay?  That would help clarifying what this option is meant to\n> do.\n\nMaybe only a few seconds is all that is needed in some circumstances.\nFor the issue I just posted, I wouldn't use it at all if the minimum \ndelay was one minute.\n\n\nNicolas\n"},{"id":"110945","messageId":"b4087cc50904091143s4ab8ccdfsc9848b70b23b00d7@mail.gmail.com","threadId":"18785","inReplyTo":"20090409174547.GA15767@vidovic","subject":"Re: [PATCH RFC 1/6] Re: send-email: Add --delay for separating emails","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2009-04-09T18:43:26Z","receivedAt":"2009-04-09T18:43:26Z","isPatch":true,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Thu, Apr 9, 2009 at 12:45, Nicolas Sebrecht\n<nicolas.s-dev@laposte.net> wrote:\n> But we could forbid the use of --delay with non-chained emails, no? Or\n> at least, warn it should not be used.\n\nAh! Good point! I'll add that.\n"},{"id":"110949","messageId":"7vskkh1va5.fsf@gitster.siamese.dyndns.org","threadId":"18785","inReplyTo":"alpine.LFD.2.00.0904091342170.6741@xanadu.home","subject":"Re: [PATCH RFC 1/6] send-email: Add --delay for separating emails","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-04-09T19:28:34Z","receivedAt":"2009-04-09T19:28:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre <nico@cam.org> writes:\n\n> On Thu, 9 Apr 2009, Jeff King wrote:\n>\n>> On Wed, Apr 08, 2009 at 09:25:25AM -0500, Michael Witten wrote:\n>> \n>> > Firstly, I presume that someone is electing to use this option, so it is\n>> > almost by definition not annoying for that person.\n>> \n>> Sure, obviously only people who enable it will be affected. I was\n>> thinking of it more in terms of group economics: how many people _will_\n>> enable it, because they think the payoff outweighs the annoyance.\n>\n> My ISP doesn't allow me to send more than 20 emails at once.\n\nHmm, I first thought you meant 20 emails in a single smtp session, but it\nappears that we create a new instance of Net::SMTP for each piece of email\nso it really sounds like it is time based (N pieces of e-mail within M\nminutes).\n\nPerhaps --pause=N,M to say \"Pause N seconds for every M messages\", where\nMichael's --delay=N is just a shorthand for --pause=N,1 is what you want?\nThat is, reset the counter to 0 at the beginning, increment it after\nsending each message, and when the counter is M and if you have more to\nsend, you wait for N seconds and reset the counter to 0.  Then when you\nhave a series smaller than 20 you won't have to suffer from any artificial\ndelay.\n"},{"id":"110950","messageId":"alpine.LFD.2.00.0904091535150.6741@xanadu.home","threadId":"18785","inReplyTo":"7vskkh1va5.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH RFC 1/6] send-email: Add --delay for separating emails","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2009-04-09T19:36:00Z","receivedAt":"2009-04-09T19:36:00Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 9 Apr 2009, Junio C Hamano wrote:\n\n> Nicolas Pitre <nico@cam.org> writes:\n> \n> > On Thu, 9 Apr 2009, Jeff King wrote:\n> >\n> >> On Wed, Apr 08, 2009 at 09:25:25AM -0500, Michael Witten wrote:\n> >> \n> >> > Firstly, I presume that someone is electing to use this option, so it is\n> >> > almost by definition not annoying for that person.\n> >> \n> >> Sure, obviously only people who enable it will be affected. I was\n> >> thinking of it more in terms of group economics: how many people _will_\n> >> enable it, because they think the payoff outweighs the annoyance.\n> >\n> > My ISP doesn't allow me to send more than 20 emails at once.\n> \n> Hmm, I first thought you meant 20 emails in a single smtp session, but it\n> appears that we create a new instance of Net::SMTP for each piece of email\n> so it really sounds like it is time based (N pieces of e-mail within M\n> minutes).\n> \n> Perhaps --pause=N,M to say \"Pause N seconds for every M messages\", where\n> Michael's --delay=N is just a shorthand for --pause=N,1 is what you want?\n> That is, reset the counter to 0 at the beginning, increment it after\n> sending each message, and when the counter is M and if you have more to\n> send, you wait for N seconds and reset the counter to 0.  Then when you\n> have a series smaller than 20 you won't have to suffer from any artificial\n> delay.\n\nI suppose that would work fine too.\n\n\nNicolas\n"},{"id":"110956","messageId":"b4087cc50904091359q7cadc31cp150b2681775e7022@mail.gmail.com","threadId":"18785","inReplyTo":"7vskkh1va5.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH RFC 1/6] send-email: Add --delay for separating emails","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2009-04-09T20:59:04Z","receivedAt":"2009-04-09T20:59:04Z","isPatch":true,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":">> My ISP doesn't allow me to send more than 20 emails at once.\n>\n> Hmm, I first thought you meant 20 emails in a single smtp session, but it\n> appears that we create a new instance of Net::SMTP for each piece of email\n> so it really sounds like it is time based (N pieces of e-mail within M\n> minutes).\n\nActually, there is a lot of ||= going on in there, so it would seem\nthat only one\nsmtp session is created; the weird thing is that STARTTLS and $smtp->hello() are\nrun each time through send_message(), which I think is probably wrong.\nIf it works,\nthen I imagine it's just superfluous.\n\nIn any case, if his ISP doesn't like him sending more than 20 emails\nper session,\nthen it certainly won't like 1 session per email.\n\n> Perhaps --pause=N,M to say \"Pause N seconds for every M messages\", where\n> Michael's --delay=N is just a shorthand for --pause=N,1 is what you want?\n> That is, reset the counter to 0 at the beginning, increment it after\n> sending each message, and when the counter is M and if you have more to\n> send, you wait for N seconds and reset the counter to 0.  Then when you\n> have a series smaller than 20 you won't have to suffer from any artificial\n> delay.\n\nThis sounds reasonable, but I would have:\n\n    --rate=M/N\n\nMichael Witten\n"},{"id":"110957","messageId":"b4087cc50904091402qbe4a0f2m90c18ab049012cdd@mail.gmail.com","threadId":"18785","inReplyTo":"b4087cc50904091359q7cadc31cp150b2681775e7022@mail.gmail.com","subject":"Re: [PATCH RFC 1/6] send-email: Add --delay for separating emails","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2009-04-09T21:02:35Z","receivedAt":"2009-04-09T21:02:35Z","isPatch":true,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Thu, Apr 9, 2009 at 15:59, Michael Witten <mfwitten@gmail.com> wrote:\n>> Perhaps --pause=N,M to say \"Pause N seconds for every M messages\", where\n>> Michael's --delay=N is just a shorthand for --pause=N,1 is what you want?\n>> That is, reset the counter to 0 at the beginning, increment it after\n>> sending each message, and when the counter is M and if you have more to\n>> send, you wait for N seconds and reset the counter to 0.  Then when you\n>> have a series smaller than 20 you won't have to suffer from any artificial\n>> delay.\n>\n> This sounds reasonable, but I would have:\n>\n>    --rate=M/N\n\nI take that back. Clearly `rate' connotes an average rather than a burst.\n"}]}