+1
“This thread was not about sacrificing stability. It is a pity that it came
across like that.“
On Mon, 29 Jun 2020 at 13:35, Stefan Miklosovic <
stefan.mikloso...@instaclustr.com> wrote:
> On Mon, 29 Jun 2020 at 16:50, Jon Haddad wrote:
> >
> > > I have been against the freeze from day one. I
On Mon, 29 Jun 2020 at 16:50, Jon Haddad wrote:
>
> > I have been against the freeze from day one. In my opinion it had a
> negative impact on the project.
>
> I'm curious how you're measuring this. Based on my time as an evangelist
> at DataStax and as a consultant with the Last Pickle, I can sa
>
> As long as you keep thinking the expressions on this ML reflect an
> organization's priorities and not the opinions of individual actors we're
> not going to get anywhere.
I propose we agree to disagree and stop thrashing the project with this
topic. Nobody is going to change their mind based
To answer your questions Jon.
I have been against the freeze from day one. In my opinion it had a
> negative impact on the project.
>
It is simply an opinion. I stated it as such because I have no way to
validate or invalidate that theory.
Had we unfrozen trunk a year ago, we just
> would have s
> I just believe that we should not look at the organizations behind the
> persons
You collaborate as an organisation, produce work for the project as an
organisation, and the organisation tells its members - each to some greater or
lesser extent - how to spend their labour. Even if we only t
>
> I am pointing to the implied signals about an organisation's priorities
> and values that are communicated by its actions
As long as you keep thinking the expressions on this ML reflect an
organization's priorities and not the opinions of individual actors (like
my email about branching was be
> I have been against the freeze from day one. In my opinion it had a
negative impact on the project.
I'm curious how you're measuring this. Based on my time as an evangelist
at DataStax and as a consultant with the Last Pickle, I can say I rarely
talked to people looking for shiny new features.
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 and it does
not push me in a direction or another.
Of course, our opinions are somehow tainte
I believe that we should try to assume that everybody has positive intentions.
:-)
What did I say that suggests I have assumed any negative intentions? Sometimes
this phrase reads as a thought-terminating cliché.
On 29/06/2020, 13:28, "Benjamin Lerer" wrote:
>
> If this is in res
>
> If this is in response to my email, you misunderstand me.
>
Sorry, that was not a response.
Increasing stability was mentioned a lot in that thread. I am all for it. I
just wanted to raise the issue that the plan for that is not clear at least
for me.
That is not to say there should not be ag
If this is in response to my email, you misunderstand me. There are distinct
issues at play. To respond directly to the issue you raise: I am personally
inclined to pursue a release of 4.0 within some time-box - say 3-6 months. We
have already done a huge amount to improve the quality of the
I believe that we all need to see 4.0.0 being released. We have been frozen
for too long in my opinions and some people simply believe that the project
is dead. That is hurting us.
That does not mean that I am not in favor of making that release as stable
as possible.
What we miss in my opinion is
> 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, particularly in
public fora where it can be more polite and less disruptive than direct
criticism. Ironically, this snippet of yo
I thought about this a bit more overnight - if I'm arguing that most work
would be fast forward merges to trunk if we branched beta due to the type
of work going into beta, the inverse argument should hold that most merges
into a feature branch would be fast forward or minimal. So I think the
basic
Great point re: increasing the public visibility of testing and validation
activity.
I’ll partner with a few contributors I work with to prep a summary of our
findings that aren’t already captured in JIRA tickets we’ve filed against 3.x
and 4.0 so far (as David mentioned, many issues we’re iden
>
> I've seen a lot of talk from some quarters of a new approach to quality,
> but so far there have been few 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).
Wh
> On Jun 26, 2020, at 3:45 PM, David Capwell wrote:
>
> the ability to test their impact. Even simple things become hard given the
> fact only committers can run Jenkins tests, 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
This is all really key to be honest. The only feature we need to develop today
is quality, and this is true regardless of 4.0.0. I've seen a lot of talk from
some quarters of a new approach to quality, but so far there have been few
contributions from the same quarters that materially contribu
>
> 1) changes going into beta should be small enough that a fast-forward merge
>
should be available in the majority of cases up to trunk. We've done this
> with previous releases and it wasn't prohibitively expensive in terms of
> time. Further, I would posit that changes going into beta should b
On Fri, Jun 26, 2020 at 2:58 PM Benedict Elliott Smith
wrote:
> > Nothing is stopping us for discussing CEPs now, and nothing prevents
> folks from making their own feature branches.
>
> I disagree. CEPs are just as - if not more - of a distraction than
> branching.
>
> Work doesn't happen in a
> Nothing is stopping us for discussing CEPs now, and nothing prevents folks
> from making their own feature branches.
I disagree. CEPs are just as - if not more - of a distraction than branching.
Work doesn't happen in a vacuum. Those who are today focusing what resources
they can on shippin
We currently have 2.1, 2.2, 3.0 3.11, and trunk. With a new branch we'll
_also_ have whatever is next, let's call it 5.0.
Nothing is stopping us for discussing CEPs now, and nothing prevents folks
from making their own feature branches.
If we're going to add another branch (4.0) and let people m
>
> > Branching anytime before we 4.0.0 adds extra burden to the folks trying
> to
> > get 4.0.0 out the door (because of merge up)
>
> Given both that we've done this with every major release in the past, as
> well as the type of work we'd expect to land during the beta phase
> (smaller, non-api b
Ok, I'm sorry for reaching the opposite conclusion before reading this email -
the implication here instead appears to be that, you believe, people are
advocating to integrate work that should be deferred - is that correct?
Perhaps we should have a direct conversation about the tickets you cons
--> Branching anytime before we 4.0.0 adds extra burden to the folks trying to
get 4.0.0
This. This is all that matters IMO. Some have been saying 4.0.0 is very
delayed, and that this harms the project - and they're right. So I'm surprised
to see those same voices advocating we prioritise th
I was speaking with Ekaterina and Benjamin about some of the currently
alpha scoped work which is what made me think of this dynamic. There's a
very different dynamic from "if we push this out to the next major, this
code will atrophy for 3-6 months" vs. "if we push this out to the next
major, you
I was originally against the trunk freeze because I didn't want it to
prevent progress, now I'm 100% on board with it and I think we should keep
it in place till we release 4.0.0.
Branching anytime before we 4.0.0 adds extra burden to the folks trying to
get 4.0.0 out the door (because of merge up
Thanks for bringing this up Josh. I think the last time we all discussed
this on the mailing list was during the initial freeze thread where we
agreed "that between the September freeze date and beta, a new branch would
not be created and trunk would only have bug fixes and performance
improvements
I think that this goes well with the philosophy of the open source and
volunteering contributions.
Also, it could really open the door for more new features and people
contributing to the project in the long term.
Ekaterina
On Fri, 26 Jun 2020 at 10:44, Sylvain Lebresne wrote:
> Fwiw, I agree wi
Fwiw, I agree with that POV in general (that it's probably beneficial on
balance to branch now/soonish for the reasonings Josh mentioned).
--
Sylvain
On Fri, Jun 26, 2020 at 3:43 PM Joshua McKenzie
wrote:
> As we close on cutting beta1, a new consequence of our release lifecycle is
> becoming a
As we close on cutting beta1, a new consequence of our release lifecycle is
becoming apparent. With guarantees of API stability in the beta phase, any
work that is deferred from alpha to the next major due to API impacting
changes will atrophy for as long as the beta is active.
Cutting a branch fo
31 matches
Mail list logo
