These are some valid concerns. But I don’t really see it that way after thinking about it. We already have restrictions and consensus based practices in place that may discourage new contributors. E.g. if someone submits a patch to enable a different GC by default in 2.1, that’s probably not going to happen, even if carefully tested by the contributor. We also don’t accept any patches at all for older 3.x versions, although there may be people who are not able to update to 3.11 and would really like to get their 3.x version patched for something.
That’s not because we want to discourage people from contributing in a “scratch an itch” way. It’s just what we agreed on how to coordinate our efforts and what kind of patches to accept for individual releases. So if it’s fine to tell people that we’re not able to accept patches for any version they are already running, why should we not be able to do so for an upcoming, unreleased version that isn’t even used by anyone at this point? Also, if we tell someone that their contribution will be reviewed and committed later after 4.0-beta, how is that actually making a difference for that person, compared to committing it now for a 4.x version. It may be satisfying to get a patch committed, but what matters more is when the code will actually be released and deferring committing contributions after 4.0-beta doesn't necessarily mean that there's any disadvantage when it comes to that. On 12.07.18 15:23, Gary Dusbabek wrote: > -0 > > I'm not interested in sparking a discussion on this, because a) it has > already happened and b) it seems I am in a minority. But thought I should > at least include the rationale for my vote: > * This proposal goes against the "scratch an itch" philosophy of making > contributions to an Apache project and IMO will discourage contributions > that are casual or new. > * It feels dictatorial. IMO the right way to do this would be for > impassioned committers to -1 any patch that goes against elements a, b, or > c of what this vote is for. > > Gary. > > > On Wed, Jul 11, 2018 at 4:46 PM sankalp kohli <kohlisank...@gmail.com> > wrote: > >> Hi, >> As discussed in the thread[1], we are proposing that we will not branch >> on 1st September but will only allow following merges into trunk. >> >> a. Bug and Perf fixes to 4.0. >> b. Critical bugs in any version of C*. >> c. Testing changes to help test 4.0 >> >> If someone has a change which does not fall under these three, we can >> always discuss it and have an exception. >> >> Vote will be open for 72 hours. >> >> Thanks, >> Sankalp >> >> [1] >> >> https://lists.apache.org/thread.html/494c3ced9e83ceeb53fa127e44eec6e2588a01b769896b25867fd59f@%3Cdev.cassandra.apache.org%3E >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
