Re: Side Car New Repo vs not

[Michael Shuler]

+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 well\* (which
> will likely happen sooner or later). So a separate repo is a choice we can
> backtrack from if it proves problematic later.
> 
> 
> \* it may be possible, but the commit messages might not make much sense
> after that.
> 
> On Fri, 24 Aug 2018, 09:12 Benedict Elliott Smith, 
> wrote:
> 
>> +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, Aug 21, 2018 at 4:34 PM Rahul Singh <
>> rahul.xavier.si...@gmail.com>
 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 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 independent side-car. Our ant
>> based build process is also not a great start for adding new tasks,
>> let
>> alone integrating other tool chains for web components for a potential
> UI.
>>
>> [0] https://git-wip-us.apache.org/repos/asf?p=cassandra-builds.git
>>
>>
>>> On 21.08.18 19:20, 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 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 way we
>> vote
> on releases with tags off current branches would have to change
>> somehow.
> Probably painfully. It would be nice to be able to easily enforce
>> freezes,
> like the upcoming one, on the whole C* repo, while allowing feature
> development on the sidecar. It would be nice to not have sidecar
>> commits in
> emails from commits@ mailing list. It would be nice to not have C* CI
> trigger necessarily on sidecar commits. Groups of people working on
>> the two
> repos will mostly be different too, so what’s the point in sharing the
>> repo?
>>>
>>> Having an extra repo with its own set of branches is cheap and easy -
> we already do that with dtests. I like cleanly separated things when
> coupling is avoidable. As such I would prefer the sidecar to live in a
> separate new repo, while still being part of the C* project.
>>>
>>> —
>>> AY
>>>
>>> On 21 August 2018 at 17:06:39, sankalp kohli (kohlisank...@gmail.com
>> )
> wrote:
>>>
>>> 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 <
>> alek...@apple.com>
>>> wrote:
>>>
 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 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
>> including tests as one commit within the main repository and
> don't
 have
>> to
>> commit to main repo, sidecar repo,

 I also don’t see a reason why the sidecar being in tree means it
> would not
 work in a mixed version cluster. The nodes themselves must work in a
> mixed
 version cluster during a rolling upgrade, I would expect any
> management
 side car to operate in the same manor, in tree or not.

 This tool will be pretty tightly coupled with the server, and as
> someone
 with experience developing such tightly coupled tools, it is *much*
> easier
 to make sure you don’t accidentally break them if they are in tree.
> How
 many times has someone updated some JMX interface, updated nodetool,

Re: Supporting multiple JDKs

[Mick Semb Wever]

> However, in addition to using such a
> tool, I believe, when we make a release, we should build against the actual
> JDKs we support (that way, we are not making a release just based on the
> result of an external tool), and we should be able to optionally run UTs
> and DTests against the JDK  (i.e. Java7 and Java8 for C* 2.2).


I'm still a bit confused as to what's the benefit in compiling with jdk1.7 and 
then testing with jdk1.7 or jdk1.8

If you find breakages here that otherwise don't exist when it's compiled with 
jdk1.8 then that's just false-positives. As well as generally wasting CI 
resources.

Either way, there's not much point discussing this as Cassandra-2.1 is about 
EOL, and Cassandra-4.0 is stuck with a very specific compile.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Side Car New Repo vs not

[Murukesh Mohanan]

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
backtrack from if it proves problematic later.


\* it may be possible, but the commit messages might not make much sense
after that.

On Fri, 24 Aug 2018, 09:12 Benedict Elliott Smith, 
wrote:

> +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, Aug 21, 2018 at 4:34 PM Rahul Singh <
> rahul.xavier.si...@gmail.com>
> >> 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 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 independent side-car. Our ant
>  based build process is also not a great start for adding new tasks,
> let
>  alone integrating other tool chains for web components for a potential
> >>> UI.
> 
>  [0] https://git-wip-us.apache.org/repos/asf?p=cassandra-builds.git
> 
> 
> > On 21.08.18 19:20, 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 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 way we
> vote
> >>> on releases with tags off current branches would have to change
> somehow.
> >>> Probably painfully. It would be nice to be able to easily enforce
> freezes,
> >>> like the upcoming one, on the whole C* repo, while allowing feature
> >>> development on the sidecar. It would be nice to not have sidecar
> commits in
> >>> emails from commits@ mailing list. It would be nice to not have C* CI
> >>> trigger necessarily on sidecar commits. Groups of people working on
> the two
> >>> repos will mostly be different too, so what’s the point in sharing the
> repo?
> >
> > Having an extra repo with its own set of branches is cheap and easy -
> >>> we already do that with dtests. I like cleanly separated things when
> >>> coupling is avoidable. As such I would prefer the sidecar to live in a
> >>> separate new repo, while still being part of the C* project.
> >
> > —
> > AY
> >
> > On 21 August 2018 at 17:06:39, sankalp kohli (kohlisank...@gmail.com
> )
> >>> wrote:
> >
> > 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 <
> alek...@apple.com>
> > wrote:
> >
> >> 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 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
>  including tests as one commit within the main repository and
> >>> don't
> >> have
>  to
>  commit to main repo, sidecar repo,
> >>
> >> I also don’t see a reason why the sidecar being in tree means it
> >>> would not
> >> work in a mixed version cluster. The nodes themselves must work in a
> >>> mixed
> >> version cluster during a rolling upgrade, I would expect any
> >>> management
> >> side car to operate in the same manor, in tree or not.
> >>
> >> This tool will be pretty tightly coupled with the server, and as
> >>> someone
> >> with experience developing such tightly coupled tools, it is *much*
> >>> easier
> >> to make sure you don’t accidentally break them if they are in tree.
> >>> How
> >> many times has someone updated some JMX interface, updated nodetool,
> >>> and
> >> then moved on? Breaking all the external tools not in tree, without
> >> realizing it. The above point 

Re: Side Car New Repo vs not

[Benedict Elliott Smith]

+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, 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 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 independent side-car. Our ant
 based build process is also not a great start for adding new tasks, let
 alone integrating other tool chains for web components for a potential
>>> UI.
 
 [0] https://git-wip-us.apache.org/repos/asf?p=cassandra-builds.git
 
 
> On 21.08.18 19:20, 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 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 way we vote
>>> on releases with tags off current branches would have to change somehow.
>>> Probably painfully. It would be nice to be able to easily enforce freezes,
>>> like the upcoming one, on the whole C* repo, while allowing feature
>>> development on the sidecar. It would be nice to not have sidecar commits in
>>> emails from commits@ mailing list. It would be nice to not have C* CI
>>> trigger necessarily on sidecar commits. Groups of people working on the two
>>> repos will mostly be different too, so what’s the point in sharing the repo?
> 
> Having an extra repo with its own set of branches is cheap and easy -
>>> we already do that with dtests. I like cleanly separated things when
>>> coupling is avoidable. As such I would prefer the sidecar to live in a
>>> separate new repo, while still being part of the C* project.
> 
> —
> AY
> 
> On 21 August 2018 at 17:06:39, sankalp kohli (kohlisank...@gmail.com)
>>> wrote:
> 
> 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, 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 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
 including tests as one commit within the main repository and
>>> don't
>> have
 to
 commit to main repo, sidecar repo,
>> 
>> I also don’t see a reason why the sidecar being in tree means it
>>> would not
>> work in a mixed version cluster. The nodes themselves must work in a
>>> mixed
>> version cluster during a rolling upgrade, I would expect any
>>> management
>> side car to operate in the same manor, in tree or not.
>> 
>> This tool will be pretty tightly coupled with the server, and as
>>> someone
>> with experience developing such tightly coupled tools, it is *much*
>>> easier
>> to make sure you don’t accidentally break them if they are in tree.
>>> How
>> many times has someone updated some JMX interface, updated nodetool,
>>> and
>> then moved on? Breaking all the external tools not in tree, without
>> realizing it. The above point about being able to modify interfaces
>>> and the
>> side car in the same commit is huge in terms of making sure someone
>>> doesn’t
>> inadvertently break the side car while fixing something else.
>> 
>> -Jeremiah
>> 
>> 
>>> On Aug 21, 2018, at 10:28 AM, Jonathan Haddad 
>> wrote:
>>> 
>>> 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 multiple versions.
>>> 
>>> The number of repos does not affect distribution - 

Re: Side Car New Repo vs not

[Jeff Jirsa]

+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 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 release process. Our scripts
>>> [0] for creating releases (tarballs and native packages), would need
>>> significant work to add support for an independent side-car. Our ant
>>> based build process is also not a great start for adding new tasks, let
>>> alone integrating other tool chains for web components for a potential
>> UI.
>>> 
>>> [0] https://git-wip-us.apache.org/repos/asf?p=cassandra-builds.git
>>> 
>>> 
 On 21.08.18 19:20, 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 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 way we vote
>> on releases with tags off current branches would have to change somehow.
>> Probably painfully. It would be nice to be able to easily enforce freezes,
>> like the upcoming one, on the whole C* repo, while allowing feature
>> development on the sidecar. It would be nice to not have sidecar commits in
>> emails from commits@ mailing list. It would be nice to not have C* CI
>> trigger necessarily on sidecar commits. Groups of people working on the two
>> repos will mostly be different too, so what’s the point in sharing the repo?
 
 Having an extra repo with its own set of branches is cheap and easy -
>> we already do that with dtests. I like cleanly separated things when
>> coupling is avoidable. As such I would prefer the sidecar to live in a
>> separate new repo, while still being part of the C* project.
 
 —
 AY
 
 On 21 August 2018 at 17:06:39, sankalp kohli (kohlisank...@gmail.com)
>> wrote:
 
 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, 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 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
>>> including tests as one commit within the main repository and
>> don't
> have
>>> to
>>> commit to main repo, sidecar repo,
> 
> I also don’t see a reason why the sidecar being in tree means it
>> would not
> work in a mixed version cluster. The nodes themselves must work in a
>> mixed
> version cluster during a rolling upgrade, I would expect any
>> management
> side car to operate in the same manor, in tree or not.
> 
> This tool will be pretty tightly coupled with the server, and as
>> someone
> with experience developing such tightly coupled tools, it is *much*
>> easier
> to make sure you don’t accidentally break them if they are in tree.
>> How
> many times has someone updated some JMX interface, updated nodetool,
>> and
> then moved on? Breaking all the external tools not in tree, without
> realizing it. The above point about being able to modify interfaces
>> and the
> side car in the same commit is huge in terms of making sure someone
>> doesn’t
> inadvertently break the side car while fixing something else.
> 
> -Jeremiah
> 
> 
>> On Aug 21, 2018, at 10:28 AM, Jonathan Haddad 
> wrote:
>> 
>> 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 multiple versions.
>> 
>> The number of repos does not affect distribution - if we want to
>> ship
>> Cassandra with the admin / repair tool (we should, imo), that can
>> be
> part
>> of the build process.
>> 
>> 
>> 
>> 
>> On Mon, Aug 20, 2018 at 9:21 PM Blake 

Re: Supporting multiple JDKs

[Jason Brown]

Some of our java8 code will not compile under java11 (see CASSANDRA-9608);
the symbols have literally been removed (Unsafe.monitorEnter() /
Unsafe.monitorExit() ). Setting -source to "8" will not help. Thus, we need
two compilers for the foreseeable future.



On Thu, Aug 23, 2018 at 3:44 PM, Sumanth Pasupuleti <
sumanth.pasupuleti...@gmail.com> wrote:

> I am not against using a compile-time quick-feedback tool like Animal
> Sniffer either. It is great to have such a tool to know of any obvious bad
> changes right away during development. However, in addition to using such a
> tool, I believe, when we make a release, we should build against the actual
> JDKs we support (that way, we are not making a release just based on the
> result of an external tool), and we should be able to optionally run UTs
> and DTests against the JDK  (i.e. Java7 and Java8 for C* 2.2).
>
> > What do we mean "support multiple JDKs" ?
> > Are we talking Run-time or Compile-time?
> I am talking both - compile-time can for Build, run-time for UTs and
> DTests.
>
> > I think that dtests are always going to be the important defence here,
> and that we simplify it by running dtests on a standardised JDK compile.
> I agree, but its good to have an optional workflow in CircleCI to be able
> to run DTest against the non-standardized JDK as well, which we support
> (Java7 for example, for C*2.2, and Java11 for C* 4.0)
>
> Thanks,
> Sumanth
>
> On Thu, Aug 23, 2018 at 12:06 AM Mick Semb Wever  wrote:
>
> >
> > > > There's a cost-optimisation here in reducing what we have to support.
> > >
> > > I agree and animal sniffer is a great way to ferret out obvious issues.
> > > I am not against using animal sniffer. I'm concerned that there are
> > > various incompatibilities[1] between JDK versions and I am not 100%
> > > certain that animal sniffer will catch all of them.
> >
> >
> > Yeah, but is compiling (and unit tests) really any more effective against
> > behavioural incompatibilities (which also occur from one patch JDK
> version
> > to the next)?
> >
> > I think that dtests are always going to be the important defence here,
> and
> > that we simplify it by running dtests on a standardised JDK compile.
> >
> > regards,
> > Mick
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: Supporting multiple JDKs

[Sumanth Pasupuleti]

I am not against using a compile-time quick-feedback tool like Animal
Sniffer either. It is great to have such a tool to know of any obvious bad
changes right away during development. However, in addition to using such a
tool, I believe, when we make a release, we should build against the actual
JDKs we support (that way, we are not making a release just based on the
result of an external tool), and we should be able to optionally run UTs
and DTests against the JDK  (i.e. Java7 and Java8 for C* 2.2).

> What do we mean "support multiple JDKs" ?
> Are we talking Run-time or Compile-time?
I am talking both - compile-time can for Build, run-time for UTs and DTests.

> I think that dtests are always going to be the important defence here,
and that we simplify it by running dtests on a standardised JDK compile.
I agree, but its good to have an optional workflow in CircleCI to be able
to run DTest against the non-standardized JDK as well, which we support
(Java7 for example, for C*2.2, and Java11 for C* 4.0)

Thanks,
Sumanth

On Thu, Aug 23, 2018 at 12:06 AM Mick Semb Wever  wrote:

>
> > > There's a cost-optimisation here in reducing what we have to support.
> >
> > I agree and animal sniffer is a great way to ferret out obvious issues.
> > I am not against using animal sniffer. I'm concerned that there are
> > various incompatibilities[1] between JDK versions and I am not 100%
> > certain that animal sniffer will catch all of them.
>
>
> Yeah, but is compiling (and unit tests) really any more effective against
> behavioural incompatibilities (which also occur from one patch JDK version
> to the next)?
>
> I think that dtests are always going to be the important defence here, and
> that we simplify it by running dtests on a standardised JDK compile.
>
> regards,
> Mick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Side Car New Repo vs not

[sankalp kohli]

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 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 independent side-car. Our ant
> > based build process is also not a great start for adding new tasks, let
> > alone integrating other tool chains for web components for a potential
> UI.
> >
> > [0] https://git-wip-us.apache.org/repos/asf?p=cassandra-builds.git
> >
> >
> > On 21.08.18 19:20, 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 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 way we vote
> on releases with tags off current branches would have to change somehow.
> Probably painfully. It would be nice to be able to easily enforce freezes,
> like the upcoming one, on the whole C* repo, while allowing feature
> development on the sidecar. It would be nice to not have sidecar commits in
> emails from commits@ mailing list. It would be nice to not have C* CI
> trigger necessarily on sidecar commits. Groups of people working on the two
> repos will mostly be different too, so what’s the point in sharing the repo?
> > >
> > > Having an extra repo with its own set of branches is cheap and easy -
> we already do that with dtests. I like cleanly separated things when
> coupling is avoidable. As such I would prefer the sidecar to live in a
> separate new repo, while still being part of the C* project.
> > >
> > > —
> > > AY
> > >
> > > On 21 August 2018 at 17:06:39, sankalp kohli (kohlisank...@gmail.com)
> wrote:
> > >
> > > 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, 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 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
> > > > > > including tests as one commit within the main repository and
> don't
> > > > have
> > > > > > to
> > > > > > commit to main repo, sidecar repo,
> > > >
> > > > I also don’t see a reason why the sidecar being in tree means it
> would not
> > > > work in a mixed version cluster. The nodes themselves must work in a
> mixed
> > > > version cluster during a rolling upgrade, I would expect any
> management
> > > > side car to operate in the same manor, in tree or not.
> > > >
> > > > This tool will be pretty tightly coupled with the server, and as
> someone
> > > > with experience developing such tightly coupled tools, it is *much*
> easier
> > > > to make sure you don’t accidentally break them if they are in tree.
> How
> > > > many times has someone updated some JMX interface, updated nodetool,
> and
> > > > then moved on? Breaking all the external tools not in tree, without
> > > > realizing it. The above point about being able to modify interfaces
> and the
> > > > side car in the same commit is huge in terms of making sure someone
> doesn’t
> > > > inadvertently break the side car while fixing something else.
> > > >
> > > > -Jeremiah
> > > >
> > > >
> > > > > On Aug 21, 2018, at 10:28 AM, Jonathan Haddad 
> > > > wrote:
> > > > >
> > > > > 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 multiple versions.
> > > > >
> > > > > The number of repos does not affect distribution - if we want to
> ship
> > > > > Cassandra with the admin / repair tool (we should, imo), that can
> be
> > > > part
> > > > > of the build process.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Aug 20, 2018 at 9:21 PM Blake Eggleston <
> 

Re: Supporting multiple JDKs

[Mick Semb Wever]

> > There's a cost-optimisation here in reducing what we have to support.
> 
> I agree and animal sniffer is a great way to ferret out obvious issues. 
> I am not against using animal sniffer. I'm concerned that there are 
> various incompatibilities[1] between JDK versions and I am not 100% 
> certain that animal sniffer will catch all of them.


Yeah, but is compiling (and unit tests) really any more effective against 
behavioural incompatibilities (which also occur from one patch JDK version to 
the next)?

I think that dtests are always going to be the important defence here, and that 
we simplify it by running dtests on a standardised JDK compile.

regards,
Mick

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Supporting multiple JDKs

[Dinesh Joshi]

> On Aug 22, 2018, at 7:23 PM, Mick Semb Wever  wrote:
> 
> There's a cost-optimisation here in reducing what we have to support.

I agree and animal sniffer is a great way to ferret out obvious issues. I am 
not against using animal sniffer. I'm concerned that there are various 
incompatibilities[1] between JDK versions and I am not 100% certain that animal 
sniffer will catch all of them.

Dinesh

[1] 
http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html