Date: Thu, 26 Apr 2001 02:07:04 +0200 From: Anders Nordby <anders@fix.no> To: Doug Barton <DougB@DougBarton.net> Cc: jim@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, ports@FreeBSD.org Subject: Re: cvs commit: ports/mail/imap-uw Makefile distinfo pkg-message ports/mail/imap-uw/files patch-ac patch-ah patch-ai Message-ID: <20010426020704.A14512@totem.fix.no> In-Reply-To: <3AE6FBEF.188F7673@DougBarton.net>; from DougB@DougBarton.net on Wed, Apr 25, 2001 at 09:31:43AM -0700 References: <200104250543.f3P5hXc80256@freefall.freebsd.org> <20010425111050.B49519@guinness.osdn.com> <3AE6FBEF.188F7673@DougBarton.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 25, 2001 at 09:31:43AM -0700, Doug Barton wrote: >> Is there any particular reason why this port is following the betas that >> seem to change every other day and leave it broken instead of 2000c? I >> don't use this port or even IMAP, I just noticed that people are always >> complaining about it being broken on -ports. Just curious. > I'm starting to think that we need an imap-uw-devel category for this, and > that we should revert imap-uw to 2000c. I do use this port, and the last > two snapshots have resulted in a problem where mail that I delete keeps > coming back from the trash marked unread. I was first notified of the problem with trash mail yesterday. You may want to cut me some slack here. What client are you using? And what exact versions of the port(s) did you have this problem with? Is it an issue with 0104241750 (the latest version)? Reporting detailed information is good (TM). Anyway, I can not reproduce this with imap-uw+cclient 0104241750 and mozilla 0.8.1, Outlook Express 5.50.4522.1200 or Netscape 4.76. And, AFAIK there is no special Trash folder for IMAP. Any folder (except INBOX) is like the other, it's just up to the clients to use them as wanted. RFC 2683 (the only IMAP RFC even mentioning "trash" that I can find) states: "3.4.8. Creating Special-Use Mailboxes It may seem at first that this is part of the namespace issue; it is not, and is only indirectly related to it. A number of clients like to create special-use mailboxes with particular names. Most commonly, clients with a "trash folder" model of message deletion want to create a mailbox with the name "Trash" or "Deleted". Some clients want to create a "Drafts" mailbox, an "Outbox" mailbox, or a "Sent Mail" mailbox. And so on. There are two major interoperability problems with this practice: 1. different clients may use different names for mailboxes with similar functions (such as "Trash" and "Deleted"), or may manage the same mailboxes in different ways, causing problems if a user switches between clients and 2. there is no guarantee that the server will allow the creation of the desired mailbox. The client developer is, therefore, well advised to consider carefully the creation of any special-use mailboxes on the server, and, further, the client must not require such mailbox creation - that is, if you do decide to do this, you must handle gracefully the failure of the CREATE command and behave reasonably when your special-use mailboxes do not exist and can not be created. In addition, the client developer should provide a convenient way for the user to select the names for any special-use mailboxes, allowing the user to make these names the same in all clients used and to put them where the user wants them." I do try to fix anything that is reported to me. The issues on these ports since I started working on them has been, as far as I can remember: a) (fatal) missing distfiles. Has been an issue for these ports for a long time. Permanently fixed through local master sites that I update now. b) missing info on pam session. The daemons were complaining about "No modules loaded for "foo" service." Confusing for some. Fixed in pkg-message. c) missing imap-uw.cnf preventing "make cert" to work with the imap-uw port. Forgotten by me and/or nsayer@freebsd.org. Fixed. d) misleading info on pam session. My bad, I refered to pam_unix which does not have session support at all. Fixed. e) (fatal) troubles building imap-uw due to people not upgrading their cclient installation while upgrading their imap-uw one. I've tried to give feedback to those asking. f) an alleged, insufficiently reported trash problem. The ports have however gained PAM, SSL and DRAC support lately. SSL support also for the Pine port. So I do not think these efforts have been in vain. Latency on getting my updates commited have also contributed greatly to the user problems/complaints here. And I've only been maintainer of the ports for 9 days. > The maintainer's logic for following the snaps is rooted in the dire > warning on the ftp site that all previous versions of imap and cclient have > bugs, however that is true of all software. :) My logic goes more in the line of using what the UW imap developers recommend and present as their main imap distribution. These days, that is unfortunately a development snapshot. My plan is to move over to a stable release once a new one is ready. I believe we should slow down on updating to the latest snapshots though (or even temporarily stalling on a _good_ snapshot), perhaps also revert to an older one if the latest does not work well. Info about older versus newer versions, from the author(s): http://www.washington.edu/imap/listarch/current/msg00325.html http://www.washington.edu/imap/listarch/current/msg00399.html ftp://ftp.cac.washington.edu/imap/imap-README (which you mentioned) > Anders, what do you think about splitting out -devel versions of imap-uw > and cclient? Not necessary in my opinion, the ports have gotten quite stable. It would also be a more demanding effort. Maintainers for these ports hasn't really been growing on trees lately, and I would not support the direction of splitting out -devel versions. Meaning someone else would have to maintain both devel and "stable" versions of the ports then. Regards, -- Anders. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010426020704.A14512>