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
The new release lifecycle guarantees changes these dynamics. Given our
commitment to API stability between beta 1 and GA, this has introduced a
time where changes being deferred to the next major due to API modification
will be unable to be merged unless we branch upon beta.
This warrants another
>
> Also, what is the plan for cutting beta branch? I am still learning the
> Apache/C* way so excuse me if I missed something. Looking at the Lifecycle
> document, I see a point only about GA major version branch.
> My understanding is that we are already in freeze for big changes. When
> would b
19 matches
Mail list logo
