Re: Structured feeds
On 11/9/19 8:41 AM, Johannes Berg wrote: On Sat, 2019-11-09 at 01:18 +1100, Daniel Axtens wrote: - code that efficiently reads a public-inbox git repository/folder of git repositories and feeds it into the existing parser. I have very inefficient code that converts public-inbox to an mbox and then parses that, but I'm sure you can do better with a git library. Somebody (Daniel Borkmann?) posted a (very fast) public-inbox git to maildir converter, with procmail support. I assume that would actually satisfy this step already, since you can just substitute the patchwork parser for procmail. - careful thought about how to do this incrementally. It's obvious how to do email incrementally, but I think you need to keep an extra bit of state around to incrementally parse the git archive. I think. Not sure he had an incremental mode figured out there, but that can't really be all *that* hard, just store the last-successfully-parsed git sha1? Yep, that is what it is doing, so that we only need to walk the repo(s) upon a new git fetch to the point where we stopped last time. Thanks, Daniel ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
Re: RFE: use patchwork to submit a patch
On Mon, Nov 11, 2019 at 10:35:10AM +0100, Dmitry Vyukov wrote: > On Sat, Nov 9, 2019 at 5:31 AM Theodore Y. Ts'o wrote: > > Essentially format=flowed is only supposed to be used when it's > > considered OK for the receiver to reflow (or not) the lines any darned > > way it wants. > But for me the point re email still stands: why are we even spending > time discussing this? Why are there such extensions with MAY status? > If one doesn't care if the received with recover the original message > or not, why caring adding/specifying these "format=flowed; > delsp=yes"?... > Obviously somebody in the middle got confused about these flowed/delsp > as well and either assumed that they are MUST or assumed that > preserving precise text for emails is just never important... Not sure if you're looking for a serious answer here or not and it's not really your point but the use case for format=flowed is for plain text mails. The sending MUA should flow the mail into 80 columns so it will render OK as text but if something wants to reflow (eg, to fit within a window) like it would for a paragraph in HTML mail then it can. It's optional so that things where the formatting is important don't get disrupted. > Regarding another mail agent: again this only proves the point for me: > this is what tool developers are forced to be spending their resources > on, rather then working on adding more useful features... > I don't even know where to start re switching mail transport; how much > the switch will cost? what are other transport costs in the long term > maintenance? what are their problems? We're not going to get away from interoperability problems no matter what we use, especially if we are mixing things intended for human and machine consumption. signature.asc Description: PGP signature ___ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
