ests, or you pay money to be able to
run the tests... If the intent is to make it easier for new people to
contribute to the project, shouldn't the focus be on fixing their pain
points such as testing?
On Fri, Jun 26, 2020 at 3:38 PM Jordan West wrote:
> On Fri, Jun 26
ew contributions from the same quarters
>
Just a heads up - this comes across as passive aggressive sniping. I'm sure
you didn't mean it as such but it does read that way (at least to me).
When it comes to quality, much like you said in another thread Benedict I
thin
On Sun, Jun 28, 2020 at 12:07 AM Benedict Elliott Smith
wrote:
> > Just a heads up - this comes across as passive aggressive sniping. I'm
> sure you didn't mean it as such
>
> I think indirect criticism is a normal part of discourse, particula
need both new features/improvements and stability.
It is natural that some people push a bit more towards new
features\improvements and others towards stability.
I would be worried if everybody wanted to go in the same direction.
On Mon, Jun 29, 2020 at 12:22 PM Benedict Elliott Smi
o be addressed.
On 29/06/2020, 15:33, "Benjamin Lerer" wrote:
Sorry, Benedict. My answer was probably not phrased in the correct way.
I just believe that we should not look at the organizations behind the
persons participating in the project. I am not my organization
I think, just as importantly, we also need to grapple with what went wrong when
features landed this way, since these were not isolated occurrences -
suggesting structural issues were at play.
I'm not sure if a retrospective is viable with this organisational structure,
but we can perhaps engag
I don't think we can realistically expect majors, with the deprecation cycle
they entail, to come every six months. If nothing else, we would have too many
versions to maintain at once. I personally think all the project needs on that
front is clearer roadmapping at the start of a release cycl
ere are no plans to stop working on it going forward.
On Tue, Jun 30, 2020 at 5:45 PM Benedict Elliott Smith
wrote:
> I don't think we can realistically expect majors, with the deprecation
> cycle they entail, to come every six months. If nothing else, we would
MV’s and tie into what you’re speaking to above
Benedict.
> On Jun 30, 2020, at 8:32 PM, sankalp kohli wrote:
>
> I see this discussion as several decisions which can be made in small
> increments.
>
> 1. In release cycles, when can we propose a featu
Yep, agreed this is definitely the best route forwards.
On 02/07/2020, 01:10, "Joshua McKenzie" wrote:
Plays pretty cleanly into the "have a test plan" we modded in last month. +1
On Wed, Jul 1, 2020 at 6:43 PM Nate McCall wrote:
> >
> >
> >
> > If so, I propose we se
+1
On 03/07/2020, 10:57, "Oleksandr Petrov" wrote:
Proposing the test build of in-jvm dtest API 0.0.3 for release.
Repository:
https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.3
Candidate SHA:
https://github.com/apache/cassan
It does raise the bar to critiquing the document though, but perhaps that's
also a feature.
Perhaps we can first discuss the purpose of the document? It seems to be a mix
of mission statement for the project, as well as your own near term roadmap?
Should we interpret it only as an advertisemen
that's table stakes. But agreeing on how we
> get
> > there, my personal take is we'd all be well served to spend our energy
> > Doing the Work and expressing these complementary positions rather than
> > trying to bend everyone to one consistent poin
gagement with the project outside a
small subset of the population with resources to dedicate to this type of
testing which I think we don't want.
On Wed, Jul 15, 2020 at 11:53 AM Benedict Elliott Smith
wrote:
> Perhaps you could clarify what you personally hope w
-1
Sorry, I dropped the ball on
https://issues.apache.org/jira/browse/CASSANDRA-15375
It's ready to commit, if somebody can give it a quick +1, and would be
prohibited after first beta.
On 16/07/2020, 21:16, "Sumanth Pasupuleti"
wrote:
+1 nb
Ran following CircleCI tests
j8_uni
etc) with marketing material and the ASF blog post that's lined up for the
project.
On Fri, Jul 17, 2020 at 5:14 AM Benedict Elliott Smith
wrote:
> -1
>
> Sorry, I dropped the ball on
> https://issues.apache.org/jira/browse/CASSANDRA-15375
&
t of diminishing returns and we're
fine just being a bit more laissez-faire about things and applying our
collective judgement through our votes on each instance. My own bias
though, definitely receptive to other points of view on that.
On Fri, Jul 17, 2020 at 11:21 AM B
Thanks Sally, really appreciate your insight.
To respond to the community discourse around this:
> Keep your announcement plans ... private: limit discussions to the PMC
This is all that I was asking and expecting: if somebody is making commitments
on behalf of the community (such as that a rel
ause of the action you took;
Actually, in this case and many others it's because of people's unfounded
assumptions about motives, incentives, and actions taken and has little to
do with reality. Which is the definition of not assuming positive intent.
On Mon, Jul 20,
not
taking this discussion further. Just want to call it out here so you or
others aren't left waiting for a reply.
We can agree to disagree.
On Mon, Jul 20, 2020 at 11:59 AM Benedict Elliott Smith
wrote:
> Firstly, that is a very strong claim that in this particul
Impacts -> Docs
It's not mandatory, but we could perhaps consider making it so somewhere in the
workflow. Do you have a good suggestion for where?
There's also "Test and Documentation Plan" which is already mandatory.
On 31/07/2020, 20:28, "Lorina Poland" wrote:
This morning, Caleb Rac
nt, I can look at the code and
figure out what it does. A topic like audit logging is likely to use many
classes and touch on many items that I'm not familiar with nor be the most
readable code.
Lorina Poland
On Fri, Jul 31, 2020 at 12:35 PM Benedict Elliott Smith
w
I do see the "Impacts" field. A search of:
*Impacts in (Docs) and project in (Cassandra) and fixVersion in (4.0)*
does turn up what I'm looking for in terms of knowing about tickets that
require docs.
The automation rule would still be nice, and could be triggered
+1
On 06/08/2020, 10:07, "Michael Semb Wever" wrote:
> I think the pragmatic thing to do is fix it now, and I'd strongly
> prefer to do that but wanted to check if there are any objections or
> things I hadn't considered?
+1
Thanks for giving this visibility and demonstr
Have we considered first asking the user list if there's anyone willing to
donate resources to maintain compatibility?
I know I have in the (distant) past handled Jira filed by (production) Windows
users. I don’t know how prevalent they are, but perhaps we should offer them a
chance to step up
ail-archive.com/user@cassandra.apache.org/msg60234.html
Jordan
On Mon, Aug 10, 2020 at 4:16 AM Benedict Elliott Smith
wrote:
> Have we considered first asking the user list if there's anyone willing to
> donate resources to maintain compatibility?
>
>
> SAI will follow the same QA/Testing guideline as in CASSANDRA-15536.
CASSANDRA-15536 might set some good examples for retrospectively shoring up our
quality assurance, but offers no prescriptions for how we approach the testing
of new work. I think the project needs to conclude the discussion
+1
On 01/09/2020, 20:09, "Caleb Rackliffe" wrote:
+1
On Tue, Sep 1, 2020, 2:00 PM Jasonstack Zhao Yang
wrote:
> +1
>
> On Wed, 2 Sep 2020 at 02:45, Dinesh Joshi wrote:
>
> > +1
> >
> > > On Sep 1, 2020, at 11:27 AM, David Capwell wrote:
> > >
> We know we are turning away more and more contributions
Do we? I haven't been aware of much of this occurring at all.
On 10/09/2020, 20:58, "Mick Semb Wever" wrote:
We know we are turning away more and more contributions and new potential
dev community with our 4.0 feature freeze, a
people using the branch seems to
mitigate that concern.
Also, when 4.0 GA'ed wouldn't we just trunk become a 4.0 branch and then
cassandra-5.0 become trunk?
On Thu, Sep 10, 2020 at 4:32 PM, Benedict Elliott Smith wrote:
> We know we are turning away more and more
r the benefit of the community. However, the community might together agree
to a partial-relaxation if it can be done safely.
On 11/09/2020, 04:09, "Jeff Jirsa" wrote:
> On Sep 10, 2020, at 2:42 PM, Benedict Elliott Smith
wrote:
>
>
>>
>> As
m concerned a new branch will not change my main goal which is
to have 4.0 out of the door.
On Fri, Sep 11, 2020 at 11:03 AM Benedict Elliott Smith
wrote:
> This is a social enterprise, and we are all able to enter into a social
> contract/convention. This doesn't
round if it
means we retain any such significant new contributions.
Work conducted without the engagement of the community can also expect to
> be heavily revised when the community finally engages with it, as
signalled
> with the CEP process.
Benedict, good point and it
y different
>
> than
>
> the one we had on the same topic 11 weeks ago:
> https://lists.apache.org/thread.html/
> raf3592f2297abfb120563d216eeea26bfb3a6e048b246492815954ff%40%3Cdev.
> cassandra.apache.org%3E
> .
>
> Jordan
a very real
challenge.
[1]: http://community.apache.org/committers/lazyConsensus.html
[2]: https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma
p.s. - sorry for being long-winded. Lots of complex stuff to cover here.
On Sat, Sep 12, 2020 at 5:46 PM Benedict Elliott Smith
> But I would suggest that we are more productive when
> raising and discussing concrete examples and specific patches
You make a good point. Can you provide some concrete examples of your own?
Ironically, this entire proposal so far rests on hypothetical lost
contributions by hypothetical comp
> I know. I recognise that is a frustrating aspect of this discussion. It
> is something hard to move on.
So how about we wait until there's a concrete example we can discuss as a
community? If we don't have one, it doesn't seem pressing.
On 16/09/2020, 08:23, "Mick Semb Wever" wrote:
+1
On 16/09/2020, 10:45, "Mick Semb Wever" wrote:
This vote is about officially accepting the Harry donation from Alex Petrov
and Benedict Elliott Smith, that was worked on in CASSANDRA-15348.
The Incubator IP Clearance has been filled out at
http://incubator.apa
I think there's significant value to the community in trying to coalesce on a
single approach, earlier than later. This is an opportunity to expand the
number of active organisations involved directly in the Apache Cassandra
project, as well as to more quickly expand the project's functionality
y has made a clear case as to a more compelling
> place to start in terms of an operator donation the project then
> collaborates on. There's no mass adoption evidence nor feature enumeration
> that I know of for any of the approaches anyone's taken, so the
discus
hat pretty much everything being discussed in this
thread has been discussed at length during the SIG meetings. I think it is
worth noting because we are pretty much still have the same conversation.
On Wed, Sep 23, 2020 at 12:03 PM Benedict Elliott Smith
wrote:
> I d
FWIW, I personally look forward to receiving that contribution when the time is
right.
On 23/09/2020, 18:45, "Josh McKenzie" wrote:
talking about that would involve some bits of information DataStax might
not be ready to share?
At the risk of derailing, I've been poking and proddi
> > project isn't interested in new contributions" (interviewees words 2
weeks
> > ago, not mine). Or same sentiment expressed by multiple major companies
> > looking to find a storage coordination layer to put in front of their
> > storage off
:05, "Brandon Williams" wrote:
On Thu, Sep 24, 2020 at 9:55 AM Benedict Elliott Smith
wrote:
>
> You do not have the authority to unilaterally overrule the community
process. This is a serious breach of your responsibilities as a member of the
PMC.
Feel free
not sacrosanct anymore?
On 24/09/2020, 16:22, "Jake Luciani" wrote:
I'm sorry I see no issue with branching 4.0 as it was the thing we voted on
back in 2018. If you wish to extend the freeze you should call a new vote.
On Thu, Sep 24, 2020 at 11:15 AM Benedic
simply pointing out the branching of 4.0 post beta was the plan of last
record.
Jake
On Thu, Sep 24, 2020 at 11:44 AM Benedict Elliott Smith
wrote:
> The community does everything through discussion and consensus. Does that
> include branching, or not?
>
>
, "Jake Luciani" wrote:
The vote was to unfreeze new changes at beta, so logically that means
non-bugfix work goes into trunk.
Jordan, thanks. That is a more recent vote so thanks. That being said,
under that line Benedict comments this needs to be discussed.
So ho
+1
On 25/09/2020, 15:45, "Oleksandr Petrov" wrote:
Proposing the test build of in-jvm dtest API 0.0.5 for release.
Repository:
https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.5
Candidate SHA:
https://github.com/apache/cassan
I would personally prefer the community to officially recommend skipping 3.11
to users that have not yet upgraded, as 3.0 and 4.0 have each had much more
attention given to them over the past several years. This would naturally lead
to fewer issues filed for 3.0->3.11 and 3.11->4.0, as fewer us
> Would it be necessary to go from 3.0 to 3.11 on the way to 4.0? I didn't
> think that was required.
That's what's being discussed, and Mick is proposing requiring it officially,
to reduce support burden.
> What has been fixed in 3.0 that hasn't been merged into 3.11 ?
Nothing that I'm aware o
Yeah, and perhaps even drop 2.1 (2.2) -> 3.11 when 4.0 appears.
I think there's anyway a big difference between supported and encouraged. I
think we should encourage 2.1->3.0->4.0, while maintaining support for 2.2->3.0
and 3.0->3.11 for critical bugs only, and 3.11->4.0 in the normal way given
o focus on 3.0->4.0 while they focus on the paths
I would be happy to deprecate.
On 09/10/2020, 15:49, "Benedict Elliott Smith" wrote:
Yeah, and perhaps even drop 2.1 (2.2) -> 3.11 when 4.0 appears.
I think there's anyway a big difference between supported and encour
reason. Your point about conservative
users upgrading later in a cycle resonates Benedict, and reflects on the
confidence we should or should not have in 3.11. I think it's also
important to realize that many cluster upgrades can take months, so it's
not a transient exposur
es w/whatever is supported at that time. That way users will be able
to have a single source of truth on what the project recommends and vets
for going from wherever they are to the latest.
On Fri, Oct 09, 2020 at 12:05 PM, Benedict Elliott Smith <
bened...@apache.org> wrote:
rent patch developed by Sylvain and
> Benedict requires an extra round trip between the coordinator and the
> replicas for SERIAL and LOCAL_SERIAL reads.
> After some experimentations, Benedict discovered that this extra round
trip
> could lead to a significant in
CASSANDRA-12126 and 4.0 we are facing several options and
> Benedict, Sylvain and I wanted to get the community feedback on them.
>
> We can:
>
>1. Try to use Benedict proposal for 4.0 if the community has the
>appetite for it. The main issue there
> Is the new implementation a separate, distinctly modularized new body of work
It’s primarily a distinct, modularised and new body of work, however there is
some shared code that has been modified - namely PaxosState, in which legacy
code is maintained but modified for compatibility, and the sy
It doesn't seem like there's much enthusiasm for any of the options available
here...
On 12/11/2020, 14:37, "Benedict Elliott Smith" wrote:
> Is the new implementation a separate, distinctly modularized new body of
work
It’s primarily a distinct, modularis
to correct).
On Wed, Nov 18, 2020 at 4:54 AM Benedict Elliott Smith
wrote:
> It doesn't seem like there's much enthusiasm for any of the options
> available here...
>
> On 12/11/2020, 14:37, "Benedict Elliott Smith"
> wrote:
&g
with a plan to opt-in by default "eventually".
>
> On Wed, Nov 18, 2020 at 11:10 AM Benedict Elliott Smith <
> bened...@apache.org>
> wrote:
>
> > Perhaps there might be broader appetite to weigh in on which major
> > rele
I think I meant #4 __♂️
On 20/11/2020, 21:11, "Blake Eggleston" wrote:
I’d also prefer #3 over #4
> On Nov 20, 2020, at 10:03 AM, Benedict Elliott Smith
wrote:
>
> Well, I expressed a preference for #3 over #4, particularly for the 3.x
series. Howev
gt; >> somebody has to make a call and live with it. It seems to me that being
> >> blamed for choosing correctness is easier to live with ;-)
> >>
> >> Benjamin
> >>
> >> PS: I tried to push the choice on Sylvain but he dodged the bu
(need to update yaml) rather than implicit (by
upgrading you agree with the change), since the latter can go unnoticed by
those who don't pay attention to NEWS.txt
Em seg., 23 de nov. de 2020 às 20:03, Benedict Elliott Smith <
bened...@apache.org> escreveu:
> What
legacy_mode:
false" and move on with their upgrades, but people wanting to keep the
previous performance will become aware of the breaking change and set it to
true.
Em seg., 23 de nov. de 2020 às 21:07, Benedict Elliott Smith <
bened...@apache.org> escreveu:
> W
m ter., 24 de nov. de 2020 às 07:26, Benedict Elliott Smith <
bened...@apache.org> escreveu:
> In my parlance the config property would be a breaking change, whereas the
> LWT behaviour would be a performance regression. This latter might cause
> partial outages or
Perhaps we should skip v5, and move to v6 for the new protocol to avoid this
issue?
On 08/12/2020, 10:53, "Sam Tunnicliffe" wrote:
CASSANDRA-15299 has revised the wire format of CQL native protocol to add a
framing layer around the existing CQL messages. This is targetted at protocol
v5,
In my opinion...
- Expected to find serious bugs (e.g. new poorly tested features): Block beta
- Anticipated to possibly find serious bugs (e.g. extensively changed features
with modest testing): Block RC
- Anticipated not to find serious bugs (e.g. old unchanged but poorly tested
features): Blo
Joshua McKenzie
> wrote:
>
> > Reasonable categories. We haven't discussed what qualifies where for 4.0
> > have we? (new lacking | changed modest | old lacking)
> >
> > On Fri, Dec 11, 2020 at 9:14 AM Benedict Elliott Smith <
> &
My preference is for a simple annual major release cadence, with minors as
necessary. This is simple for the user community and developer community:
support = x versions = x years.
I'd like to pair this with stricter merge criteria, so that we maintain a
~shippable trunk, and we cut a release a
d-cycle RC, that a user wanting
shiny features can grab, providing feedback throughout the development cycle.
On 26/01/2021, 14:11, "Benedict Elliott Smith" wrote:
My preference is for a simple annual major release cadence, with minors as
necessary. This is simple for the user com
eaking change has been introduced,
does it make sense to release a major?
On Wed, Jan 27, 2021 at 11:21 AM Benedict Elliott Smith
wrote:
> Perhaps we could also consider quarterly "develop" releases, so that we
> have pressure to maintain a shippable trunk? Thi
We have had a very problematic history with release versioning, such that our
users probably think the numbers are meaningless.
However, in the new release lifecycle document (and in follow-up discussions
around qualifying releases) we curtail _features_ once a release is GA, and
also stipulate
> if there's no such features, or anything breaking compatibility
What do you envisage being delivered in such a release, besides bug fixes? Do
we have the capacity as a project for releases dedicated to whatever falls
between those two gaps?
I'd like to see us have three branches: life suppor
But, as discussed, we previously agreed limit features in a minor version, as
per the release lifecycle (and I continue to endorse this decision)
On 28/01/2021, 16:04, "Mick Semb Wever" wrote:
> if there's no such features, or anything breaking compatibility
>
> What do you envisag
at 9:58 AM Benjamin Lerer
wrote:
> Thanks for your responses.
>
> I had some offline discussions with different persons to gather more
> feedback on the current discussion.
> The people I talked to appeared to be in favor of one supported release
>
Should we wait for e.g. five clean CI runs in a row? Historically flaky tests
have been a real issue for the project, and CI success probably shouldn't be
taken instantaneously for releases.
On 26/02/2021, 19:38, "Michael Semb Wever" wrote:
> * We’re within line-of-sight to closing out
Very nice.
On 26/02/2021, 21:36, "Melissa Logan" wrote:
Hi all,
We are excited to share the almost-complete Cassandra website design
(CASSANDRA-16115). Huge thanks to Lorina Poland, Anthony Grosso, Mick Semb
Weaver, Josh Levy, Chris Thornett, Diogenese Topper, and a few others
Fair enough.
On 26/02/2021, 20:45, "Mick Semb Wever" wrote:
Should we wait for e.g. five clean CI runs in a row? Historically flaky
> tests have been a real issue for the project, and CI success probably
> shouldn't be taken instantaneously for releases.
There are tickets fo
A while back somebody privately raised the idea of a project roadmap to me, and
I’d like to propose we formally consider it as a project now that 4.0 is
approaching completion.
I think there are two major benefits to agreeing a roadmap:
1) It helps us to coordinate finite project resource
rk" is not restricted to items in the project
roadmap and developers can still make contributions to work unlisted in the
project roadmap, I think having a project roadmap is certainly a step in
the right direction.
Thanks,
Sumanth
On Mon, Mar 1, 2021 at 1:18 A
I guess I meant that I don't foresee roadmap discussions having a hard
requirement of CEP for all goals we might discuss, though it would probably be
expected that many of the biggest proposals would already at least have a
minimal CEP to be filed, you're right.
Certainly if an advanced CEP ex
a strongly held position on
either (but think it's probably better they're not intrinsically tied in either
direction).
On 01/03/2021, 12:13, "Benedict Elliott Smith" wrote:
I guess I meant that I don't foresee roadmap discussions having a hard
requirement of
w we
plan to use CEPs moving forward.
.
Le lun. 1 mars 2021 à 13:21, Benedict Elliott Smith a
écrit :
> I guess I meant that I don't foresee roadmap discussions having a hard
> requirement of CEP for all goals we might discuss, though it would
probably
> be
focus on first.
What do you think?
Le mar. 2 mars 2021 à 06:29, Berenguer Blasi a
écrit :
> +1000 on some form of roadmap for visibility and planning
>
> On 1/3/21 18:35, Benedict Elliott Smith wrote:
> > I completely agree we should consider any roadmap
s been launched. The longer you will stay with it the
> more troubles you will get with it over time.
>
> Kind regards,
> Lukasz
>
>
> > Wiadomość napisana przez Robert Stupp w dniu 2 kwi
> 2015, o godz. 14:51:
> >
> > TL;DR - Benedict is right.
> >
> > I
sal. I'm just attempting to explain my perception
of the view of the existing contributors.
On Mon, Apr 13, 2015 at 9:31 PM, Łukasz Dywicki wrote:
> Hey Benedict,
> My replies in line
>
>
> >> According to some recordings from DataStax there is a plan to support in
> >
iven me a
much wider view of the codebase than I otherwise would have likely had, and
I would hate to see that discouraged.
On Mon, Apr 13, 2015 at 5:37 PM, Ariel Weisberg wrote:
> Hi Benedict,
>
> This only requires unit testing or dtests to be run this way. However for
> >
If you're connecting via thrift, all your traffic is most likely being
routed to just one node, which then communicates with the other nodes for
you.
On Wed, Apr 22, 2015 at 6:11 AM, Anishek Agarwal wrote:
> Forwarding it here, someone with Cassandra internals knowledge can help may
> be
>
>
>
> How would it be different from creating an actual real extra table instead?
There's nothing that warrants making the codebase more complex to
> accomplish something it already does.
As far as I was aware, the only point of static columns was to support the
thrift ability to mutate and read
at 3:01 PM, Jonathan Ellis wrote:
> I'm down for adding JOIN support within a partition, eventually. I can see
> a lot of stuff I'd rather prioritize higher in the short term though.
>
> On Fri, May 1, 2015 at 8:44 AM, Jonathan Haddad wrote:
>
> > I think what Be
uch easier to flush a
> single memtable to more than one stable on disk (static and non static) and
> then allow for separate compaction of those
>
> > On May 1, 2015, at 9:06 AM, Benedict Elliott Smith <
> belliottsm...@datastax.com> wrote:
> >
> > It also doesn&
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
>
> 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
ation, 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 annoying for
> >> everyone
it fails
> > it fails because it's broken by the latest merge.
> >
> > At this size I don't see the need for a staging branch to prevent trunk
> > from ever breaking. There is a size where it would be helpful I just
> don't
> > think we are there yet.
mit 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 testing before every merge.
>
>
>
>
> On Thu, May 7, 2015 at 10
7;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 time it hits the branch,
> releasable code is way
y. I have been on a team roughly our
> size
> > that shipped every three weeks without having staging branches. Trunk
> broke
> > infrequently enough it wasn't an issue and when it did break it wasn't
> hard
> > to address. The real pain point was flapping tests
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
Hi Min,
The key selection occurs prior to this. The operation has been assigned one
(or more, in the case of user profile operations) partition keys, and this
is just it accessing that key. You should explore backwards for assignment
operations, and see where these happen, to understand how this b
501 - 600 of 753 matches
Mail list logo
