On Sun, Aug 27, 2017 at 7:21 PM, Thomas Weise <t...@apache.org> wrote:
> I think you have been consistent in your position. However, we cannot claim
> something is a community concern unless that is the case.
>
> On Sun, Aug 27, 2017 at 5:37 PM, Pramod Immaneni <pra...@datatorrent.com>
> wrote:
>
> >
> > It could easily
> > be argued the other way, that it is easy to propose wholesale changes
> > without much thought to what it would take to support existing users when
> > there is no obligation to support them like a vendor may have.
>
>
> How so? I will argue that the opposite is true. I don't want to repeat
> things again and again. You know that I proposed an option based on 3.x
> (and took the time to implement it) that would have required no change to
> the user and not even a major version change. Now are debating major
> version change, which no existing user is obligated to adopt, users can
> continue with what they have and the vendor can continue to support 3.x.
>
The implementation, while did consider backward compatibility, provided a
frozen version of the project and would require users to change their code
in order to benefit from newer fixes and updates to existing operators.
While appreciating the approach, I did note these shortcomings in the
discussions in original discussion and the subsquent one and asked if a
similar approach could be applied in a way that it would be possible to
allow existing applications to benefit from future updates in the same
major version without code changes. This is not trivial and when I saw
there was no appetite to do this, I supported 4.x as the alternative.
> Let's keep in mind that today there are not many users ("many" is
> subjective). It is further a misrepresentation to claim that the community
> wanting to make changes negatively affects users. I will argue the opposite
> is true, the changes that are proposed will make it easier for new users to
> adopt and build applications.
>
This is a very broad and incorrect interpretation of the original statement
and it does not say or translate to "community
wanting to make changes negatively affects users". It gives one
interpretation of the original proposal of changing the package paths
without providing wrappers that will remain compatible with older versions
for at least some transitional period (no frozen older release is not the
same). It is not what the community as a whole wants, so I wouldn't call it
a community want either.
> >
> >
> > Yes nothing would prevent contributors from submitting the changes to
> > master simultaneously and should be encouraged. I am trying to figure out
> > the best way to accomodate the ask where the contributors be not required
> > to do so when they cannot or don't want to do so and to not block those
> > contributions. I don't know if this will change the -1 votes but hoping
> > folks can discuss this.
> >
>
> If it is purely a vendor interest and not a community interest, then it is
> also possible to apply such changes to the fork. This has been done in the
> past. I see a risk that we are discussing something that may not even
> become relevant, looking at current contributions and type of changes.
>
Then lets allow it for the specific release-3 branch and see how it goes.
This might assuage the concerns of those who raised them and help them come
around to going for a 4.x now.
Thanks
