> if we do these contributions in secret
Are you aware of any work happening (or expected to happen) in this way? This
seems a very different problem than the one the thread was opened with.
> it will be even harder for folk to put in late reviews
It is always harder to revert and revisit committed work, than to review work
that has not been merged. So the flood gates you expect to open will still
flood those people working on 4.0, only worse. There is also no such thing as a
"late review" in this context; the review happens, at whatever pace is
necessary, as agreed recently by the community. If an organisation drops
several huge patches, progress will quite reasonably be slow. The best way to
mitigate this would be to invest more of those secret resources into shipping
4.0, so the project can be on an even keel.
On 11/09/2020, 13:06, "Mick Semb Wever" <m...@apache.org> wrote:
For significant new feature work, the option of working in a public,
> long-running, trunk-based feature branch is available. If we look at a
> specific example like CEP-7/SAI, I’m not sure how it would benefit much
> from a 5.0 branch, at least until it fundamentally depended on other
> 5.0-targeted work.
>
Caleb, I'm seeing an important value to the branch (given there's no
inter-dependencies between patches) is the CI builds on the cassandra-5.0
branch, and the efforts of rebasing centralised from many feature branches
to one preview branch.
Raising the CEP process is interesting. Anything significant enough to
warrant a CEP still has to go through that process (which has limited
throughput atm) and I can't imagine anything that size making it to the
cassandra-5.0 before we got to 4.0-rc (which is hopefully in a few months).
But we are sending the clear signal that we are no longer shutting out
these contributions.
Maybe the effort should be done in the area of getting more people on
> board technically so they can start to review things themselves (which
> indeed takes a lot of time and patience) instead of creating a new
> branch so they can pile up their stuff there.
Stefan, the cassandra-5.0 is not a substitute for reviews. Good habits in
preparation for reviews: like rebasing your feature branch, having CI
results ready to view; and the review process itself remains exactly the
same, and will take the same time as before.
You do have strong review preparation habits in place. I can see that the
CI builds (not just a selection of tests but the whole complete pipeline)
being part of the value you are taking advantage of here. We want to
re-apply that value also to the cassandra-5.0 branch with its patches that
are post-review yet, not yet merged to trunk. That CI would help smoke out
the combination (sequence) of reviewed patches all put together, and easing
the burden of the re-review of those patches, before they land in trunk.
Again… if the feature freeze is now a quickly shortening window, it's going
to be very limited to what might make it into such a branch, so mostly
about sending the signal that this final hurdle can be worked around if it
means we retain any such significant new contributions.
Work conducted without the engagement of the community can also expect to
> be heavily revised when the community finally engages with it, as
signalled
> with the CEP process.
Benedict, good point and it loops into what Caleb touches on. The CEP
intends to bring out community involvement earlier in the development
cycle, to avoid the late revisions. And under the feature freeze the CEP
process is an obvious bottleneck and I don't think we can get around that.
As far as dev involvement goes, it doesn't stop just because something is
merged to trunk, commits in trunk can also be re-reviewed and then
reverted, but that's something we want to avoid. So yes, ofc there will be
those that want to have their say on things sitting in the 5.0 branch that
have otherwise met reviewer requirements, at the same time (as long as the
branch remains limited in its scope) this does lengthen out the dev cycle
for these contributions providing more patience and soak time for all. I
would expect that the maintainers of the branch extend the opportunity for
late reviewing to those that were doing The Right Thing focusing all their
time on getting 4.0 out, before those commits go into trunk. Opposed to
this, if we do these contributions in secret to avoid these types of
discussions, only raising them once the feature-freeze is lifted, there may
be a flood-gates rush and it will be even harder for folk to put in late
reviews. I would certainly rather see exceptions made and things done in
public (even if in a fork), though the main concern we are hearing is folk
simply walking away altogether.
I agree with the social responsibility perspective as well, but it's not
something we can enforce. If folk want to do this we can't stop them and we
should listen to why they believe it is a valuable exception.
I do believe the discussion and hearing out people's frustrations: how
overloaded and focused on 4.0 they are, and the concerns of how this risks
delaying 4.0; should happen and is of immense value.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
