+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 (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 easi
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 you'
>
> 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 cost
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 ver
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. M
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 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 whe
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 (d
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
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 they
How is this preventing someone from working and collaborating on an Apache
Project? You can still collaborate on making 4.0 more stable.
Why will these committers not work on making 4.0 more stable and fix broken
tests? Considering we cannot release without test passing, how will these
features b
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 Ap
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
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 b
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 rel
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 stre
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 stre
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, 201
19 matches
Mail list logo
