What would be the recommended JDK, is Hotspot still the way to go or do
JDK8 users already consider OpenJDK production-grade now ?
On 05/07/2015 07:00 PM, Jonathan Ellis wrote:
> Yes, it is.
>
Hi,
I agree with release (or even collaboration branches) having the same
approach for only merging code that has run in cassci off of that branch.
Ariel
On Thu, May 7, 2015 at 1:34 PM, Aleksey Yeschenko
wrote:
> > +100 from me, but why the exception for trunk?
>
> Sorry, just my poor wording
> +100 from me, but why the exception for trunk?
Sorry, just my poor wording again. No exception for trunk. What I meant by
‘non-trunk’ patches was patches that originated in 2.0 or 2.1 branches. ‘trunk’
patches (today) would be 3.0-only features and fixes, and these need no
upstream merging, b
> In the meantime can we agree on having cassci to validate personal merged
branches before pushing either, in case of non-trunk patches?
+100 from me, but why the exception for trunk? Wouldn't it be easier to
wait for the dev branch tests to pass and then do all the merging at once
(2.0, 2.1,3.0,
On Thu, May 7, 2015 at 10:42 AM, Jens Rantil wrote:
>
> Are there any plans (or JIRA issue) for adding client-side filtering to
> cqlsh? It would hugely improve our experiences with it when debugging etc.
> I wouldn't be against adding some kind of auto LIMIT or warning when using
> it as I under
> Agreed. I would like to wait and see how we do without extra branches for
> a release or two. That will give us a better idea of how much pain the
> extra steps will protect us from.
In the meantime can we agree on having cassci to validate personal merged
branches before pushing either, in c
Yes, it is.
On Thu, May 7, 2015 at 9:43 AM, Nick Bailey wrote:
> Is running 2.1 with java 8 a supported or recommended way to run at this
> point? If not then we'll be requiring users to upgrade both java and C* at
> the same time when making the jump to 3.0.
>
> On Thu, May 7, 2015 at 11:25 AM,
There’s no reason why people can’t run java 8 with 2.1. IIRC the only issue
we’d had with it was Dave’s
https://issues.apache.org/jira/browse/CASSANDRA-7028. That’s probably the best
thing for people to do though - run java 8 with 2.1 so the jump to 3.0 isn’t as
significant. Good point.
> O
Is running 2.1 with java 8 a supported or recommended way to run at this
point? If not then we'll be requiring users to upgrade both java and C* at
the same time when making the jump to 3.0.
On Thu, May 7, 2015 at 11:25 AM, Aleksey Yeschenko
wrote:
> The switch will necessarily hurt 3.0 adoption
The switch will necessarily hurt 3.0 adoption, but I think we’ll live. To me,
the benefits (mostly access to lambdas and default methods, tbh) slightly
outweigh the downsides.
+0.1
--
AY
On May 7, 2015 at 19:22:53, Gary Dusbabek (gdusba...@gmail.com) wrote:
+1
On Thu, May 7, 2015 at 11:09
I have no position on this, but I would like to issue a word of caution to
everyone excited to use the new JDK8 features in development to please
discuss their use widely beforehand, and to consider them carefully. Many
of them are not generally useful to us (e.g. LongAdder), and may have
unexpecte
+1
On Thu, May 7, 2015 at 11:09 AM, Jonathan Ellis wrote:
> We discussed requiring Java 8 previously and decided to remain Java
> 7-compatible, but at the time we were planning to release 3.0 before Java 7
> EOL. Now that 8099 and increased emphasis on QA have delayed us past Java
> 7 EOL, I th
+1
On Thu, May 7, 2015 at 11:13 AM, Jeremiah D Jordan
wrote:
> With Java 7 being EOL for free versions I am +1 on this. If you want to
> stick with 7, you can always keep running 2.1.
>
>> On May 7, 2015, at 11:09 AM, Jonathan Ellis wrote:
>>
>> We discussed requiring Java 8 previously and dec
With Java 7 being EOL for free versions I am +1 on this. If you want to stick
with 7, you can always keep running 2.1.
> On May 7, 2015, at 11:09 AM, Jonathan Ellis wrote:
>
> We discussed requiring Java 8 previously and decided to remain Java
> 7-compatible, but at the time we were planning t
+1, from a testing perspective we run dtest and unit tests on hotspot 8 and
openjdk 8 and have seen no problems.
On Thu, May 7, 2015 at 12:09 PM, Jonathan Ellis wrote:
> We discussed requiring Java 8 previously and decided to remain Java
> 7-compatible, but at the time we were planning to releas
We discussed requiring Java 8 previously and decided to remain Java
7-compatible, but at the time we were planning to release 3.0 before Java 7
EOL. Now that 8099 and increased emphasis on QA have delayed us past Java
7 EOL, I think it's worth reopening this discussion.
If we require 8, then we c
>
> I would argue that we must *at least* do the following for now.
If we get this right, the extra staging branches can certainly wait to be
assessed until later.
IMO, any patch should have a branch in CI for each affected mainline
branch, and should have the commit completely wired up (CHANGES
Hi,
I meant in the hypothetical case that we did this. There is going to be an
interim period where we wouldn't have this. The automation comes at the
expense of something else.
Ariel
On Thu, May 7, 2015 at 11:40 AM, Josh McKenzie
wrote:
> >
> > So who and when is going to implement the automa
On Thu, May 7, 2015 at 7:13 AM, Aleksey Yeschenko
wrote:
>
> That said, perhaps it’s too much change at once. We still have missing
> pieces of infrastructure, and TE is busy with what’s already back-logged.
> So let’s revisit this proposal in a few months, closer to 3.1 or 3.2, maybe?
>
Agreed.
Hi,
Are there any plans (or JIRA issue) for adding client-side filtering to
cqlsh? It would hugely improve our experiences with it when debugging etc.
I wouldn't be against adding some kind of auto LIMIT or warning when using
it as I understand users could use it as an anti-pattern, too.
Cheers,
>
> So who and when is going to implement the automation?
I don't believe we have sufficient consensus that this is necessary to
start doling out action-items for implementation.
On Thu, May 7, 2015 at 10:16 AM, Ariel Weisberg wrote:
> Hi,
>
> If it were automated I would have no problem with
Hi,
If it were automated I would have no problem with it. That would be less
work for me because the problems detected would occur anyways and have to
be dealt with by me. I just don't want to deal with extra steps and latency
manually.
So who and when is going to implement the automation?
Ariel
I would argue that we must *at least* do the following for now.
If your patch is 2.1-based, you need to create a private git branch for that
and a merged trunk branch ( and -trunk). And you don’t push anything
until cassci validates all of those three branches, first.
An issue without a
It's odd, because I honestly think this release process will be easier,
since the stricter we make it the smoother it can become. It requires well
formed commits from everyone, and lets the committers asynchronously
confirm their work, and for it to never be in question *who* needs to fix
something
>
> Merging is *hard*. Especially 2.1 -> 3.0, with many breaking API changes
> (this is before 8099, which is going to make a *world* of hurt, and will
> stick around for a year). It is *very* easy to break things, with even the
> utmost care.
While I agree re:merging, I'm not convinced the propo
Ok let's focus then on the idea that trunk is releasable. Releasable
to me doesn't mean it can't contain a bad merge.
It means it doesn't contain some untested and unstable feature. We
can always "release from trunk" and we still have a release process.
The idea that trunk must contain. a first
Hi,
Sorry didn't mean to blame or come off snarky. I just it is important not
to #include our release process from somewhere else. We don't have to do
anything unless it is necessary to meet some requirement of what we are
trying to do.
So the phrase "Trunk is always releasable" definitely has so
>
> This breaks your model of applying every commit ref by ref.
How? The rebase only affects commits after the "real" branch, so it still
cleanly fast forwards?
Merging is *hard*. Especially 2.1 -> 3.0, with many breaking API changes
(this is before 8099, which is going to make a *world* of hurt
You then fetch and repair
your local version and try again.
This breaks your model of applying every commit ref by ref.
I'm all for trying to avoid extra work/stability but we already have
added a layer of testing every change before commit. I'm not going to
accept we need to also add a layer of
It's a bit unfair to characterize Aleksey as subscribing to a cargo cult.
*We* agreed to define the new release process as "keeping trunk always
releasable".
Your own words that catalyzed this: "If we release off trunk it is pretty
much necessary for trunk to be in a releasable state all the time"
>
> wouldn't you need to force push?
git push --force-with-lease
This works essentially like CAS; if the remote repositories are not the
same as the one you have modified, it will fail. You then fetch and repair
your local version and try again.
So what does this buy us?
This buys us a clean
"Our process is our own" <- always remember this.
> On May 7, 2015, at 9:25 AM, Ariel Weisberg
> wrote:
>
> Hi,
>
> Whoah. Our process is our own. We don't have to subscribe to any cargo cult
> book buying seminar giving process.
>
> And whatever we do we can iterate and change until it works
Hi,
Whoah. Our process is our own. We don't have to subscribe to any cargo cult
book buying seminar giving process.
And whatever we do we can iterate and change until it works for us and
solves the problems we want solved.
Ariel
On Thu, May 7, 2015 at 10:13 AM, Aleksey Yeschenko
wrote:
> Stri
I'm not sure how I feel about this, on the one hand cleaner trunk is good,
on the other, added complexity leaves more room for error. I'm +0 currently.
> We still have missing pieces of infrastructure, and TE is busy with
what’s already back-logged. So let’s revisit this proposal in a few months,
Strictly speaking, the train schedule does demand that trunk, and all other
branches, must be releasable at all times, whether you like it or not (for the
record - I *don’t* like it, but here we are).
This, and other annoying things, is what be subscribed to tick-tock vs.
supported branches exp
Hi,
I don't think this is necessary. If you merge with trunk, test, and someone
gets in a head of you just merge up and push to trunk anyways. Most of the
time the changes the other person made will be unrelated and they will
compose fine. If you actually conflict then yeah you test again but this
>
> I still think this is overly complicated. We still
> need to run CI before we release. So what does this buy us?
I second this line of questioning. This sounds like we have a solution
looking for a problem; we're not talking about people git cloning our repo
and running it in production.
On
git rebase -i trunk_staging
fix the problem
git rebase --continue
In this situation, if there was an untested follow on commit wouldn't
you need to force push?
On Thu, May 7, 2015 at 9:28 AM, Benedict Elliott Smith
wrote:
>>
>> If we do it, we'll end up in weird situations which will be annoyin
>
> If we do it, we'll end up in weird situations which will be annoying for
> everyone
Such as? I'm not disputing, but if we're to assess the relative
strengths/weaknesses, we need to have specifics to discuss.
If we do go with this suggestion, we will most likely want to enable a
shared git re
ah missed that. I still think this is overly complicated. We still
need to run CI before we release. So what does this buy us?
On Thu, May 7, 2015 at 9:24 AM, Aleksey Yeschenko wrote:
>> The is still the problem of a commit coming into the staging dir after
>> a previous commit that is being test
> The is still the problem of a commit coming into the staging dir after
> a previous commit that is being tested.
> When the first commit is merged to the stable branch it will include
> both tested and untested version.
How so? We’ll only be merging up to the latest tested ref into the stabl
The is still the problem of a commit coming into the staging dir after
a previous commit that is being tested.
When the first commit is merged to the stable branch it will include
both tested and untested version.
Let's not take releasable branches to literally, we still need to tag
and test every
> Agreed as far as having staging branches vetoed by CI goes. Less sure about
> the edit-commit-in-place part as said above.
Right. That’s just an implementation detail (in place vs. extra fix up
commits). The latter is less annoying for the team in general, let’s do that
instead.
> If we do t
> If one of them breaks, we go and edit the _staging branch in place to
correct
> the problem, and let CI run again.
I would strongly advise against *in place* edits. If we do it, we'll end up
in
weird situations which will be annoying for everyone. Editing commits that
have
been shared is almost
+1. I would ask that if we end up doing this that it be documented on the
wiki.
Gary.
On Thu, May 7, 2015 at 4:05 AM, Benedict Elliott Smith <
belliottsm...@datastax.com> wrote:
> A good practice as a committer applying a patch is to build and run the
> unit tests before updating the main reposi
If the goal is to have branches that are always passing all the tests (aka
‘stable’ branches), then I don’t see any workarounds,
so +1 to this.
I’d go for branch names that are less likely to be confused w/ final
cassandra-X via autocomplete though: staging-2.0, staging-2.1, staging-trunk.
--
A good practice as a committer applying a patch is to build and run the
unit tests before updating the main repository, but to do this for every
branch is infeasible and impacts local productivity. Alternatively,
uploading the result to your development tree and waiting a few hours for
CI to valida
47 matches
Mail list logo
