Re: [sup-talk] [sup-devel] sup: Fix for an UndefinedMethodError
On 16. april 2013 23:21, Matthieu Rakotojaona wrote: On 04/16, Eric Weikl wrote: Hi everyone, I created a new branch with all the commits from Damien Leone and Edward Yang related to maildir syncback and put it here: https://github.com/sup-heliotrope/sup/tree/maildir-sync I skipped some advanced stuff like Edward's inotify support for now. We can add that later. I performed some basic testing, but it would be great if some more people could give it a try. There's some documentation in the wiki: https://github.com/sup-heliotrope/sup/wiki/Maildir-Syncback Cheers, Eric Fantastic. Not being able to sync back was what prevented me from using it. After much work and discouragement with heliotrope, I will gladly try this ! On a longer-term note, syncing back to maildir has the limitation that non-standard flags (i.e labels) will not be handled, unless we start defining some custom way of storing them or modifying the original emails, which I highly dislike (this is how mu[0] works). But that's just something to keep in mind for future times, when we have a stable, up-to-date sup release. Let's do this ! =] [0] http://www.djcbsoftware.nl/code/mu/ Great! Put up a wikipage for collecting some resources on this: https://github.com/sup-heliotrope/sup/wiki/Development:-Maildir-syncback Also a notmuch user created a script for syncing labels to maildir folders: https://github.com/altercation/es-bin/blob/master/maildir-notmuch-sync Cheers, Gaute ___ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk
Re: [sup-talk] [sup-devel] sup: Fix for an UndefinedMethodError
Hi everyone, I created a new branch with all the commits from Damien Leone and Edward Yang related to maildir syncback and put it here: https://github.com/sup-heliotrope/sup/tree/maildir-sync I skipped some advanced stuff like Edward's inotify support for now. We can add that later. I performed some basic testing, but it would be great if some more people could give it a try. There's some documentation in the wiki: https://github.com/sup-heliotrope/sup/wiki/Maildir-Syncback Cheers, Eric Excerpts from Gaute Hope's message of 2013-04-14 14:05:52 +0200: Cool. I would really like to see this in main sup, any other objections? In my view the main arguments are: - Manipulating IMAP could mess up user mail (potentially new bugs could mess up) - Maintaining this functionality requires some long-term (at least minor) effort - It modifies the mail store (could be solved with disabled-by-default) which I think is a big plus for many I would suggest creating a official branch for this now, if you are interested I could add you as commiter or owner. ___ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk
Re: [sup-talk] [sup-devel] sup: Fix for an UndefinedMethodError
On 04/16, Eric Weikl wrote: Hi everyone, I created a new branch with all the commits from Damien Leone and Edward Yang related to maildir syncback and put it here: https://github.com/sup-heliotrope/sup/tree/maildir-sync I skipped some advanced stuff like Edward's inotify support for now. We can add that later. I performed some basic testing, but it would be great if some more people could give it a try. There's some documentation in the wiki: https://github.com/sup-heliotrope/sup/wiki/Maildir-Syncback Cheers, Eric Fantastic. Not being able to sync back was what prevented me from using it. After much work and discouragement with heliotrope, I will gladly try this ! On a longer-term note, syncing back to maildir has the limitation that non-standard flags (i.e labels) will not be handled, unless we start defining some custom way of storing them or modifying the original emails, which I highly dislike (this is how mu[0] works). But that's just something to keep in mind for future times, when we have a stable, up-to-date sup release. Let's do this ! =] [0] http://www.djcbsoftware.nl/code/mu/ -- Matthieu Rakotojaona ___ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk
Re: [sup-talk] [sup-devel] sup: Fix for an UndefinedMethodError
Beautiful! I will begin using this in place of my copy of ezyang's fork immediately. Thanks for all your hard work, Steven Excerpts from Eric Weikl's message of 2013-04-16 16:30:26 -0400: Hi everyone, I created a new branch with all the commits from Damien Leone and Edward Yang related to maildir syncback and put it here: https://github.com/sup-heliotrope/sup/tree/maildir-sync I skipped some advanced stuff like Edward's inotify support for now. We can add that later. I performed some basic testing, but it would be great if some more people could give it a try. There's some documentation in the wiki: https://github.com/sup-heliotrope/sup/wiki/Maildir-Syncback Cheers, Eric Excerpts from Gaute Hope's message of 2013-04-14 14:05:52 +0200: Cool. I would really like to see this in main sup, any other objections? In my view the main arguments are: - Manipulating IMAP could mess up user mail (potentially new bugs could mess up) - Maintaining this functionality requires some long-term (at least minor) effort - It modifies the mail store (could be solved with disabled-by-default) which I think is a big plus for many I would suggest creating a official branch for this now, if you are interested I could add you as commiter or owner. -- Truth or die. Steven Hum 5 - 28 Gilmour St Ottawa, ON K2P 0N3 email sdot...@gmail.com tel 613.237.9058 ___ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk
Re: [sup-talk] [sup-devel] sup: Fix for an UndefinedMethodError
Hi Gaute, That sounds like a plan of action :-) Excerpts from Gaute Hope's message of 2013-04-13 19:37:01 +0200: - Go for Mail in stead of RMail (index breakage) Is this related to getting rid of Iconv for Ruby 2.0.0, or is it a separate issue? Otherwise, I would favor lumping it in the same release together with IMAP syncback, since both require a migration step by the user. - Integrate the IMAP / label sync back stuff (personally this is what I miss the most) I've been using the imap syncback code by Damien Leone from ezyang's branch for quite a while now ( 1 year) without any issues. It should be fairly easy to cherry-pick the relevant commits into the development branch. - Get rid of all dependencies that are abandoned or deprecated (ncurses gem..) +1 I'd also add deleting all unused code and other stuff (server code, website, Redwood protocol stuff, etc.). - Try to do tests on most stuff for different encodings I thought about adding some functional tests (through the UI or otherwise), since retrofitting unit tests is probably too much of a pain. I need to figure out how the parts fit together some more, though. Do you think that makes sense? Would be very nice: - Index migration We could do the index migration like the imap syncback code does - it recognizes that it wasn't done yet and asks you to run a command-line tool. - Config migration How exactly will the config change? Possibly it easy to detect via regular expressions or something? Cheers, Eric ___ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk
Re: [sup-talk] [sup-devel] sup: Fix for an UndefinedMethodError
On 14. april 2013 13:31, Eric Weikl wrote: Hi Gaute, That sounds like a plan of action :-) Excerpts from Gaute Hope's message of 2013-04-13 19:37:01 +0200: - Go for Mail in stead of RMail (index breakage) Is this related to getting rid of Iconv for Ruby 2.0.0, or is it a separate issue? Otherwise, I would favor lumping it in the same release together with IMAP syncback, since both require a migration step by the user. No, RMail and Iconv are separate issues. Yes, that was my thinking as well - since both config and index need a migration step. Iconv deprecation should be seamless (syncback as well). - Integrate the IMAP / label sync back stuff (personally this is what I miss the most) I've been using the imap syncback code by Damien Leone from ezyang's branch for quite a while now ( 1 year) without any issues. It should be fairly easy to cherry-pick the relevant commits into the development branch. Cool. I would really like to see this in main sup, any other objections? In my view the main arguments are: - Manipulating IMAP could mess up user mail (potentially new bugs could mess up) - Maintaining this functionality requires some long-term (at least minor) effort - It modifies the mail store (could be solved with disabled-by-default) which I think is a big plus for many I would suggest creating a official branch for this now, if you are interested I could add you as commiter or owner. - Get rid of all dependencies that are abandoned or deprecated (ncurses gem..) +1 I'd also add deleting all unused code and other stuff (server code, website, Redwood protocol stuff, etc.). Yes, you could put Iconv in this category as well. - Try to do tests on most stuff for different encodings I thought about adding some functional tests (through the UI or otherwise), since retrofitting unit tests is probably too much of a pain. I need to figure out how the parts fit together some more, though. Do you think that makes sense? Would be very nice: - Index migration We could do the index migration like the imap syncback code does - it recognizes that it wasn't done yet and asks you to run a command-line tool. Not entirely sure how things are built up, but migration probably requires to map ids between Mail and RMail (it's going to be messy). Matthieu had some insight here, see: https://github.com/sup-heliotrope/sup/issues/22 - Config migration How exactly will the config change? Possibly it easy to detect via regular expressions or something? The YAML output from Syck (deprecated and removed) and Psych is incompatible. So the old config files are not readable by Psych. An approach could possibly be: install syck as a gem (if it exists), load the file with Syck, re-write it with Psych. There exists a Psych gem for 1.8 (which could be conditionally loaded). Also might be worth taking a look at sup inspired stuff; notmuch / mutt-kz which I don't think provides the same as sup, but are less buggy atm. Cheers, Gaute ___ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk
Re: [sup-talk] [sup-devel] sup: Fix for an UndefinedMethodError
Hi Gaute, Excerpts from Gaute Hope's message of 2013-04-14 14:05:52 +0200: In my view the main arguments are: - Manipulating IMAP could mess up user mail (potentially new bugs could mess up) Yes. Although my experience was positive until now, this definitely needs extensive testing (especially when disabled). Volunteers, anyone? :-) I would suggest creating a official branch for this now, if you are interested I could add you as commiter or owner. Sure, I can give it a spin. Cheers, Eric ___ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk
