Thanks everyone for the feedback. Looks like we will go with separate repo as
that is what majority of people prefer.
Also note that we can always change this approach later as we build the side
car.
> On Aug 24, 2018, at 07:00, Eric Evans wrote:
>
>> On Thu, Aug 23, 2018 at 3:01 PM sankalp
On Thu, Aug 23, 2018 at 3:01 PM sankalp kohli wrote:
>
> Separate repo is in a majority so far. Please reply to this thread with
> your responses.
I think it makes sense for the code, project, and workflows to be
(de|loosely)-coupled, so the repo should be as well.
+1 for a separate repository
+1 separate repo. I think in-tree only works if you're *not* supporting
multiple versions and each sidecar release is directly tied to a
corresponding C* release. Considering this case is also completely
achievable in a separate repo anyway with minimal overhead we may as well
start that way and se
+1 for a separate repo
On Fri, 24 Aug 2018 at 06:40, Michael Shuler wrote:
> +1 for a separate repository.
>
> Michael
>
> On 08/23/2018 07:30 PM, Murukesh Mohanan wrote:
> > FWIW, I think it's possible to merge in a separate repository into a
> > subdirectory while keeping git history, but I do
+1 for a separate repository.
Michael
On 08/23/2018 07:30 PM, Murukesh Mohanan wrote:
> FWIW, I think it's possible to merge in a separate repository into a
> subdirectory while keeping git history, but I don't know if the other way
> will be possible if commits span other parts of the repo as we
FWIW, I think it's possible to merge in a separate repository into a
subdirectory while keeping git history, but I don't know if the other way
will be possible if commits span other parts of the repo as well\* (which
will likely happen sooner or later). So a separate repo is a choice we can
backtra
+1 also for separate repo
> On 24 Aug 2018, at 01:11, Jeff Jirsa wrote:
>
> +1 for separate repo
>
>
> --
> Jeff Jirsa
>
>
>> On Aug 23, 2018, at 1:00 PM, sankalp kohli wrote:
>>
>> Separate repo is in a majority so far. Please reply to this thread with
>> your responses.
>>
>> On Tue, A
+1 for separate repo
--
Jeff Jirsa
> On Aug 23, 2018, at 1:00 PM, sankalp kohli wrote:
>
> Separate repo is in a majority so far. Please reply to this thread with
> your responses.
>
> On Tue, Aug 21, 2018 at 4:34 PM Rahul Singh
> wrote:
>
>> +1 for separate repo. Especially on git. Maybe
Separate repo is in a majority so far. Please reply to this thread with
your responses.
On Tue, Aug 21, 2018 at 4:34 PM Rahul Singh
wrote:
> +1 for separate repo. Especially on git. Maybe make it a submodule.
>
> Rahul
> On Aug 21, 2018, 3:33 PM -0500, Stefan Podkowinski ,
> wrote:
> > I'm also
+1 for separate repo. Especially on git. Maybe make it a submodule.
Rahul
On Aug 21, 2018, 3:33 PM -0500, Stefan Podkowinski , wrote:
> I'm also currently -1 on the in-tree option.
>
> Additionally to what Aleksey mentioned, I also don't see how we could
> make this work with the current build and
I'm also currently -1 on the in-tree option.
Additionally to what Aleksey mentioned, I also don't see how we could
make this work with the current build and release process. Our scripts
[0] for creating releases (tarballs and native packages), would need
significant work to add support for an inde
+1 for separate repo. For pretty much all the same reasons Aleksey
elucidated.
On Tue, Aug 21, 2018 at 10:20 AM, Aleksey Yeshchenko
wrote:
> Sure, allow me to elaborate - at least a little bit. But before I do, just
> let me note that this wasn’t a veto -1, just a shorthand for “I don’t like
> t
Sure, allow me to elaborate - at least a little bit. But before I do, just let
me note that this wasn’t a veto -1, just a shorthand for “I don’t like this
option”.
It would be nice to have sidecar and C* version and release cycles fully
decoupled. I know it *can* be done when in-tree, but the w
Hi Aleksey,
Can you please elaborate on the reasons for your -1? This
way we can make progress towards any one approach.
Thanks,
Sankalp
On Tue, Aug 21, 2018 at 8:39 AM Aleksey Yeshchenko
wrote:
> FWIW I’m strongly -1 on in-tree approach, and would much prefer a separate
> repo,
FWIW I’m strongly -1 on in-tree approach, and would much prefer a separate
repo, dtest-style.
—
AY
On 21 August 2018 at 16:36:02, Jeremiah D Jordan (jeremiah.jor...@gmail.com)
wrote:
I think the following is a very big plus of it being in tree:
>> * Faster iteration speed in general. For exa
I think the following is a very big plus of it being in tree:
>> * Faster iteration speed in general. For example when we need to add a
>> new
>> JMX endpoint that the sidecar needs, or change something from JMX to a
>> virtual table (e.g. for repair, or monitoring) we can do all changes
>> includi
Strongly agree with Blake. In my mind supporting multiple versions is
mandatory. As I've stated before, we already do it with Reaper, I'd
consider it a major misstep if we couldn't support multiple with the
project - provided admin tool. It's the same reason dtests are separate -
they work with
An option is to create a mono repo with Cassandra and SideCar as modules that
could be built independently. This would keep source for both artifacts in the
same repo and have their own release cadences. That said, I don't have any
strong opinions at this point. We can try going with a separate
If the sidecar is going to be on a different release cadence, or support
interacting with mixed mode clusters, then it should definitely be in a
separate repo. I don’t even know how branching and merging would work in a repo
that supports 2 separate release targets and/or mixed mode compatibilit
I think that the pros of incubating the sidecar in tree as a tool first
outweigh the alternatives at this point of time. Rough tradeoffs that I see:
Unique pros of in tree sidecar:
* Faster iteration speed in general. For example when we need to add a new
JMX endpoint that the sidecar needs, or ch
20 matches
Mail list logo
