-0. Agree w/Gary, but not willing to die on this hill. We'll see how it
goes.
On Thu, Jul 12, 2018 at 12:46 PM sankalp kohli
wrote:
> merging non code will be allowed correct
>
> On Thu, Jul 12, 2018 at 9:41 AM Stefan Podkowinski
> wrote:
>
> > +1
> >
> > (assuming merging patches on documentat
>
> Deferring huge amount of commits gives rebase/redo hell. That's the
> biggest impact and the order in which these deferred commits are then
> actually committed can make it more painful or less painful depending on
> the commit. And that in turn will have to then wait for each contributor
> to
On Thu, Jul 12, 2018 at 10:54 AM, Michael Burman
wrote:
> On 07/12/2018 07:38 PM, Stefan Podkowinski wrote:
>
>> 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, compar
On 07/12/2018 07:38 PM, Stefan Podkowinski wrote:
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 ge
merging non code will be allowed correct
On Thu, Jul 12, 2018 at 9:41 AM Stefan Podkowinski wrote:
> +1
>
> (assuming merging patches on documentation will always be possible, as
> it's not effecting the code base)
>
>
> On 11.07.18 23:46, sankalp kohli wrote:
> > Hi,
> > As discussed in the
+1
(assuming merging patches on documentation will always be possible, as
it's not effecting the code base)
On 11.07.18 23:46, sankalp kohli 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 tru
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
-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
+1
On 12 July 2018 at 08:49, Mick Semb Wever wrote:
>
> > Vote will be open for 72 hours.
>
>
> +1 (non-binding)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@ca
> Vote will be open for 72 hours.
+1 (non-binding)
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
10 matches
Mail list logo
