I feel like the calendar is relevant though because if we delay 3.8 more
we're looking at a week, maybe 10 days before 3.9 is scheduled. Which
doesn't give us much time for the stabilizing we're supposed to do in 3.9.
All in all I think I agree that releasing 3.8 in August is less confusing
than
Hi John,
I work for the DSE team. What you're seeing is the result of DSE having its
own release schedule distinct from Apache Cassandra. We'll start qualifying an
Apache release to build on, such as 3.0.7 for DSE 5.0, but if 3.0.8 comes out
while we're still working on 5.0.1 we won't necessa
Yeah, unfortunately right now we're in clean-up / debt mode when it comes
to shoring up the quality of tests in the code-base, as well as the
stability of CI.
Once we're consistently all-green it should be much easier to figure out
who to point fingers at when things fail. :)
On Thu, Jul 21, 2016
On Thu, Jul 21, 2016 at 5:40 PM, Aleksey Yeschenko
wrote:
> We don’t need to block 4.0 on #8110.
>
> What we need is to block those sstable-format related tickets on *either*
> #8110 *or* 4.0.
>
You're right, I kind of listed the ticket a bit quickly.
>
> #8110 itself can go anywhere in 3.x or
On Thu, Jul 21, 2016 at 5:42 PM, Jeremiah D Jordan <
jeremiah.jor...@gmail.com> wrote:
> > Josh, add me to the "test fixers" queue, as well. However, I think the
> > authors of patches that break the build should also be on the hook for
> > fixing problems, as well.
>
> +1 I have always been a fan
> Josh, add me to the "test fixers" queue, as well. However, I think the
> authors of patches that break the build should also be on the hook for
> fixing problems, as well.
+1 I have always been a fan of “you broke it, you fix it"
We don’t need to block 4.0 on #8110.
What we need is to block those sstable-format related tickets on *either* #8110
*or* 4.0.
#8110 itself can go anywhere in 3.x or 4.x.
--
AY
On 21 July 2016 at 15:38:58, Jason Brown (jasedbr...@gmail.com) wrote:
Sylvain,
In the large, yes, that is the b
On Thu, Jul 21, 2016 at 4:38 PM, Jason Brown wrote:
> Sylvain,
>
> In the large, yes, that is the best "have enough mechanism in place that no
> further ticket _have to_ wait for a major", but many of the tickets we are
> talking about makes changes to things we've all agreed can *only* happen at
What is the difference behind Datastax DSE Cassandra and open source.
1. Why is Datastax maintaining a fork of open source where they back port fixes
which are not back ported for the community for that version. People running
DSE wants more stability thats why?
2. I know community move
>> Any reason not to draw a line in the sand for the next stabilization
release (3.9)?
+1
Josh, add me to the "test fixers" queue, as well. However, I think the
authors of patches that break the build should also be on the hook for
fixing problems, as well.
On Wed, Jul 20, 2016 at 2:05 PM, Jo
I have no vote here, but I think that #2 is not a good idea here. We would
be implicitly releasing an "odd" release with new features, which is more
than a little confusing. I do think that CDC is important, so I don't like
#4 (but for less important reasons than #2). So, I'm good with options 3
What we’d usually do is revert the offending ticket and push it to the next
release, if this indeed were significant enough.
So option 4 would be to revert CDC fast (painful) and ship.
Option 5 would be to quickly fix the issue, retag, and revote, with 3.9 still
following up on schedule.
Option
D'oh, too late to respond :)
I was going to comment that leaving the non-critical commits in 2.1 is
probably OK at this point (the deed has already been done), as long as we
agree to become more rigorous in the future about critical bugs vs bugs vs
minor enhancements vs major features and in which
Sylvain,
In the large, yes, that is the best "have enough mechanism in place that no
further ticket _have to_ wait for a major", but many of the tickets we are
talking about makes changes to things we've all agreed can *only* happen at
majors, as per the http://wiki.apache.org/cassandra/Compatibil
Sounds like we have consensus on that. I will handle the reverts and
update Jira.
On Wed, Jul 20, 2016 at 7:11 PM, Aleksey Yeschenko
wrote:
> Keep #11349, revert the rest sounds reasonable.
>
> --
> AY
>
> On 20 July 2016 at 22:27:05, sankalp kohli (kohlisank...@gmail.com) wrote:
>
> +1 on only
I think this is the right way to think about the problem.
Does 12042, 9424, 8110 cover those bases then?
On Thu, Jul 21, 2016 at 9:02 AM, Sylvain Lebresne
wrote:
> My very own preference would be to actually focus on making 4.0 the release
> where have enough mechanism in place that no further
My very own preference would be to actually focus on making 4.0 the release
where have enough mechanism in place that no further ticket _have to_ wait
for a major. That means at least making sure CASSANDRA-12042 makes it in,
adding some proper versioning of schemas and CASSANDRA-8110.
If we had al
On Thu, Jul 21, 2016 at 3:21 PM, Jonathan Ellis wrote:
> I see the alternatives as:
>
> 1. Release this as 3.8
> 2. Skip 3.8 and release 3.9 next month on schedule
> 3. Skip this month and release 3.8 next month instead
>
I've hopefully made it clear I don't really like 1. I'm totally fine with
I see the alternatives as:
1. Release this as 3.8
2. Skip 3.8 and release 3.9 next month on schedule
3. Skip this month and release 3.8 next month instead
On Thu, Jul 21, 2016 at 8:19 AM, Aleksey Yeschenko
wrote:
> I still think the issue is minor enough, and with 3.8 being extremely
> delayed
I still think the issue is minor enough, and with 3.8 being extremely delayed,
and being a non-odd release, at that, we’d be better off just pushing it.
Also, I know we’ve been easy on -1s when voting on releases, but I want to
remind people in general that release votes can not be vetoed and on
Sorry but I'm (binding) -1 on this because of
https://issues.apache.org/jira/browse/CASSANDRA-12236.
I disagree that knowingly releasing a version that will temporarily break
in-flight queries during upgrade, even if it's for a very short time-frame
until re-connection, is ok. I'll note in particu
21 matches
Mail list logo
