GNOME Bugzilla – Bug 324118
Remove IMAP4rev1 from stable releases.
Last modified: 2013-09-13 00:48:35 UTC
Difference? Some elaboration would be nice when creating/editing a mail account.
Maybe call the second "IMAP 4 rev. 1" and the first "IMAP X" where X is whatever
version it's supposed to be.
I don't know which one is the more modern/better/recommended and personally I am
As far as I can tell, IMAP4rev1 support is rubbish. It doesn't mark any emails
as "read" which drives me up the wall - but that's another bug maybe.
*** This bug report was brought to you by my "Getting Linux un-fucked"
bug-filing rampage. Sorry if it seems stupid or offends. ***
no, you're right. IMAP4rev1 should not have become part of the stable release.
good evening harish, good evening partha.
i'd like to see this discussed. now.
when will IMAP4rev1 be removed from the "normal" build?
both of you can imagine how many times i have written "do not use imap4rev1,
it's experimental" at bugzilla now?
it just sucks currently, i could spend that time on more useful things if it
would simply be removed. i'm spending too much time on stuff that just has no
development at all - answering imap4rev1 crashes in bugzilla is one of them.
if it's experimental, then it's experimental.
if evolution does not support some stuff, it does not support some stuff.
that's we way it goes. we can't have everything.
leave it optional with a configure flag for people compiling on their own, but
please don't waste my time anymore with answering IMAP4rev1 questions.
thanks in advance.
(i'm ranting too often within the last days, damn.)
PS: alex: sorry for kidnapping your bug report. :-)
Any time :P
At least I know for myself now not to use it!
The experimental and pretty-much unssupported/unmaintained IMAP4rev1 Account
Type needs to be *removed* from the default build. Make it optional again, like
it used to be.
Note: As this one went live before, Evo *must* provide some way to either
automatically or (easily) maually migrate from IMAP4rev1 to the stable IMAP
See e-h for a dead discussion about this, some months ago.
Alex, since you asked:
Both Mail Account Types IMAP and IMAP4rev1 basically use the IMAP4rev1
*protocol*, IIRC. At least, both are definitely IMAP4.
IMAP (as in the account type) is stable and should be preferred. The account
type IMAP4rev1 should never have been enabled by default in stable releases, IMHO.
FWIW, this is the thread I was talking about:
(Please note, there are a few more responses than obvious in the month view by a
quick glimpse. That's what you get for using shitty clients that break proper
In-Reply-To and References headers. GAR)
Coincidentally I just came across a user on IRC, who couldn't switch from
IMAP4rev1 to IMAP providers. Evo kept sitting in the "Loading" state, even after
I don't remember, if anyone successfully just *switched* account types.
To solve this, creating a new "IMAP" account was necessary. Dunno, if there are
some issues in the backends that effectively prohib switching. This needs to be
Hey Alex, Andre, Guenther,
IMAP4 rev 1 is going, soon. We have not removed it altogether since moving the
users is not quite straight forward. And thats the reason for the problem
mentioned by Guenther on Comment #7
The IMAP is IMAP4 compliant currently. So theoritically there is not much a
differnce between both the implementations in Evolution today. The only major
difference is the support for namspaces whcih 'IMAP 4 rev 1' has complete
support. And the IMAP implementation (in Evo) does not support it fully, as per
the RFC. Shreyas is actually adding the support for namspaces in the IMAP
provider. So the only hitch which remains is the migration from IMAP 4 rev1 to IMAP.
Hmmm.. Maybe its worthwhile to write migration support first and then implement
Namespaces. We dont want people using it <peroid>
Partha have you looked at how hard it is to write migration code from 'imap 4
rev1' (evo protocol) to imap.
Im not sure how this came under UI. It has to do with mailer and backends.
removing the keyword.
OK, so we missed this Milestone. Punting.
This still is a serious issue, and should be corrected ASAP.
The issue of an existing amorphous user base for IMAP4rev1, the necessity of providing a migration path or the likelihood of renewed hacking love for the provider have all been in limbo all these months. I would like to propose for one more time (hopefully, final) -
* to take IMAP4rev1 off the builds.
* not make the migration code a blocker, since it was 'experimental' all the while anyway
* add/test the support for namespaces in IMAP to address the need why some people opt to use IMAP4rev1. Get this in our roadmap but not wait on this to remove the provider.
partha/sankar/fejj : thoughts ?
sounds good to me, sad to see imap4 go but it's not worth trying to maintaining 2 imap providers.
Unmarking NEEDINFO... I don't have any more info to provide!
what's up, guys?
Sorry for the additional spam, but is anyone working on this?
seems the answer is "no".
harish, srini: this sucks.
Crap, wish I never reported this. Seems the emails just keep on coming in about it. :P
What's the holdup?
alex: hehehe :-)
guess the problem is that we also need to provide a well-tested fallback migration so people can easily migrate from imap4rev1 back to plain imap, which could be a tricky task.
Why do you even need to migrate an account type?
Isn't the whole point of IMAP that the mail remains on a remote server? What exactly do you need to "migrate"?
we need to migrate the account settings, e.g. imap4rev1 supports multiple namespaces while imap does not, if i remember correctly.
I'm not sure really how badly things really need to be "migrated", how many people really use imap4rev1 now? I doubt many.
the longer we keep imap4 available, the more people will start using it/depending on it which means the more needed migration will be. if this had been dropped asap, we probably could have gotten away without migrating at all.
I kinda think the best approach to this is to remove imap4 now and see how many people really need migration. if we find it's a problem, then we can write migration code, but seeing as how no one is actively writing it now anyway and we keep telling users who mention they are using imap4 to switch back to imap, we aren't going to be causing any additional harm by simply removing it.
For the time being, since nothing seems to be happening to resolve this, can we at least get IMAP4rev1 removed from the new account creation options, and something added to the documentation about the situation? It is rather hard to explain to users why a supposedly mature product has an experimental and broken option like this with *no warning anywhere in the documentation*.
Reassigning this to myself to get this removed in time for the release.
Mailer guys - I am requesting a freeze break approval for the removal unless I hear an objection from you.
I have no objection to remove it from the build and lets evaluate how many users really want a *migration* fix.
Patch committed to the CVS after approval from the release team. Resolving the bug as fixed.
I'll weigh in as one of those (happy) IMAP4 users.
For me, the current regular IMAP provider crashes regularly connecting to my Groupwise 6.5 IMAP server. The IMAP4rev1 provider does not. This has been consistent for years.
I'm willing to continue to rebuild my rpms everytime an upgrade comes out, but please do not completely remove this!
the patch that has been applied for evolution 2.8 makes the IMAP4rev1 provider a conditional feature which is turned off by default.
however, it is not removed from the codebase.
I was referring to fejj's note:
"I kinda think the best approach to this is to remove imap4 now and see how many
people really need migration. if we find it's a problem, then we can write
migration code, but seeing as how no one is actively writing it now anyway and
we keep telling users who mention they are using imap4 to switch back to imap,"
Migration would not help me, since the regular IMAP provider core dumps when presented with slightly misformed IMAP messages. This is a longstanding bug, the solution to which is apparently to upgrade the server. Since my server is stuck on Groupwise 6.5, and out of my control, this doesn't help.
I know I still had issues with this in EDS 1.6. I'll reserver judgement on 1.8 until I get a chance to run it. FC6 is out today, no? :)
So, I again plead to not remove IMAP4 until and unless the IMAP provider is known working with GW 6.5.
Hopefully this makes a bit more sense.