+1.
> On 9 Jul 2018, at 20:17, Mick Semb Wever wrote:
>
>
>> We have done all this for previous releases and we know it has not worked
>> well. So how giving it one more try is going to help here. Can someone
>> outline what will change for 4.0 which will make it more successful?
>
>
> I
The most impactful change that I can see is the people that are
involved with development who are willing to -1 a release. Those of
us with votes are TLP have a big incentive for 4.0 to be stable - we
want people to upgrade. I assume folks at Netflix, Apple are also
very incentivized to see a
Sure...thats an addition to the 3 states I was thinking(-1,+/-0 and +1) :)
On Mon, Jul 9, 2018 at 12:49 PM Josh McKenzie wrote:
> >
> > I did not see a -1 but all +0s and a few +1s.
>
> It's more accurate to say you have quite a few -0's, some +0's, and a few
> +1's, probably some -0.5's if
What I’m saying is that for new contributors, not branching has a cost and I
think there are other ways to organize efforts.
One of the suggestions was for each organization to test their own use cases in
the stabilization process. I don’t think that’s been done very effectively
previously.
We have done all this for previous releases and we know it has not worked
well. So how giving it one more try is going to help here. Can someone
outline what will change for 4.0 which will make it more successful?
Not branching is one idea but we should discuss what will change now than
iterating
>
> I did not see a -1 but all +0s and a few +1s.
It's more accurate to say you have quite a few -0's, some +0's, and a few
+1's, probably some -0.5's if you're into that.
On Mon, Jul 9, 2018 at 2:53 PM Jeremy Hanna
wrote:
> What I’m saying is that for new contributors, not branching has a
> We have done all this for previous releases and we know it has not worked
> well. So how giving it one more try is going to help here. Can someone
> outline what will change for 4.0 which will make it more successful?
I (again) agree with you Sankalp :-)
Why not try something new?
It's
What did we land on? Sounds like we're pretty split without consensus on
"change the old branching strategy and reject new things on trunk during
stabilization" vs. "keep doing things the way we did but message strongly
that we won't be reviewing new things until 4.0 is stable".
On Sat, Jul 7,
This sha fails to build JDK7. If built on JDK8, which is what I did
erroneously, the release fails with JDK7 runtime in AntiCompactionTest.
In going through a round of test builds, it appears we have a problem
with the CASSANDRA-14423 commit calling a JDK8-only String.join().
I'm vetoing this
Based on the CASSANDRA-14555 notes and revert of the CASSANDRA-14252
from the cassandra-3.0/3.11 branches, I'm also a -1 for release.
Kind regards,
Michael
On 07/03/2018 02:14 AM, Sam Tunnicliffe wrote:
> -1 I think CASSANDRA-14252 should be reverted from 3.0 & 3.11, at least the
> effect on
Based on the CASSANDRA-14555 notes and revert of the CASSANDRA-14252
from the cassandra-3.0/3.11 branches, I'm also a -1 for release.
Kind regards,
Michael
On 07/03/2018 02:14 AM, Sam Tunnicliffe wrote:
> -1 I think CASSANDRA-14252 should be reverted from 3.0 & 3.11, at least the
> effect on
Greetings, Apache software enthusiasts!
(You’re getting this because you’re on one or more dev@ or users@ lists
for some Apache Software Foundation project.)
ApacheCon North America, in Montreal, is now just 80 days away, and
early bird prices end in just two weeks - on July 21. Prices will
I did not see a -1 but all +0s and a few +1s.
On Mon, Jul 9, 2018 at 5:49 AM Josh McKenzie wrote:
> What did we land on? Sounds like we're pretty split without consensus on
> "change the old branching strategy and reject new things on trunk during
> stabilization" vs. "keep doing things the way
I don't see how changing the process and banning feature commits is
going to be any help to the project. There may be a couple committers
who are interested in committing new features.
I'm a -1 on changing the branching strategy in a way that prevents
people from working and collaborating on an
Not everyone wants to work and collaborate the way you do. It seems
absurd to me to force everyone to hold off on merging into a single
branch just because a lot of us want to prioritize testing 4.0.
I think most committers are going to want to contribute to the 4.0
testing process more than
If some committers want to bring in features without a path forward for
releasing(as tests are broken), is that an acceptable state for you? How do
we get out of this state.
Like I said in my original email, this is a "proposal" and I am trying to
see how we can improve things here. So if you are
My proposal is that we implement everything you're suggesting, except
we branch off as we have in the past rather than locking down trunk.
I'd encourage everyone to work to improve 4.0 in some way or another,
whether it be fixing bugs, testing in a staging environment
(feedback), writing tooling
I wholeheartedly agree with efforts to make releases more stable and the more
contributors that add tests or test within the context of their own use cases,
the better. +1 non-binding to the idea of better, more complete testing for
releases.
When it comes to how to do this, I think that’s
18 matches
Mail list logo
