several things to improve the 4.0 process including that "we lack clarity
around scoping of this release and don't seem to have a project-wide
consensus on how we're handling this."
Gotcha. Yeah, for me the argument of "people working on 4.0 should have to
carry the burden of merging forward" is a
On Fri, Sep 11, 2020 at 9:18 AM Joshua McKenzie
wrote:
> I thought it was the former; seems like it's
> the latter.
>
>
Looking at the thread I link, both are discussed (initially the former but
it turns to the latter briefly as well before going down a path similar to
the one this thread is star
it seems unlikely this conversation will be any different than the one we
had on the same topic 11 weeks ago
The big difference to me is whether the turning point on the conversation
is the extra work required by people working on 4.0 to merge up to a new
trunk or if the turning point is on a desi
It still seems to me that the best use of our efforts as a community is to
come together to get a stable 4.0 out as fast as possible. It would address
the branching and freeze issues that have been raised -- neither of which
currently prevent people from "scratching an itch", maintaining a
non-offi
> 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 comm
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-target
As I said before
> The more significant cost to the project is distracting contributors focused
> on 4.0
This a conversation we keep coming back to, so I will highlight this phrase for
future repetition: Work does not happen in a vacuum. The whole community bears
a cost when new work is integr
>
> People might be itching to get out, particularly those who are unlikely to
> be harmed, but most agree to stay put for the benefit of the community.
>
The freeze has been there for quite a while now and as far as I can see the
goal of all those working on C* right now is to have 4.0 out. Will
This is a social enterprise, and we are all able to enter into a social
contract/convention. This doesn't prevent someone from breaking the
convention, or not agreeing to it, of course, but this entails social costs.
This is exactly how the feature-freeze has worked until now, curtailing
deve
I second David. I think I can speak up here as I perfectly fit into
the bucket of "new people trying to contribute".
While it is true that reviews tend to take a long time I am perfectly
happy with people who eventually look at them. It is understandable
that there is a lot of going on and a commi
10 matches
Mail list logo
