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
