apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pramod Immaneni <pra...@datatorrent.com>
Subject Re: [DISCUSS] changing project name to apex-library
Date Fri, 25 Aug 2017 19:37:18 GMT
On Fri, Aug 25, 2017 at 10:16 AM, Thomas Weise <thw@apache.org> wrote:

> There is obviously disagreement with regard to version reset and you have
> already voted for 4.0.
>

Yes and my position is still the same. I think there is a general consensus
with 4.0, the additional concern/ask from community I believe, is because
of the divergence as things go forward, to not burden the contributor from
having to submit the PR to both master and release-3 and to relax the
restriction by allowing submissions to go into release-3 without requiring
they go into master. This would be different from what we do today.

I think we can accomodate this for the following reasons. For the most part
fixes and updates to existing operators/code would be cherry pickable onto
master as is, with simple conflict resolution or with minor changes on top
such as package name changes. If the contributor does not want to do the
work the committer or the community can step in and do this at the same
time when the original PR is merged or asynchronously if more time is
needed so as to not block the original PR. We will need a way to track
pending items and possibly we could do this in JIRA itself and additionally
not close the JIRA till it is also fixed in master. The ones that are not
trivial to port would be few in my opinion because as things go forward
majority of the contributions will just go to master and for these few we
can again rely on the community for help. Also, with the prevailing
sentiment to do additional refactoring and cleanups in 4.x there may be no
reason to port some of the changes in release-3 as they may no longer be
applicable to 4.x.


>
> A larger issue though is the attempt to stop any other proposal without
> valid reason.
>
> If community members are willing to invest their efforts to improve the
> project and provide the justification
> for the changes then those that otherwise don't participate in discussions
> or initiatives should not seek to prevent changes from happening.
>
> A project that is stuck in the past won't attract volunteers to work on it
> and users to adopt it.
>

There are different users who have adopted the project at different stages
or versions and have made investments on their side adopting the project
and as the project continues to grow the number will only increase. Changes
against the grain like these, affect them and we cannot trivialize it as
merely a few lines code change or a pom.xml change. That may be a new
development cycle for them and the associated cost. There may be
documentation they need to change for their developers. We have to listen
to community opinion and chart the best course forward.

Thanks


>
> Thomas
>
>
> On Fri, Aug 25, 2017 at 9:57 AM, Pramod Immaneni <pramod@datatorrent.com>
> wrote:
>
> > No, concerns for the changing the project name and version remain the
> same.
> > I think the current version numbering train and name are fine and prefer
> we
> > move forward and not backward by resetting things back to 1.x, which I
> > believe is not accurate for the project. The name change is unnecessary,
> > the name isn't broken that it needs to be fixed, it does not buy us much
> > and causes unnecessary disruption for people who are already used to
> > and malhar is already known out there. It is equivalent to asking for
> > apex-core to be changed to apex-engine, engine is probably a better name
> > but is it worth making the change, probably not, if it is not broke why
> fix
> > it.
> >
> > Thanks
> >
> > On Fri, Aug 25, 2017 at 9:01 AM, Vlad Rozov <vrozov@apache.org> wrote:
> >
> > > How do we move from here? If all the concerns regarding version and
> > > artifactId change are addressed we should move forward with the vote,
> if
> > > not, it will be good to raise them here rather than in the voting
> thread.
> > >
> > > Thank you,
> > >
> > > Vlad
> > >
> > >
> > > On 8/24/17 10:26, Thomas Weise wrote:
> > >
> > >> On Thu, Aug 24, 2017 at 9:42 AM, Amol Kekre <amol@datatorrent.com>
> > wrote:
> > >>
> > >> In terms of rebasing versions, there is no urgency in mimic-ing some
> of
> > >>> the
> > >>> other projects. Apex has already be been versioned.
> > >>>
> > >>
> > >> There is an expectation users have for a version number, which is
> > >> different
> > >> for 3.x or 1.x or 0.x. Apex library maturity is nowhere near 3.x. That
> > was
> > >> already discussed.
> > >>
> > >> What functional gain do
> > >>
> > >>> we have by changing versions, names? Functionality wise Apex users
do
> > not
> > >>> gain anything. With regards to bumping to 4.X, we should wait for a
> > >>> proposal/plan for a new functional api.
> > >>>
> > >>> Addition of such API does not require major version change. New API
> > have
> > >> been added and no major version change was done. Major version change
> is
> > >> for backward incompatible changes.
> > >>
> > >> Examples:
> > >> - rename packages
> > >> - remove deprecated code
> > >> - relocate operators that were not designed for production use
> > >> - change to functionality of operators
> > >>
> > >> There is an illusion of backward compatibility (which does not exist
> > >> today). That cannot be used as justification to not make changes.
> > >>
> > >>
> > >> On Wed, Aug 23, 2017 at 10:26 AM, Vlad Rozov <vrozov@apache.org>
> wrote:
> > >>>
> > >>> Please see my comments in-line.
> > >>>>
> > >>>> Thank you,
> > >>>>
> > >>>> Vlad
> > >>>>
> > >>>> On 8/23/17 09:11, Pramod Immaneni wrote:
> > >>>>
> > >>>> That is not accurate, I have mentioned and probably others as well
> > that
> > >>>>> changing the name of the project would be disruptive to users.
> Users
> > >>>>> are
> > >>>>> used to using the malhar project and its artifacts a certain
way
> and
> > >>>>>
> > >>>> this
> > >>>
> > >>>> would cause them immediate confusion followed by consternation
and
> > then
> > >>>>> changes that could extend beyond their application such as
> > >>>>> documentation
> > >>>>> etc.
> > >>>>>
> > >>>>> Changing the name is as disruptive to users as changing minor/patch
> > >>>> version. I don't see a big difference in changing one line in
> pom.xml
> > >>>> (version) vs changing 2 lines (version and artifact). There is
a
> > bigger
> > >>>> change/disruption that does IMO require major version change and
> > >>>> renaming
> > >>>> project to use the single brand (Apache Apex) at the same time
is
> > >>>> beneficial both to the project and users. Changing package and
major
> > >>>> version will impact documentation in much bigger way compared to
> > >>>> changing
> > >>>> artifactId.
> > >>>>
> > >>>> Second the project has been around for quite some time and has
> > reached a
> > >>>>> version 3.x, the second part of the proposed change is to reset
it
> > back
> > >>>>>
> > >>>> to
> > >>>
> > >>>> 1.0-SNAPSHOT. I don't think that is accurate for the project and
the
> > >>>>> maturity it would portray to the users. Not to get subjective
but
> > there
> > >>>>> are
> > >>>>> operators in malhar that are best of the breed when it comes
to
> > >>>>>
> > >>>> streaming
> > >>>
> > >>>> functionality they achieve.
> > >>>>>
> > >>>>> There are many Apache projects that were around much longer
than
> > malhar
> > >>>> and have not yet reached 3.x version even though they are also
used
> in
> > >>>> production and are considered more stable. Number of evolving
> packages
> > >>>>
> > >>> and
> > >>>
> > >>>> interfaces in malhar do not qualify it for 3.x or 4.x. IMO, version
> > must
> > >>>>
> > >>> be
> > >>>
> > >>>> driven by the engineering/community, not by the marketing.
> > >>>>
> > >>>> Third think about all the changes it would need, code, project
> > >>>>> infrastructure such as github repo and jira project, documentation,
> > >>>>> website
> > >>>>> etc and the time all the developers have to spend to adapt
to this.
> > >>>>> Wouldn't we want to spend this time doing something more
> productive.
> > >>>>>
> > >>>>> I don't think it is as drastic as it looks to be. It was done
in a
> > past
> > >>>> and is supported by all tools involved.
> > >>>>
> > >>>> I would think changing a project name and resetting the version
is a
> > big
> > >>>>> deal and should be done if there something big to gain for
the
> > project
> > >>>>>
> > >>>> by
> > >>>
> > >>>> doing this. What is the big gain we achieve to justify all this
> > >>>>> consternation? If we want to increase adoption, one of the
things
> we
> > >>>>>
> > >>>> need
> > >>>
> > >>>> to do is to provide users with a platform that behaves in an
> expected
> > >>>>>
> > >>>> and
> > >>>
> > >>>> stable manner.
> > >>>>>
> > >>>>> It will be good to provide details why is it "a big deal".
Why
> > changing
> > >>>> groupId was not a big deal and changing artifactId is a big deal?
> > >>>>
> > >>>> I completely agree with the increasing adoption, but it comes from
> the
> > >>>> quality, not from the quantity and whether version is 1.x, 3.x
or
> 4.x
> > >>>>
> > >>> does
> > >>>
> > >>>> not change the quality of the library.
> > >>>>
> > >>>> Thanks
> > >>>>>
> > >>>>>
> > >>>>> On Wed, Aug 23, 2017 at 8:09 AM Vlad Rozov <vrozov@apache.org>
> > wrote:
> > >>>>>
> > >>>>> All -1 are technically void at this point as justification
given
> are
> > >>>>> why
> > >>>>>
> > >>>>>> project may continue without modifications and not why
the
> > >>>>>> modification
> > >>>>>> must not be done. Whether we proceed with the vote or with
the
> > >>>>>> discussion, arguments should be what are pros and cons
of a code
> > >>>>>>
> > >>>>> change,
> > >>>
> > >>>> not that the project may continue without them. The same should
> apply
> > >>>>>> not only to the current set of changes, but to all future
> > discussions.
> > >>>>>>
> > >>>>>> Thank you,
> > >>>>>>
> > >>>>>> Vlad
> > >>>>>>
> > >>>>>> On 8/23/17 06:54, Thomas Weise wrote:
> > >>>>>>
> > >>>>>> The discussion already took place [1]. There are two options
under
> > >>>>>>>
> > >>>>>> vote
> > >>>
> > >>>> out
> > >>>>>>
> > >>>>>> of that discussion and for the first option there is a
single -1.
> > Use
> > >>>>>>>
> > >>>>>> of
> > >>>
> > >>>> -1
> > >>>>>>
> > >>>>>> during voting (and veto on PR) when not showing up during
the
> > >>>>>>>
> > >>>>>> preceding
> > >>>
> > >>>> discussion is problematic.
> > >>>>>>>
> > >>>>>>> Thomas
> > >>>>>>>
> > >>>>>>> [1] https://lists.apache.org/thread.html/
> > >>>>>>>
> > >>>>>> bd1db8a2d01e23b0c0ab98a785f6ee
> > >>>
> > >>>> 9492a1ac9e52d422568a46e5f3@%3Cdev.apex.apache.org%3E
> > >>>>>>>
> > >>>>>>> On Wed, Aug 23, 2017 at 1:58 AM, Justin Mclean <
> > >>>>>>> justin@classsoftware.com
> > >>>>>>>
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>> Hi,
> > >>>>>>>
> > >>>>>>>> Votes are only valid on code modifications with
a reason. [1]
> > >>>>>>>>
> > >>>>>>>> However it looks to me that there’s not consensus
and which way
> > >>>>>>>>
> > >>>>>>> forward
> > >>>
> > >>>> is
> > >>>>>>> best I would suggest cancelling the vote and having
a discussion
> of
> > >>>>>>>
> > >>>>>> the
> > >>>
> > >>>> benefit or not of making the change.
> > >>>>>>>>
> > >>>>>>>> Thanks,
> > >>>>>>>> Justin
> > >>>>>>>>
> > >>>>>>>> 1. https://www.apache.org/foundation/voting.html
> > >>>>>>>>
> > >>>>>>>> Thank you,
> > >>>>>>
> > >>>>>> Vlad
> > >>>>>>
> > >>>>>>
> > >>>>>> Thank you,
> > >>>>
> > >>>> Vlad
> > >>>>
> > >>>>
> > >
> > > Thank you,
> > >
> > > Vlad
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message