From a_s_y at sama.ru  Wed Jan  1 16:38:18 2020
From: a_s_y at sama.ru (Sergey)
Date: Thu, 2 Jan 2020 01:38:18 +0400
Subject: licenses of cyrus-imap =?utf-8?q?=D0=B8?= cyrus-sasl
Message-ID: <202001020138.18992.a_s_y@sama.ru>

Hello.

I see what sources of cyrus-imap ? cyrus-sasl have similar but
different COPYING files. Should be they synchronized maybe?

It would be nice to add the license to the spdx project:
https://spdx.org/licenses/

-- 
Regards,
Sergey

From a_s_y at sama.ru  Wed Jan  1 18:51:59 2020
From: a_s_y at sama.ru (Sergey)
Date: Thu, 2 Jan 2020 03:51:59 +0400
Subject: licenses of cyrus-imap and cyrus-sasl
In-Reply-To: <202001020138.18992.a_s_y@sama.ru>
References: <202001020138.18992.a_s_y@sama.ru>
Message-ID: <202001020351.59758.a_s_y@sama.ru>

On Thursday 02 January 2020, Sergey wrote:

> cyrus-imap ? cyrus-sasl

Sorry, "?" -> "and". :-)

-- 
Regards,
Sergey

From marc at marclaporte.com  Sat Jan  4 21:16:19 2020
From: marc at marclaporte.com (Marc Laporte)
Date: Sat, 4 Jan 2020 21:16:19 -0500
Subject: yearly release cycle
In-Reply-To: <76ffb8a6-9204-445e-98e8-5ac19e4e8a3f@dogfood.fastmail.com>
References: <76ffb8a6-9204-445e-98e8-5ac19e4e8a3f@dogfood.fastmail.com>
Message-ID: <CABd-ERE1kKfFYTcOnfU_BtF7rtfpK0MKg_FVBZJhYzqu=PK7wQ@mail.gmail.com>

Dear Ricardo and the Cyrus IMAP community,

I strongly support time-based releases.

3.2 in March 2020 sounds fantastic. JMAP in a stable release: yes!
FYI, we use Cyrus IMAP as part of WikiSuite:
https://wikisuite.org/Cyrus-IMAP

Another component of WikiSuite is Tiki Wiki CMS Groupware. The Tiki
project started in 2002, and since 2009, has been using a time-based
release schedule. It is __by far__ the most important decision we ever
made. A time-based release process has the benefits described by
Ricardo. And more. It gives a rhythm to the project. More things get
contributed. Features are sooner accessible to end users, and thus,
get feedback and improvements.

A related important question: what is the support lifecycle? In Tiki:
A major release every 8 months, which is supported for 9 months. Every
3rd version is a Long Term Support (LTS) version, which is supported
for 5 years. Here is some detailed information about the process:
https://tiki.org/Versions

Given upcoming versions will be quite frequent, it would be really
great if (for example) 3.0.x could be chosen as an LTS version with
security fixes for a number of years.

Thank you and best regards,

Marc

On Fri, Dec 13, 2019 at 10:01 AM Ricardo Signes <rjbs at fastmailteam.com> wrote:
>
> Hey, remember last month when I asked about releasing Cyrus v3.2?
>
> That thread had some more conversation about what needs to get done before v3.2, and I wanted to come back to it and turn some things on their head.
>
> Right now, we?re talking about Cyrus releases being feature-bound. ?We?ll release v3.2 when feature X is done.? I think we?re not being well-served by that. As feature X is delayed (for various reasons that we can?t easily eliminate), it doesn?t just delay the feature, but also all the other minor bugfixes and optimizations that we?ve made in the master branch. Also, it sets up the idea that we delay releases for the sake of fixes, instead of releasing the fixes that are ready.
>
> That is: every additional criteria for a new release is another doorway to delay. Instead of opening those doors, I would rather try to eliminate all of them.
>
> I propose that instead of tying releases to milestones, we tie them to the calendar. For the sake of full disclosure: I am modeling this suggestion on the release cycle of perl, which I ran for several years. I found the process more than satisfactory, then.
>
> A new unstable release of Cyrus is made every month. We promise only that it compiled and passed the Cassandane test suite on the release manager?s computer. It might contain regressions from previous unstable releases, it might have crashers or corruptors. We try to avoid any of these, but the goal here is a snapshot for easy month-to-month testing. These are the odd-middle-digit releases. (3.3.x)
>
> A new major release of Cyrus is made every year. We will have tested it on as many configurations as we can readily test. We will have, some time before the release, frozen the branch for risky changes, to reduce churn. In the meantime, new work lives in feature branches. (The changelogs from each unstable release provide a good basis for the whole-year changelog!) These are the even-middle-digit third-digit-zero releases. (3.4.0)
>
> A new maintenance release of Cyrus is made for the last two stable releases when there are enough fixes to critical bugs to warrant it. These are the even-middle-digit third-digit-nonzero releases (3.4.1)
>
> For the above to work, some more properties need to be maintained.
>
> Maintenance releases should be no-brainers to install, so they must only fix regressions, crashers, security vulnerabilities, and the like. This means that once you?re on 3.4.0, you can always upgrade within the 3.4 series with a minimum risk. It also means you get no optimizations, features, and the like.
>
> Major releases must clearly document any incompatible changes or upgrade steps required. Because non-regression bugfixes aren?t backported, we want everyone to be able to upgrade from major release to major release, so incompatible changes must be kept to a minimum.
>
> In part, this is just ?don?t kill off a feature people use just because it?s a little annoying.? The more important one is ?don?t introduce half-baked things that might need to change,? because people will come to rely on them before you get the updates finished. For features that will require multiple years to get right, they have to go behind a default-off configuration option. I?d strongly suggest they all have a uniform substring like ?unstable?. That way, when a complaint comes in that the behavior of JMAP calendaring has changed, we can reply, ?well, to use it, you had to turn on the unstable_jmap_calendaring? option.
>
> If we go with this policy, we?ll need to?
>
> identify what issues are blockers to v3.2.0, meaning they?re regressions from v3.0 and would reasonably prevent someone from upgrading; this does not include all known bugs, since they may be bugs that already exist in the last stable release!
>
> pick a release target for v3.2.0; I will arbitrarily suggest March 2 as ?not too far off, but far off enough that we can get things in order?; also, if you?re American, March 2 is 3/2 ;-)
>
> produce a changleog, and especially identify what changes in master need documentation as ?incompatible changes?
>
> produce a list of changes in master that should be put behind an unstable configuration option and then do it
>
> decide when to stop merging non-release-related things to master
>
> make a plan for who will do monthly snapshot releases
>
> I?ve spoken with ellie and Bron about just a few of these, such that I don?t think it?s all crazy. (ellie notes, correctly, I think, that the first set of releases like this will be the hard ones, where we work out things like ?how do we keep track of incompatibilities, upgrade steps, and also how do we make snapshots dead easy to release.?) If there?s general agreement, I am definitely ready to pitch in and help try to make it work!
>
> ?
> rjbs
>
>


-- 
Marc Laporte

http://WikiSuite.org
http://PluginProblems.com
http://Avan.Tech

From marc at marclaporte.com  Sun Jan  5 09:02:57 2020
From: marc at marclaporte.com (Marc Laporte)
Date: Sun, 5 Jan 2020 09:02:57 -0500
Subject: Cyrus IMAPd version 3.1.8
In-Reply-To: <44ddb82b-b952-4227-9ee9-31e19c3a3c84@dogfood.fastmail.com>
References: <2f1624ab-d716-499f-9c97-72fa2edc8ff8@www.fastmail.com>
 <44ddb82b-b952-4227-9ee9-31e19c3a3c84@dogfood.fastmail.com>
Message-ID: <CABd-ERGe9onG_2vupEcf4kSRJCrzAUCsA2YWKx6w8cnyioFv5w@mail.gmail.com>

Dear Bron,

Congratulations and thank you for keeping the versions so close.

It reminds me of this blog post:
http://community.redhat.com/blog/2015/03/upstream-first-turning-openstack-into-an-nfv-platform/

Best regards,

Marc


On Thu, Dec 5, 2019, 06:54 Bron Gondwana <brong at fastmailteam.com> wrote:

> FYI: this is almost exactly what Fastmail is running in production right
> now - it has about 4 minor commits beyond current production, and is
> missing the handful of Fastmail specific magic!
>
> OldRev: cyrus-imapd-3.1.8
> NewRev: fmstable-20191203v1
>
> Removes the following commits:
>   44210c59 2019-12-02 brong: jmap: don't need to update the alive value,
> mailbox.c already did that on write
>   463f6291 2019-12-03 brong: caldav: fix bogus && to & in read_cb
>   41f6117e 2019-12-02 brong: caldav: scheduling enabled should always be
> checked on the shared annotation (aka: owner)
>   3d69f08c 2019-12-03 rsto: jmap_mail: report "xapian" perf filter for
> contact group searches
>   469cacc0 2019-12-04 rsto: jmap_mail: move Identity data to
> jmap:submission capability
>   dc91d2d4 2019-12-04 rsto: jmap_mail: reject mutable search in
> queryChanges
>   0b757d88 2019-12-04 rsto: jmap_mail_query: don't crash for nested
> multipart alternatives
>   9b30ee3f 2019-12-04 ellie: release notes for 3.1.8
>   18d157e0 2019-12-04 ellie: fix cve link in 3.1.7 release notes
>   96d194de 2019-12-04 ellie: developer release 3.1.8
>
> Adds the following commits:
>   1c6ed3ad 2015-03-30 brong: Fastmail Secrets (no rated)
>   5ba2dbee 2015-03-30 brong: Fastmail ONLY - make assertion failures and
> fatal errors into coredumps
>   26d563c1 2015-03-30 brong: Fastmail ONLY - Remove sieve action string
>   0e71d55c 2017-08-18 brong: Fastmail ONLY - don't fiddle timezone data in
> http_caldav_sched.c
>   61da4794 2018-06-26 brong: Fastmail ONLY - re-apply the VEVENTS ONLY
> patch for alarms
>   c51f3989 2019-02-06 rsto: Fastmail ONLY - mailbox owners always have
> ACL_ADMIN in JMAP
>   2f3e9516 2015-08-07 brong: mkdebian: fastmail build script (v29)
>
> This is from the attached "GitBranchDiff" script.
>
> All the commits listed as only being on "master" will be merged into
> Fastmail production next week when we rebase our build on the 3.1.8 tag
> (and possibly more changes from master too)
>
> Cheers,
>
> Bron.
>
> On Wed, Dec 4, 2019, at 14:27, ellie timoney wrote:
>
> The Cyrus team is pleased to announce the immediate availability of a new
> version of Cyrus IMAP: 3.1.8
>
> This is a snapshot of the master branch, and should be considered for
> testing purposes and bleeding-edge features only. It is available as a git
> tag, which can be found here:
>
> https://github.com/cyrusimap/cyrus-imapd/releases/tag/cyrus-imapd-3.1.8
>
> Join us on Github at https://github.com/cyrusimap/cyrus-imapd to report
> issues, join in the deliberations of new features for the next Cyrus IMAP
> release, and to contribute to the documentation.
>
> On behalf of the Cyrus team,
>
> ellie
>
>
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   brong at fastmailteam.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20200105/04d754f7/attachment.html>

From ellie at fastmail.com  Wed Jan  8 00:02:16 2020
From: ellie at fastmail.com (ellie timoney)
Date: Wed, 08 Jan 2020 16:02:16 +1100
Subject: The master janitor goes crazy / Re: Debugging Deadlocks
In-Reply-To: <c4fca564-147c-4be2-9fe6-b702b61199e3@www.fastmail.com>
References: <92cca1d7baac62ef2b3cbe3f59a771796aba19dd.camel@aegee.org>
 <78928faba6a46f1b60e31d29d1061668a372cda3.camel@aegee.org>
 <feb5a91b-56d0-4ac2-b16c-e207362be8f3@www.fastmail.com>
 <25d97486-b257-44bb-b47a-3ddc9b16d5de@www.fastmail.com>
 <cd241d576c9902da1da519b7d6d4699eb74a84d2.camel@aegee.org>
 <c4fca564-147c-4be2-9fe6-b702b61199e3@www.fastmail.com>
Message-ID: <e99ff2f2-86fa-4879-b2eb-8504fd6583bc@www.fastmail.com>

Okay, just got distracted by this happening again.  The way I'm reproducing it is by ^C'ing a Cassandane run (which cleanly shuts down the cyrus instances it had started) during the JMAP tests, and I guess I'm sometimes getting lucky on the timing and hitting this.

On Wed, Dec 4, 2019, at 2:22 PM, ellie timoney wrote:
> I think the really useful information to collect next time this happens 
> (and while the master process is still running) is:
> 
> * What does lsof tell us about that ready file descriptor (in the 
> example, fd 11)?  I would be very interested to know if it's a client 
> socket, or an internal messaging socket (that service processes use to 
> tell master their status).

master  3121 cyrus   11u  IPv4           49559608      0t0      TCP localhost:9146 (LISTEN)

This is the port the http service was listening on.

> * If you can attach a debugger and step through a couple of iterations 
> of master's big "for (;;) {" loop, what path is it taking?  What 
> decisions is it making?

So the problem pops up here:

            /* connections */
            if (y >= 0 && Services[i].ready_workers == 0 &&
                Services[i].nactive < Services[i].max_workers &&
                !service_is_fork_limited(&Services[i])) {
                if (verbose > 2)
                    syslog(LOG_DEBUG, "listening for connections for %s/%s",
                           Services[i].name, Services[i].familyname);
                FD_SET(y, &rfds);
                if (y > maxfd) maxfd = y;
            }

(gdb) p Services[i]
$28 = {name = 0x55df363956c0 "http", listen = 0x55df36395170 "127.0.0.1:9146", 
  proto = 0x55df36395680 "tcp", exec = 0x55df363956e0, babysit = 0, 
  associate = 0, family = 2, familyname = 0x55df35a8c780 "ipv4", socket = 11, 
  stat = {12, 13}, desired_workers = 0, max_workers = 2147483647, maxfds = 0, 
  maxforkrate = 0, ready_workers = 0, nforks = 1, nactive = 1, 
  nconnections = 1, forkrate = 0, nreadyfails = 0, lastreadyfail = 0, 
  last_interval_start = {tv_sec = 1578455582, tv_usec = 342312}, 
  interval_forks = 1}

The http service has shut down already... sort of. It's hanging around as a defunct process:
cyrus     3143  3121  0 14:53 ?        00:00:00 [httpd] <defunct>

We have no ready_workers, and nactive is less than max_workers, so we're adding the service socket (fd 11) to the listen set.  If verbose were large enough, I think we would be logging "listening for connections for %s/%s" during this loop.

So, we have data on the socket for this service, and if we weren't already in_shutdown we'd be trying to spawn a new service process to handle it.  But we ARE in_shutdown, so we don't spawn a service, so the data on the socket remains unhandled.

We don't simply finish shutting down, because that nactive=1 in the service table entry means we think we still have children, so we call child_janitor and then go round the loop again.

Sooooo we're waiting for child_janitor to clean up after the http service, I guess.

Inside child_janitor, here's the entry:
(gdb) print **p
$36 = {pid = 3143, service_state = SERVICE_STATE_BUSY, janitor_deadline = 0, 
  si = 1, 
  desc = 0x55df36397f30 "type:SERVICE name:http path:/dev/shm/cyrus/main/libexec/httpd", spawntime = {tv_sec = 1578455582, tv_usec = 682977}, sighuptime = -1, 
  next = 0x0}

So, it thinks the http process is still busy, so we're spinning and waiting for it...  but the defunct state tells us it's already exited, and the system is just waiting for the parent process (master) to waitpid() it before getting rid of it completely.

It's pretty clear that there's still client data on that socket, but I'm not sure if "shut down Cyrus while there's still a client sending data to httpd" is enough to trigger it, or if it's more subtle.  The data pending on the socket is the reason we see pselect() called over and over again, but I don't think it's the cause of the problem: without that pending data, we'd still be hanging here instead of shutting down cleanly, but we'd be blocked in pselect() instead.

We _should_ have gotten a sigchld from httpd shutting down, and then reap_child should have waitpid'd it and cleaned up the child table, so we shouldn't be spinning like this.  So I guess the failure occurred somewhere in the sigchld handling, but by the time I notice it spinning it's too late to see what happened.  Did the sigchld go missing?  Did reap_child do the wrong thing?  Who knows!

I don't have any further insight at the moment.  I guess if I can find a way to reproduce it reasonably reliably, then I can litter reap_child with debug output and see what it reports just before it goes pear-shaped....

Cheers,

ellie

From dilyan.palauzov at aegee.org  Thu Jan  9 07:14:58 2020
From: dilyan.palauzov at aegee.org (=?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?=)
Date: Thu, 09 Jan 2020 12:14:58 +0000
Subject: The master janitor goes crazy / Re: Debugging Deadlocks
In-Reply-To: <e99ff2f2-86fa-4879-b2eb-8504fd6583bc@www.fastmail.com>
References: <92cca1d7baac62ef2b3cbe3f59a771796aba19dd.camel@aegee.org>
 <78928faba6a46f1b60e31d29d1061668a372cda3.camel@aegee.org>
 <feb5a91b-56d0-4ac2-b16c-e207362be8f3@www.fastmail.com>
 <25d97486-b257-44bb-b47a-3ddc9b16d5de@www.fastmail.com>
 <cd241d576c9902da1da519b7d6d4699eb74a84d2.camel@aegee.org>
 <c4fca564-147c-4be2-9fe6-b702b61199e3@www.fastmail.com>
 <e99ff2f2-86fa-4879-b2eb-8504fd6583bc@www.fastmail.com>
Message-ID: <97867d3c5de7ae44f16532594100a5d987a4fe83.camel@aegee.org>

Hello,

I had some more observations.  After `killall -9 master` there are zombies, so maybe the master thinks that some process
IDs have to finish, but in fact the ready PIDs are different.  I have not digged this further.

I had problems with the ID: a lot of read/write operations to the disk caused very slow syslog-daemon.  This in turn
means, that each syslog() call needs very long time (a minute or three) to return, as the syslog daemon needs that much
time to come to the syslog() call and conclude that this particular call causes no write on the disk.

After I both improved the IO on the system and removed some syslog() calls in Cyrus IMAP, the shutdown works fast.  I
have not done excessive experiments, but in the past the janitor went grazy on shutdown often and now this does not
happen.

Greetings
  ?????

On Wed, 2020-01-08 at 16:02 +1100, ellie timoney wrote:
> Okay, just got distracted by this happening again.  The way I'm reproducing it is by ^C'ing a Cassandane run (which cleanly shuts down the cyrus instances it had started) during the JMAP tests, and I guess I'm sometimes getting lucky on the timing and hitting this.
> 
> On Wed, Dec 4, 2019, at 2:22 PM, ellie timoney wrote:
> > I think the really useful information to collect next time this happens 
> > (and while the master process is still running) is:
> > 
> > * What does lsof tell us about that ready file descriptor (in the 
> > example, fd 11)?  I would be very interested to know if it's a client 
> > socket, or an internal messaging socket (that service processes use to 
> > tell master their status).
> 
> master  3121 cyrus   11u  IPv4           49559608      0t0      TCP localhost:9146 (LISTEN)
> 
> This is the port the http service was listening on.
> 
> > * If you can attach a debugger and step through a couple of iterations 
> > of master's big "for (;;) {" loop, what path is it taking?  What 
> > decisions is it making?
> 
> So the problem pops up here:
> 
>             /* connections */
>             if (y >= 0 && Services[i].ready_workers == 0 &&
>                 Services[i].nactive < Services[i].max_workers &&
>                 !service_is_fork_limited(&Services[i])) {
>                 if (verbose > 2)
>                     syslog(LOG_DEBUG, "listening for connections for %s/%s",
>                            Services[i].name, Services[i].familyname);
>                 FD_SET(y, &rfds);
>                 if (y > maxfd) maxfd = y;
>             }
> 
> (gdb) p Services[i]
> $28 = {name = 0x55df363956c0 "http", listen = 0x55df36395170 "127.0.0.1:9146", 
>   proto = 0x55df36395680 "tcp", exec = 0x55df363956e0, babysit = 0, 
>   associate = 0, family = 2, familyname = 0x55df35a8c780 "ipv4", socket = 11, 
>   stat = {12, 13}, desired_workers = 0, max_workers = 2147483647, maxfds = 0, 
>   maxforkrate = 0, ready_workers = 0, nforks = 1, nactive = 1, 
>   nconnections = 1, forkrate = 0, nreadyfails = 0, lastreadyfail = 0, 
>   last_interval_start = {tv_sec = 1578455582, tv_usec = 342312}, 
>   interval_forks = 1}
> 
> The http service has shut down already... sort of. It's hanging around as a defunct process:
> cyrus     3143  3121  0 14:53 ?        00:00:00 [httpd] <defunct>
> 
> We have no ready_workers, and nactive is less than max_workers, so we're adding the service socket (fd 11) to the listen set.  If verbose were large enough, I think we would be logging "listening for connections for %s/%s" during this loop.
> 
> So, we have data on the socket for this service, and if we weren't already in_shutdown we'd be trying to spawn a new service process to handle it.  But we ARE in_shutdown, so we don't spawn a service, so the data on the socket remains unhandled.
> 
> We don't simply finish shutting down, because that nactive=1 in the service table entry means we think we still have children, so we call child_janitor and then go round the loop again.
> 
> Sooooo we're waiting for child_janitor to clean up after the http service, I guess.
> 
> Inside child_janitor, here's the entry:
> (gdb) print **p
> $36 = {pid = 3143, service_state = SERVICE_STATE_BUSY, janitor_deadline = 0, 
>   si = 1, 
>   desc = 0x55df36397f30 "type:SERVICE name:http path:/dev/shm/cyrus/main/libexec/httpd", spawntime = {tv_sec = 1578455582, tv_usec = 682977}, sighuptime = -1, 
>   next = 0x0}
> 
> So, it thinks the http process is still busy, so we're spinning and waiting for it...  but the defunct state tells us it's already exited, and the system is just waiting for the parent process (master) to waitpid() it before getting rid of it completely.
> 
> It's pretty clear that there's still client data on that socket, but I'm not sure if "shut down Cyrus while there's still a client sending data to httpd" is enough to trigger it, or if it's more subtle.  The data pending on the socket is the reason we see pselect() called over and over again, but I don't think it's the cause of the problem: without that pending data, we'd still be hanging here instead of shutting down cleanly, but we'd be blocked in pselect() instead.
> 
> We _should_ have gotten a sigchld from httpd shutting down, and then reap_child should have waitpid'd it and cleaned up the child table, so we shouldn't be spinning like this.  So I guess the failure occurred somewhere in the sigchld handling, but by the time I notice it spinning it's too late to see what happened.  Did the sigchld go missing?  Did reap_child do the wrong thing?  Who knows!
> 
> I don't have any further insight at the moment.  I guess if I can find a way to reproduce it reasonably reliably, then I can litter reap_child with debug output and see what it reports just before it goes pear-shaped....
> 
> Cheers,
> 
> ellie


From rjbs at fastmailteam.com  Tue Jan 14 12:27:02 2020
From: rjbs at fastmailteam.com (Ricardo Signes)
Date: Tue, 14 Jan 2020 12:27:02 -0500
Subject: moving the Cyrus mailing lists?
Message-ID: <0d6face2-0ea9-4dac-9859-de144e3deeca@dogfood.fastmail.com>

This morning, I updated a bunch of my Sieve to split out some mailing list mail, and remembered that I've been meaning to float the idea of moving Cyrus's development lists.

Right now, the Cyrus lists are hosted at lists.andrew.cmu.edu. My understanding is that CMU is no longer involved with Cyrus development, but we've got assurances that these lists will keep working indefinitely. So: I don't think we *need* to do anything.

Fastmail is deeply committed to Cyrus IMAP, and we have a mailing list product (Topicbox) that I think is really good, with great search (powered by Cyrus + Xapian), a great web UI for both public archives and composing mail, and it still does all the things you'd expect from mailing lists: accepts mail via SMTP, has a moderation queue, and so on.

You can see an example open source project hosted on Topicbox here: https://illumos.topicbox.com/ <https://illumos.topicbox.com/latest>

So, consider this an offer. I'll set up a gratis Topicbox organization for hosting the Cyrus lists and we'll import past mail from the lists into the organization and, if we can get the subscriber lists, transfer subscribers. For me, the benefits are having an easier-to-search archive and living without fear that the list might go away. Obviously, I'm also a Fastmail employee, and I'm happy to show off Topicbox, too.

I'll wait a while to hear general interest in the idea before doing anything else.

-- 
Ricardo Signes (rjbs)
CTO, Fastmail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20200114/62836288/attachment.html>

From fedoraproject at cyberpear.com  Tue Jan 14 12:42:49 2020
From: fedoraproject at cyberpear.com (James Cassell)
Date: Tue, 14 Jan 2020 12:42:49 -0500
Subject: moving the Cyrus mailing lists?
In-Reply-To: <0d6face2-0ea9-4dac-9859-de144e3deeca@dogfood.fastmail.com>
References: <0d6face2-0ea9-4dac-9859-de144e3deeca@dogfood.fastmail.com>
Message-ID: <cf07fcaf-008d-4617-8a2a-0c6aa7020863@www.fastmail.com>


On Tue, Jan 14, 2020, at 12:27 PM, Ricardo Signes wrote:
> This morning, I updated a bunch of my Sieve to split out some mailing 
> list mail, and remembered that I've been meaning to float the idea of 
> moving Cyrus's development lists.
> 
> Right now, the Cyrus lists are hosted at lists.andrew.cmu.edu. My 
> understanding is that CMU is no longer involved with Cyrus development, 
> but we've got assurances that these lists will keep working 
> indefinitely. So: I don't think we *need* to do anything.
> 
> Fastmail is deeply committed to Cyrus IMAP, and we have a mailing list 
> product (Topicbox) that I think is really good, with great search 
> (powered by Cyrus + Xapian), a great web UI for both public archives 
> and composing mail, and it still does all the things you'd expect from 
> mailing lists: accepts mail via SMTP, has a moderation queue, and so on.
> 
> You can see an example open source project hosted on Topicbox here: 
> https://illumos.topicbox.com/ <https://illumos.topicbox.com/latest>
> 
> So, consider this an offer. I'll set up a gratis Topicbox organization 
> for hosting the Cyrus lists and we'll import past mail from the lists 
> into the organization and, if we can get the subscriber lists, transfer 
> subscribers. For me, the benefits are having an easier-to-search 
> archive and living without fear that the list might go away. Obviously, 
> I'm also a Fastmail employee, and I'm happy to show off Topicbox, too.
> 
> I'll wait a while to hear general interest in the idea before doing 
> anything else.
> 

-1 for a straight migration, but only because I really hate when things break. (...as Fastmail has been prone to do for its legacy users.) Is there a way to have Topicbox mirror the list, and allow folks to try it out for a while?

V/r,
James Cassell

"If it ain't broke, don't fix it."

From ellie at fastmail.com  Tue Jan 14 18:55:00 2020
From: ellie at fastmail.com (ellie timoney)
Date: Wed, 15 Jan 2020 10:55:00 +1100
Subject: feature freeze on master until Feb 3
Message-ID: <b0dee868-93bd-49b2-88f1-a4c03708490b@www.fastmail.com>

Hi,

I plan on branching off a new cyrus-imapd-3.2 branch at the start of February (probably on the 3rd), so I can start making beta releases in preparation for an eventual real release in March (hopefully!).

In the meantime, if you have big, risky branches that should not be in the 3.2 release, please hold off on merging them to master for a little longer.  Once 3.2 diverges from master, you can go hog wild ;)

I'm about to re-audit the https://github.com/cyrusimap/cyrus-imapd/labels/3.2 label for what's actually feasible to include, and untag the rest.  I will probably need to ask some of you about some of these, for code areas I don't know.  I'd appreciate prompt responses. :)

Cheers,

ellie

From rjbs at fastmailteam.com  Tue Jan 14 21:18:47 2020
From: rjbs at fastmailteam.com (Ricardo Signes)
Date: Tue, 14 Jan 2020 21:18:47 -0500
Subject: guide to migrating to virtdomains: userid
Message-ID: <54e85159-fdaf-4aa6-9d57-4d7f4ff5114b@dogfood.fastmail.com>

We have documented that we wish to discourage settings for userid other than virtdomains. In discussion earlier today, ellie and I chatted about the fact that 3.2 is a good time to take *some* action in that regard.

I think I have a question and a request for volunteer.

*QUESTION:* Do we have an established policy for how features are deprecated and removed? For example, if we can make a backward incompatible change in Cyrus X.Y.0, how long in advance do we need to provide notice, and via what means?

In this case, the very least we can do is add it to the documentation. The second-to-least thing we can do is issue a warning when a deprecated setting is found, even if we don't have a timetable for removal.

*REQUEST*: We want people to change from virtdomains:X to virtdomains:userid for all non-userid values of X. It would be a kindness to provide a migration guide. Is anyone competent to write such a guide? (My eye is drawn to one Bron Gondwana, but perhaps he migrated his user base so long ago that all his wisdom on that topic has since been replaced by new wisdom.)

-- 
Ricardo Signes (rjbs)
CTO, Fastmail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20200114/b1009c77/attachment-0001.html>

From ellie at fastmail.com  Tue Jan 14 21:47:21 2020
From: ellie at fastmail.com (ellie timoney)
Date: Wed, 15 Jan 2020 13:47:21 +1100
Subject: guide to migrating to virtdomains: userid
In-Reply-To: <54e85159-fdaf-4aa6-9d57-4d7f4ff5114b@dogfood.fastmail.com>
References: <54e85159-fdaf-4aa6-9d57-4d7f4ff5114b@dogfood.fastmail.com>
Message-ID: <1d485a32-2607-4ac9-8900-261b1a85de57@www.fastmail.com>

On Wed, Jan 15, 2020, at 1:18 PM, Ricardo Signes wrote:
> *QUESTION:* Do we have an established policy for how features are deprecated and removed? For example, if we can make a backward incompatible change in Cyrus X.Y.0, how long in advance do we need to provide notice, and via what means?
> 
> In this case, the very least we can do is add it to the documentation. The second-to-least thing we can do is issue a warning when a deprecated setting is found, even if we don't have a timetable for removal.

[This is not really what you're asking, but we have a mechanism for deprecating config options. This looks like it's mostly been used so far for renaming options from badnameswithnounderscores to sensible_names. It's not quite useful here though: it deals with deprecating _entire options_, not merely "some values thereof".]

My longer term gut feel on this one (virtdomains:userid) specifically is: this time, we encourage (via good upgrade docs) people to consider switching to the only-known-good setting, but we change nothing. Next time, if we feel like the world is ready for it, we make the good setting the default (and the upgrade doc at that time will need to be clear that people who hadn't already migrated to it need to either a) migrate to it, or b) explicitly set their config to the value they may previously have had by default).

Historically, 3.0 changed the default values of unixhierarchyseparator and altnamespace. We talked a lot about it on the mailing lists, and the upgrade docs were clear about it. I think it may have caused some confusion, but I also think on the whole people mostly coped. But I guess maybe people coped by just setting the setting to whatever they were already using (rather than dealing with the changed behaviour). At one point, 3.0 documentation said the default value of virtdomains had changed too, but that didn't actually happen, and I think the bad documentation was identified and corrected during the beta process.

3.0 was a pretty massive upgrade from 2.x, though. 3.0->3.2 is, I think, a much smaller step, which might mean things go more smoothly, or might mean people are more cavalier about it and thus trip over stuff.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20200115/ada4b453/attachment.html>

From ellie at fastmail.com  Thu Jan 30 18:35:01 2020
From: ellie at fastmail.com (ellie timoney)
Date: Fri, 31 Jan 2020 10:35:01 +1100
Subject: Error building cyrus-imapd-3.1.8
In-Reply-To: <DA16D9DB.24C31%David.Luong@interoptechnologies.com>
References: <DA0D4AEF.24224%David.Luong@interoptechnologies.com>
 <d4918175-e2b8-4f14-9b87-fbe46017d306@www.fastmail.com>
 <DA16D9DB.24C31%David.Luong@interoptechnologies.com>
Message-ID: <f18bf860-08d3-4c3a-9e1b-f866b624a4fb@www.fastmail.com>

Hi David,

Thanks for tracking those down and passing it on.

I still haven't had a chance to look at this any closer, but I've copied it into https://github.com/cyrusimap/cyrus-imapd/issues/2982 so it doesn't languish in my inbox indefinitely. :)

Cheers,

ellie

On Thu, Dec 12, 2019, at 10:40 AM, Luong, David wrote:
> Hi Ellie,
> 
> I finally resolved the dependencies with the following packages.
> 
> $ yum install python-docutils.noarch -y
> $ yum install python-sphinx -y
> $ yum install python-pygments.noarch -y
> $ yum install python3-pip.noarch ?y
> 
> Regards,
> David.
> 
> 
> *From: * Cyrus-devel <cyrus-devel-bounces+david.luong=interoptechnologies.com at lists.andrew.cmu.edu> on behalf of ellie timoney <ellie at fastmail.com>
> *Date: * Thursday, December 5, 2019 at 4:30 PM
> *To: * "cyrus-devel at lists.andrew.cmu.edu" <cyrus-devel at lists.andrew.cmu.edu>
> *Subject: * Re: Error building cyrus-imapd-3.1.8
> 
> Hi David,
> 
> That smells like a missing dependency. Have you reviewed https://www.cyrusimap.org/dev/imap/developer/compiling.html ?
> 
> Looking at the error, and glancing at the dependencies list, I wonder if you need 'perl-devel'. It's listed as a developer-only dependency, but because you're building from a git tag and not a distribution tarball (where some things with tricky dependencies have been pre-compiled), you will probably need some or all of the developer dependencies as well.
> 
> It would be nice if configure would report the missing dependency, instead of succeeding and then the build fails. If you can track down which missing dependency caused this problem, please let us know and I'll update configure to complain about it. :)
> 
> Cheers,
> 
> ellie
> 
> On Thu, Dec 5, 2019, at 4:37 AM, Luong, David wrote:
>> Hi,
>> 
>> I?m building with the following options:
>> 
>> $ autoreconf -i -s
>> $ ./configure --enable-http --enable-jmap --enable-autocreate --enable-murder --enable-idled --enable-xapian --prefix=/usr/cyrus
>> $ make
>> 
>> The build is not completed with the following errors.
>> 
>> make[2]: Leaving directory `/cyrus/cyrus-imapd-3.1.8'
>> Making all in perl/annotator
>> make[2]: Entering directory `/cyrus/cyrus-imapd-3.1.8/perl/annotator'
>> make[2]: *** No rule to make target `all'. Stop.
>> make[2]: Leaving directory `/cyrus/cyrus-imapd-3.1.8/perl/annotator'
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory `/cyrus/cyrus-imapd-3.1.8'
>> make: *** [all] Error 2
>> 
>> 
>> Please advise.
>> 
>> Regards,
>> David.
>> 
>> 
>> 
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20200131/7fc13098/attachment.html>