Open for feedback/comments until tomorrow (due for submission today):
https://docs.google.com/document/d/1TKHKI_4htvoIHYu4S7q5HuaX-2eUuW-d5pQUtsWTrBs/edit?usp=sharing
Thomas,
I would be happy to help...with the caveat that I don’t know the code are very
well at all...any pointers would be much appreciated.
Sent from my iPhone
> On Jan 9, 2019, at 22:23, Thomas Weise wrote:
>
> Quite satisfying to see this spike of mailing list activity! Didn't expect
>
Snapshot dependency in third-party repo is a bit problematic as we had seen
last year ;-)
But I would not consider it a blocker as long as the licensing is clear.
On Wed, Jan 9, 2019 at 6:40 PM Pramod Immaneni
wrote:
> It would likely be easier to adapt to such an API change than
>
Quite satisfying to see this spike of mailing list activity! Didn't expect
we still had so many subscribers and "attic" seems to be a strong keyword :)
Aaron, thanks for refreshing my memory! I'm also not aware of any other
project supporting on the fly topology changes. It's a capability that
In regards to your second question, I think our capability to make releases
when necessary such as responding to CVEs hasn't diminished. Most of the
folks who cut the releases, worked on CVEs and members of the security
group in the past are still participating in the group discussions and can
It would likely be easier to adapt to such an API change than
developing/co-opting the protocol code, which would be throwaway work once
there is a release anyway. Would be better to just manage with snapshot
till there is a release. Or we could wait till there is a release. I can
check with the
From the perspective of a person experimenting with Apex coming from a
background with Storm as the existing solution, Thomas’ comment is particularly
relevant: there are significant barriers to entry that make Apex appealing on
the surface, but very challenging to implement or port an
It is not only hosting on Apache or Maven Central that worries me. It is also a
snapshot version. My experience with hosting artifacts on maven servers that
are not mirrored by Maven central and a dependency on a snapshot version are
equally bad and both usually lead to broken builds.
While
Sanjay,
I don’t see a need to be positive or negative. The community is not a baby and
does not need positive (or negative) encouragement. It needs facts and the fact
is that there were no contributions to the project for the last 6 month and the
project is on the way to the attic.
I am also
Without 3 active PMC members it would be the board decision to move the project
to the attic, fortunately it is not yet at this state. At the same time I don’t
think that it is good to pretend that the project is alive without
contributions.
The rebranding is required only if an enterprise, a
IMHO, the bare minimum for “survivability” as an ASF project is 3 Active PMC
members (to make project decisions) and enough of an active community to make
releases when necessary (e.g. Respond to CVEs, etc.).
Given the responses to this thread, I believe the project has the former. The
Vlad,
Not too worried about the dependency as the gating factor, it can always be
hosted on some maven server. Importantly it is developed by salesforce
folks who will handle the specifics, which will allow portability in case
the protocol evolves. It also handles the sf replay protocol,
Vlad,
Thanks for the clarification. So the threat of shutting down the project
(aka moving to attic) as a way to energize the community. One way to do it
and I guess works in many cases...
We should also look into more positive ways of encouraging participation
and contribution. Hopefully it's
Pramod,
Did you consider using CometD library directly? epm-connector is a thin layer
on top of CometD and skipping it will allow you at least to resolve dependency
on a snapshot version.
Thank you,
Vlad
> On Jan 9, 2019, at 14:52, Thomas Weise wrote:
>
> Thanks for the actionable input.
Thanks for the actionable input.
I would suggest you try to contribute back. From my end I'm happy to
support that as reviewer or in advisory capacity.
If multiple folks maintaining private forks were to contribute back, the
cost equation was more attractive (you benefit from other contributions
We have a couple of operators notably a salesforce operator that I am
trying to get the necessary permissions at work to contribute. The
underlying salesforce client library (emp-connector) used by the operator
doesn't have a release yet so that is another reason slowing things down,
waiting to
Hi Sanjay, long time, no see.
This is my attempt to mobilize the community and see if we can revive some
activity on the project. Note that the same discussion happened among PMCs
members 2 month ago and there were promises to contribute back to the project
with no new PRs being open. Should
Hi Vlad
I have been watching this debate from the sidelines and just decided to
jump in.
As an Apex PMC member you said "... I am responsible for maintaining the
correct state of the project...". But let's face it, you don't actually
have to do it just like you didn't have to make contributions,
Amol,
Without details who decided to stay away and why it is not very constructive
and does not tell me whether I should continue or not. Again, I’d like to see
what policies needs to be changed that will bring more contributions and won’t
affect quality of the code. If you have a concrete
I believe that the best way forward at this moment is to identify a small
set of features that we can ship in near future with our limited set of
contributors/committers. I also suggest that we allow committers to take
ownership of some component for the time being and focus on getting a
feature
Vlad,
Would you want to continue to be involved in the project, even if this
involvement is itself causing community folks to stay away? If the issue is
cultural, things will not improve. Doing the same thing again and expecting
different result will not work. Why not change the policies that
Agree, we need *concrete* answers to all those questions to avoid the project
to be moved to the attic.
Thank you,
Vlad
> On Jan 9, 2019, at 09:35, Thomas Weise wrote:
>
> I think it would be constructive to find answers to relevant questions that
> came up:
>
> * Who is going to contribute
I think it would be constructive to find answers to relevant questions that
came up:
* Who is going to contribute to the project?
* Is there code in private forks that can be contributed?
* What is the estimated timeline for such contributions?
* Are there any other opportunities to
Remember that to vote -1 it is necessary to provide justification, so I’d like
to see the justifications and the plan from those who do not want to move Apex
to the attic. I am also not very happy that my past efforts will be placed in
the attic, but let’s face the reality. It is not that I
What would be the purpose of such a vote? From the discussions it is quite
apparent that there is a significant, possibly majority view that project
shouldn’t go to attic. The same could be reported to the board, can’t it?
Like I also said if you or others don’t like where the project is at and
Without concrete details of what will be committed (support for k8s, hadoop
3.x, kafka 2.x, etc) and what requirements in code submission needs to be
relaxed (well written java code, consistent code style, successful build with
passing unit tests in CI, providing unit test, etc) the statements
I do believe and know of some work done in private forks by people. There
could be couple of reasons why it didn't go public. One could be high bar
for code submission (I don't have references at hand but that's general
feeling amongst committers) and other could be lack of motivation.
Let's try
27 matches
Mail list logo
