.
>
> Cheers,
>
> Bron.
>
> On Wed, Nov 13, 2019, at 16:12, Anatoli via Cyrus-devel wrote:
>> > How do you know when the current write operations are finished?
>>
>> The pseudocode from my previous email:
>>
>> __start:
>>
>
> How do you know when the current write operations are finished?
The pseudocode from my previous email:
__start:
atomic_inc(write_operations_in_execution_counter)
atomic_load(write_barrier)
if (write_barrier == ON) {
atomic_dec(write_operations_in_execution_counter)
sleep(100ms)
goto _
x27;s the case, what would have to be done to
guarantee it (i.e. to make it like Cyrus was shutdown normally)?
Regards,
Anatoli
On 7/11/19 19:56, Bron Gondwana wrote:
> On Thu, Nov 7, 2019, at 15:46, Anatoli via Cyrus-devel wrote:
>> Bron,
>>
>> Thanks for your detaile
lease let me know if you'd like my feedback once you decide with Ellie
on possible directions.
Thanks!
Anatoli
On 5/11/19 18:20, Bron Gondwana wrote:
> On Wed, Nov 6, 2019, at 03:44, Anatoli via Cyrus-devel wrote:
>> Hi All!
>>
>> Bron, for deployments I manage these issues are
Hi All!
Bron, for deployments I manage these issues are also important:
* #1763 (Backups for SMB (lock entire server for a moment while taking a
snapshot)). Don't know if there was any progress on this. Basically, a
short (milliseconds to a few seconds) global write lock is needed on all
data str
Ellie, Ken, thanks for the clarifications! Ellie, I hope you recover soon!
Best regards,
Anatoli
*From:* Ellie Timoney
*Sent:* Monday, July 29, 2019 20:28
*To:* Cyrus Devel
*Subject:* Re: Notes 29 July
On Mon, Jul 29, 2019, at 11:10 PM, Anatoli via Cyrus-devel wrote:
There are a lot of
Hi All,
Ken, what's the /Delayed Send/ feature you mentioned? Is it something
like Send Later extension in TB but on the server? How would the clients
use it?
Bron, do you still pursue the goal to close most of the GitHub issues?
Do you have any roadmap for which issues to be closed in the n
Hi All,
> NEXT WEEK:
> * read through issues for anything that should be a 3.2 release
blocker and we'll discuss the tasks at the next meeting.
Bron, please consider issues #1765/#2100 (a chroot implementation
blocker) and #1763 (efficient backup blocker).
Thanks,
Anatoli
*From:* Bron Gond
evel
*Subject:* Re: Cyrus Sieve futures
I'm pretty sure there's no IO handling inside the sieve bytecode
processing, though it makes callbacks to perform the actual actions -
so the impure bits are very clearly defined.
On Wed, 8 Feb 2017, at 13:05, Anatoli via Cyrus-devel wrote:
B
M, Anatoli via Cyrus-devel wrote:
Another question (just wondering if it's in your (or other devs) plans
and its feasibility): is it practically possible to implement for Sieve
something like "run the rules on X folder (+ subfolders)" same way as
local rules in most MUAs could be
el
*Subject:* Re: Cyrus Sieve futures
Actually, that's pretty much already done, the separation. Sieve, more
than any other part of the Cyrus code, is very decoupled. It used to be
a separate CVS repository once upon a time.
Bron.
On Tue, 7 Feb 2017, at 18:36, Anatoli via Cyrus-devel
Hi Ken,
I don't have any special uses for Sieve apart from the most basic ones,
but I would like to ask you if you see it feasible, as part of this
work, to separate the "numbers crunching" (e.g. rules matching,
transformations, etc.) code from the I/O code (that is responsible for
manipulati
oli
*From:* Bron Gondwana Via Cyrus-devel
*Sent:* Tuesday, December 27, 2016 21:04
*To:* Cyrus-devel
*Subject:* Re: Release plan blog post
Hi,
Sorry for the delay in responding to this - I left it over Christmas so
I could sit down without distraction and reply when I was back in the
office.
On Sat,
Hi Bron, all.
Thanks for the update and for the support of the project. That's great
we'll see the 3.0 release soon!
Replying to your last paragraph in the blog post about the community
needs, I believe that what's good for FM is mostly good for the
community too. The FM team is probably the
[...]
Please apply the fixes as you see fit.
Thanks, those look good to me. I'll push it up, but I'll split it into
separate commits for each piece (sieve/RSCALE/com_err) for historical clarity.
I'll also fix the "distribuion" typo while I'm in there, that
og says:
> configure:19090: checking for bison
> configure:19106: found /usr/bin/bison
> configure:19117: result: bison -y
> configure:19133: checking for flex
> configure:19149: found /usr/bin/flex
> configure:19160: result: flex
so configure is looking for, and finding, b
nt: Wednesday, May 11, 2016 15:44
To: Anatoli; cyrus-devel@lists.andrew.cmu.edu
Subject: Re: v3.0
On 05/09/2016 02:57 AM, Anatoli via Cyrus-devel wrote:
> Hi all,
>
> I'm testing v3.0.0 beta2. Here goes the feedback, this time for the build
> process.
>
> 1. --disable-sq
is list, so this is
probably the best place for it.
You're also welcome to join our conference calls, they happen at 11am
UTC most Mondays on Google Hangouts. Probably the easiest way to join
is to come into #cyrus on Freenode IRC at the meeting time and ask for
the hangouts link, because it c
, April 21, 2016 12:34
To: Anatoli
Cc: cyrus-devel@lists.andrew.cmu.edu
Subject: RE: v3.0
On Wed, 20 Apr 2016, Anatoli via Cyrus-devel wrote:
> The T199 actually mentions exactly this behavior. Why do you think that
this
> is not a bug? How is it supposed the specialuse flag should be set f
Hi Leena,
What's not working in 2.5.7 is the functionality to set from cyradm the
specialuse flag that would be visible via IMAP. Consider the following
example:
First we retrieve the information for a folder from cyradm:
getmd user/test/fol...@example.com
{user/test/fol...@example.com}:
priv
rus 3.0 is active on this list, so this is
probably the best place for it.
You're also welcome to join our conference calls, they happen at 11am
UTC most Mondays on Google Hangouts. Probably the easiest way to join
is to come into #cyrus on Freenode IRC at the meeting time and ask for
the hang
Hi folks,
Sorry for bothering you again with subj, I haven't received any answer to the
previous mails about it. I'm quite interested in this release and I'd like to
help with testing, simple problems investigation and fixing, and similar tasks,
but at least some insight to the current state of
Hi Bron,
It would be great! Also it'll help a lot to have a roadmap with ETAs for
each stage with a feature set defined. We're very interested in v3.0 and at
this time we have no idea about its present and future.
Regards,
Anatoli
-Original Message-
From: Cyrus-devel
[mailto:cyrus-devel-
uction use. Am I right?
I don't know much about it myself -- can someone else field this question
please?
Cheers,
ellie
On Fri, Apr 8, 2016, at 02:48 PM, Anatoli via Cyrus-devel wrote:
Hi all,
Firstly, thanks, developers, for your hard work in creating Cyrus! We've
d
Hi all,
Firstly, thanks, developers, for your hard work in creating Cyrus! We've
deployed it recently and it worked as expected from the first try (after
reading a lot of documentation first :).
We've experimented with different configure options and found that when
--disable-event-notifica
25 matches
Mail list logo