Congrats!
On Mon, May 3, 2021 at 1:23 PM Paulo Motta wrote:
> Congrats, Stefan! Happy to see you onboard! :)
>
> Em seg., 3 de mai. de 2021 às 17:17, Ben Bromhead
> escreveu:
>
> > Congrats mate!
> >
> > On Tue, May 4, 2021 at 4:20 AM Scott Andreas
> wrote:
> >
> > > Congratulations, Štefan!
Congrats, Stefan! Happy to see you onboard! :)
Em seg., 3 de mai. de 2021 às 17:17, Ben Bromhead
escreveu:
> Congrats mate!
>
> On Tue, May 4, 2021 at 4:20 AM Scott Andreas wrote:
>
> > Congratulations, Štefan!
> >
> >
> > From: David Capwell
> > Sent:
Congrats mate!
On Tue, May 4, 2021 at 4:20 AM Scott Andreas wrote:
> Congratulations, Štefan!
>
>
> From: David Capwell
> Sent: Monday, May 3, 2021 10:53 AM
> To: dev@cassandra.apache.org
> Subject: Re: Welcome Stefan Miklosovic as Cassandra committer
>
Congratulations, Štefan!
From: David Capwell
Sent: Monday, May 3, 2021 10:53 AM
To: dev@cassandra.apache.org
Subject: Re: Welcome Stefan Miklosovic as Cassandra committer
Congrats!
> On May 3, 2021, at 9:47 AM, Ekaterina Dimitrova wrote:
>
> Congrat
Hi,
We're working with the CDC feature to develop an agent to stream changes in
Cassandra DB into Kafka. However, the CDC feature doesn't work well for us
so far because CommitLog files are rarely flushed into cdc_raw directory,
and the frequency can be as low as a few months.
Is there any
Congrats!
> On May 3, 2021, at 9:47 AM, Ekaterina Dimitrova wrote:
>
> Congrat Stefan! Well done!!
>
> On Mon, 3 May 2021 at 11:49, J. D. Jordan wrote:
>
>> Well deserved! Congrats Stefan.
>>
>>> On May 3, 2021, at 10:46 AM, Sumanth Pasupuleti <
>> sumanth.pasupuleti...@gmail.com> wrote:
Congrat Stefan! Well done!!
On Mon, 3 May 2021 at 11:49, J. D. Jordan wrote:
> Well deserved! Congrats Stefan.
>
> > On May 3, 2021, at 10:46 AM, Sumanth Pasupuleti <
> sumanth.pasupuleti...@gmail.com> wrote:
> >
> > Congratulations Stefan!!
> >
> >> On Mon, May 3, 2021 at 8:41 AM Brandon
Well deserved! Congrats Stefan.
> On May 3, 2021, at 10:46 AM, Sumanth Pasupuleti
> wrote:
>
> Congratulations Stefan!!
>
>> On Mon, May 3, 2021 at 8:41 AM Brandon Williams wrote:
>>
>> Congratulations, Stefan!
>>
>>> On Mon, May 3, 2021 at 10:38 AM Benjamin Lerer wrote:
>>>
>>> The
Congratulations Stefan!!
On Mon, May 3, 2021 at 8:41 AM Brandon Williams wrote:
> Congratulations, Stefan!
>
> On Mon, May 3, 2021 at 10:38 AM Benjamin Lerer wrote:
> >
> > The PMC's members are pleased to announce that Stefan Miklosovic has
> > accepted the invitation to become committer
Congratulations, Stefan!
On Mon, May 3, 2021 at 10:38 AM Benjamin Lerer wrote:
>
> The PMC's members are pleased to announce that Stefan Miklosovic has
> accepted the invitation to become committer last Wednesday.
>
> Thanks a lot, Stefan, for all your contributions!
>
> Congratulations and
The PMC's members are pleased to announce that Stefan Miklosovic has
accepted the invitation to become committer last Wednesday.
Thanks a lot, Stefan, for all your contributions!
Congratulations and welcome
The Apache Cassandra PMC members
For a minor/major? I can imagine doing this for a patch version, but this is of
much less importance to downstream users.
Do you have any examples of projects that do this for major/minor development
branches, as you propose?
I'm just a bit confused about the proposition to decouple from
> > Vendors are also free to support and provide hot-fixes and back ports on
> > these unreleased versions, outside of the community's efforts or concerns
>
> This seems to me like we're endorsing the release of these versions by
> downstream maintainers? Even if we decide to modify this
> Vendors are also free to support and provide hot-fixes and back ports on
> these unreleased versions, outside of the community's efforts or concerns
This seems to me like we're endorsing the release of these versions by
downstream maintainers? Even if we decide to modify this proposal and say
> Well the other problem I see is that this could create a lot of confusion for
> our users, if more versions start popping up (and/or versions are skipped).
> It's hard to row back from unwanted versions in the wild, and we may end up
> having to either support them or disappoint our users.
Well the other problem I see is that this could create a lot of confusion for
our users, if more versions start popping up (and/or versions are skipped).
It's hard to row back from unwanted versions in the wild, and we may end up
having to either support them or disappoint our users.
Do we
> Hmm, ok. I see some possible issues with this. You mention one possibility,
> i.e. that downstream may end up releasing these versions for us? Which
> potentially complicates our lives, whether we want it or not.
>
> Would this apply to only trunk, or to all existing major/minor releases?
Hmm, ok. I see some possible issues with this. You mention one possibility,
i.e. that downstream may end up releasing these versions for us? Which
potentially complicates our lives, whether we want it or not.
Would this apply to only trunk, or to all existing major/minor releases?
I wonder if
> Sorry, I may be being dense, but it's not that I didn't parse your
> justification for it, but that I literally don't understand what the proposal
> is.
Ah, nothing more than every quarter we bump the minor version in build.xml
(the frequency is up for discussion)
Sorry, I may be being dense, but it's not that I didn't parse your
justification for it, but that I literally don't understand what the proposal
is.
On 03/05/2021, 08:30, "Mick Semb Wever" wrote:
> I didn't really understand the unreleased versions proposal though.
Benedict, two
> I didn't really understand the unreleased versions proposal though.
Benedict, two brief example perspectives on it. This is all under the
"let's try, learn, evaluate" umbrella.
1)
Unreleased versions can give downstream more choices through the
annual development cycle than the binary choice
21 matches
Mail list logo
