From: Gaute Hope <eg@gaute.vetsj.com>
To: Eric Weikl <eric.weikl@gmx.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-devel] [sup-talk] sup: Fix for an UndefinedMethodError
Date: Sun, 14 Apr 2013 14:05:52 +0200 [thread overview]
Message-ID: <516A9BA0.7040906@gaute.vetsj.com> (raw)
In-Reply-To: <1365938152-sup-6420@mint>
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
next prev parent reply other threads:[~2013-04-14 12:06 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-12 18:09 Jonathan Lassoff
2013-04-12 18:46 ` Steven Hum
2013-04-12 19:46 ` Hamish D
2013-04-13 9:16 ` Gaute Hope
2013-04-13 10:09 ` Jonathan Lassoff
2013-04-13 13:17 ` Gaute Hope
2013-04-13 16:35 ` Jonathan Lassoff
2013-04-13 17:14 ` Gaute Hope
2013-04-13 17:37 ` Gaute Hope
2013-04-13 19:19 ` Jonathan Lassoff
2013-04-13 20:48 ` Jonathan Lassoff
2013-04-13 22:17 ` Gaute Hope
2013-04-14 11:31 ` [sup-devel] " Eric Weikl
2013-04-14 12:05 ` Gaute Hope [this message]
2013-04-14 17:39 ` Eric Weikl
2013-04-16 20:30 ` [sup-talk] [sup-devel] " Eric Weikl
2013-04-16 21:21 ` Matthieu Rakotojaona
2013-04-17 8:51 ` Gaute Hope
2013-04-17 3:31 ` Steven Hum
2013-08-15 13:22 ` [sup-devel] Is maildir-sync ready for prime time? Eric Weikl
2013-08-15 13:35 ` [sup-talk] " Steven Schmeiser
2013-04-14 17:45 ` [sup-talk] sup: Fix for an UndefinedMethodError Hamish D
2013-04-14 22:32 ` Gaute Hope
2013-04-15 11:42 ` Gaute Hope
2013-04-13 19:15 ` Jonathan Lassoff
2013-04-13 22:20 ` Gaute Hope
2013-04-13 12:49 ` Matthieu Rakotojaona
2013-04-13 13:29 ` Gaute Hope
2013-04-13 15:42 ` Steven Hum
2013-04-13 10:06 ` Jonathan Lassoff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=516A9BA0.7040906@gaute.vetsj.com \
--to=eg@gaute.vetsj.com \
--cc=eric.weikl@gmx.net \
--cc=sup-talk@rubyforge.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox