Re: cyrus 2.2 status
> On Tue, 17 Dec 2002 20:28:57 -0600, > archive info-cyrus <[EMAIL PROTECTED]> (ai) writes: ai> --On Tuesday, December 17, 2002 4:24 PM -0800 Jonathan Marsden ai> <[EMAIL PROTECTED]> wrote: ai> | So the question becomes: what, if anything can non-CMU people do that ai> | would help cause a release of 2.2 (or 2.1 with virtdomains in it??) to ai> | happen sooner rather than later? ai> Just a guess... send Ken some money. Actually, perhaps the CMU developers ought to think of doing what the SpamAssassin developers are doing: create Amazon (or other vendors) wish lists so that folks eager for enhancements can demonstrate their appreciation. ;-) Ho. Ho. -- Amos
Re: cyrus 2.2 status
On Wed, 18 Dec 2002, Ken Murchison wrote: > Its not a matter of CMU needing/using virtdomain support. CMU is not > using altnamespace or unixhiersep stuff in 2.1, and that was released. Well, yes, but we did have an interest in moving to SASL2. Though I still agree that what we run internally often has little to do with official releases (we're almost always running a CVS snapshot of some type instead of a "real" version, though they sometimes coinside with only minor differences) > What gets developed has a lot to do with what CMU needs/wants, but > releases are usually based on code quality/stability and time. 2.2 has > a lot of other changes (NNTP support, new config option architecture, > config options for stuff in lib/, restructured ANNOTATEMORE code, etc) > which need more testing and documentation. Yes, this is definately the main reason we're not doing a "real" 2.2 release yet. Also, depending on how things sort out locally we may be adding the sieve bytecode support, but that's the only "major" feature left. > IIRC, Rob is targeting some time in mid/late January for a 2.2.0 > release. Probably a bit later at this point, but I'd be surprised if it got as late as march and we didn't even have an alpha out. > > So the question becomes: what, if anything can non-CMU people do that > > would help cause a release of 2.2 (or 2.1 with virtdomains in it??) to > > happen sooner rather than later? > > 2.1 w/virtdomain definitely won't happen, at least not "officially" > without some kind of incentive to do so. Agreed, especially since the 2.2 branch was basically started to keep the virtdomain code out of the "stable" code. There really isn't any incentive to do so. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: cyrus 2.2 status
Jonathan Marsden wrote: > > On 13 Dec 2002, Jure Pecar writes: > > > On Thu, 12 Dec 2002 20:31:41 -0500 Ken Murchison <[EMAIL PROTECTED]> wrote: > > >> I addition to what Rob already mentioned, there needs to be more > >> work done on documenting the virtdomain support and tying some > >> loose ends. > > > Yes, virtdomains are actually the #1 thing i'm interested in cyrus > > 2.2 ... I'm sure there are more people interested, so i think it > > would be nice to provide either a stable, known working cvs branch > > of 2.2 or a patch with a backport of virtdomains stuff to 2.1. I'm > > willing to help here, just give me some directions. > > I would also very much like to see this happen. To get Red Hat 7.x > RPMs of cyrus-imapd with virtdomain support, I grabbed the CVS for 2.2 > as of late September and turned it ito RPMs and since then I have > stuck with that. I'm about to resync with CVS again to pick up the > recent security fixes. But I'd be more comfortable with using a > somewhat supported (or at least officially labelled!) version of the > codebase. > > The issue on when releases happen seems to me to be that CMU has its > own priorities, and tends to stick to them. Which is absolutely fine, > and probably the right thing for them to do. The result is that, even > if a backport patch of the virtdomain code to 2.1.x happens, I'm not > sure it would really help in the supportedness/officialness stakes, > since CMU would not be using it :-) > > So it may be that until CMU finds an internal need for something that > is in 2.2 but not in 2.1, there's little anyone else can do to get > virtdomain support "more official" than it just being there in CVS. Its not a matter of CMU needing/using virtdomain support. CMU is not using altnamespace or unixhiersep stuff in 2.1, and that was released. What gets developed has a lot to do with what CMU needs/wants, but releases are usually based on code quality/stability and time. 2.2 has a lot of other changes (NNTP support, new config option architecture, config options for stuff in lib/, restructured ANNOTATEMORE code, etc) which need more testing and documentation. IIRC, Rob is targeting some time in mid/late January for a 2.2.0 release. > So the question becomes: what, if anything can non-CMU people do that > would help cause a release of 2.2 (or 2.1 with virtdomains in it??) to > happen sooner rather than later? 2.1 w/virtdomain definitely won't happen, at least not "officially" without some kind of incentive to do so. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: cyrus 2.2 status
--On Tuesday, December 17, 2002 4:24 PM -0800 Jonathan Marsden <[EMAIL PROTECTED]> wrote: | So the question becomes: what, if anything can non-CMU people do that | would help cause a release of 2.2 (or 2.1 with virtdomains in it??) to | happen sooner rather than later? Just a guess... send Ken some money. Amos
Re: cyrus 2.2 status
On 13 Dec 2002, Jure Pecar writes: > On Thu, 12 Dec 2002 20:31:41 -0500 Ken Murchison <[EMAIL PROTECTED]> wrote: >> I addition to what Rob already mentioned, there needs to be more >> work done on documenting the virtdomain support and tying some >> loose ends. > Yes, virtdomains are actually the #1 thing i'm interested in cyrus > 2.2 ... I'm sure there are more people interested, so i think it > would be nice to provide either a stable, known working cvs branch > of 2.2 or a patch with a backport of virtdomains stuff to 2.1. I'm > willing to help here, just give me some directions. I would also very much like to see this happen. To get Red Hat 7.x RPMs of cyrus-imapd with virtdomain support, I grabbed the CVS for 2.2 as of late September and turned it ito RPMs and since then I have stuck with that. I'm about to resync with CVS again to pick up the recent security fixes. But I'd be more comfortable with using a somewhat supported (or at least officially labelled!) version of the codebase. The issue on when releases happen seems to me to be that CMU has its own priorities, and tends to stick to them. Which is absolutely fine, and probably the right thing for them to do. The result is that, even if a backport patch of the virtdomain code to 2.1.x happens, I'm not sure it would really help in the supportedness/officialness stakes, since CMU would not be using it :-) So it may be that until CMU finds an internal need for something that is in 2.2 but not in 2.1, there's little anyone else can do to get virtdomain support "more official" than it just being there in CVS. So the question becomes: what, if anything can non-CMU people do that would help cause a release of 2.2 (or 2.1 with virtdomains in it??) to happen sooner rather than later? Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
Re: cyrus 2.2 status (fwd)
On Fri, 13 Dec 2002, John Alton Tamplin wrote: > Rob Siemborski wrote: > > >But unless the contents of the folders are backed up in this way too, you > >haven't really gained a significant amount, since the transactions that > >cyrus needs to make rely on the contents of the filesystem as well. > > > > > True, although with the metadata secure you can politely tell the user > their message is gone I agree that is of little benefit unless the > messages are stored in the database as well. For a large installation, > avoiding the downtime to reconstruct large databases after a crash might > be a benefit worth the effort. > True. But you do not need an SQL engine just for online backups. Most new filesystems support 'snapshot' which is used for 'online' filesystem backups. -- Igor
Re: cyrus 2.2 status
Rob Siemborski wrote: But unless the contents of the folders are backed up in this way too, you haven't really gained a significant amount, since the transactions that cyrus needs to make rely on the contents of the filesystem as well. True, although with the metadata secure you can politely tell the user their message is gone I agree that is of little benefit unless the messages are stored in the database as well. For a large installation, avoiding the downtime to reconstruct large databases after a crash might be a benefit worth the effort. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Re: cyrus 2.2 status
On Thu, 12 Dec 2002, John Alton Tamplin wrote: > Well, most real databases offer online backup capability so you can get > a robust backup even while processing transactions, and with continuous > log backup a crash can't lose any committed transactions. But unless the contents of the folders are backed up in this way too, you haven't really gained a significant amount, since the transactions that cyrus needs to make rely on the contents of the filesystem as well. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: cyrus 2.2 status
On Thu, 12 Dec 2002 20:31:41 -0500 Ken Murchison <[EMAIL PROTECTED]> wrote: > I addition to what Rob already mentioned, there needs to be more work > done on documenting the virtdomain support and tying some loose ends. Yes, virtdomains are actually the #1 thing i'm interested in cyrus 2.2 ... I'm sure there are more people interested, so i think it would be nice to provide either a stable, known working cvs branch of 2.2 or a patch with a backport of virtdomains stuff to 2.1. I'm willing to help here, just give me some directions. -- Jure Pecar
Re: cyrus 2.2 status
Jure Pecar wrote: > > Hi all, > > what is the current status of the cyrus 2.2 cvs branch? judging by the cvs > commits lately, there are just various little cleanups here and there ... is > there anything big left on the TODO list for 2.2? I addition to what Rob already mentioned, there needs to be more work done on documenting the virtdomain support and tying some loose ends. I'm also doing more work on the NNTP support. I started working on a nntpproxyd for Murder, but got sidetracked consolidating the client side authentication code that is present in each of the current proxies (some of which was committed today). Documentation of the NNTP support needs to be done to replace the legacy Usenet stuff which isn't even functional anymore. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: cyrus 2.2 status
Rob Siemborski wrote: The only *possible* advantage I see is it gets cyrus's databases backed up with an SQL database, but since you still have to back up the cyrus datastore anyway, you haven't won anything. Well, most real databases offer online backup capability so you can get a robust backup even while processing transactions, and with continuous log backup a crash can't lose any committed transactions. It may also have better scalability on the upper end. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Re: cyrus 2.2 status
On Thu, 12 Dec 2002, Jure Pecar wrote: > what is the current status of the cyrus 2.2 cvs branch? judging by the cvs > commits lately, there are just various little cleanups here and there ... is > there anything big left on the TODO list for 2.2? The big one is getting the sieve bytecode support merged in, but that needs to undergo testing that may not be able to happen until late January atleast. In any case, I'm not totally sure this feature will make it anyway. IPv6 support should be in 2.2, and I'm waiting to hear back from Hajimu on a few issues I have with his patch (http://bugzilla.andrew.cmu.edu/show_bug.cgi?id=1651). I'm personally currently working on making ptloader able to take authorization modules (I just finished a first version of it with the AFS PTS backend). This would mean that we could, for example, support LDAP groups. Long-term has this stuff moving into SASL, but atleast not until SASL hits 2.2 (this will happen as the IETF draft SASL API settles down a bit). The AFS stuff should probably hit CVS tomorrow afternoon. As it is, we're in no real rush to get 2.2 out the door, especially since so far the only feature that *might* be useful to us locally is the new mupdate implementation. > my little wish would be the sql cyrusdb interface, discussed here a week or > two ago, even if marked exeprimental or something. I don't think we're really interested in this at all, actually. Adding the SQL layer for key/value pairings just seems pretty lame to me. Those who want a direct interface to cyrus's internal datastructures are asking for trouble anyway, and I suggest they continue to use the IMAP interfaces. The only *possible* advantage I see is it gets cyrus's databases backed up with an SQL database, but since you still have to back up the cyrus datastore anyway, you haven't won anything. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
cyrus 2.2 status
Hi all, what is the current status of the cyrus 2.2 cvs branch? judging by the cvs commits lately, there are just various little cleanups here and there ... is there anything big left on the TODO list for 2.2? my little wish would be the sql cyrusdb interface, discussed here a week or two ago, even if marked exeprimental or something. -- Jure Pecar
