Re: [discuss]Release MiNiFi-CPP 0.8.0

2020-07-16 Thread Adam Hunyadi

Hi,

Reflecting to an ongoing chat conversation about intermediate releases:
I agree with not rushing 1.0, but having multiple releases with big API 
changes after 0.8 would be probably difficult for the user base to adopt 
to.


A problematic example:
- We make a decision on which namespace a particular component belongs 
to and change it for a version 0.9
- We decide to change this again for fixing up the public API with a 
deadline of 1.0


This would effectively mean that the end users would potentially need to 
change their codebase to adopt to us getting ready for 1.0.


I propose us agreeing only on having a robust v1.0 and plan no 
intermediate release unless we clearly see its necessity.


Cheers,
Adam

On 2020. 07. 15. 19:30, Joe Witt wrote:

"To allow the
community some time to finalize the API, I would not rush 1.0 right after
0.8, unless we see that the API is stable and something we can commit to."

+1 to that

On Wed, Jul 15, 2020 at 10:28 AM Marton Szasz  wrote:


Hi,

+1. There are countless fixes and stability improvements on the main
development branch that would benefit the majority of users.

Breaking changes: there are some minor API breakages compared to 0.7, but
there was an effort to avoid breaking core APIs and the configuration
syntax.

I agree with Marc that we should allow ourselves more freedom to fix issues
even at the cost of breaking APIs, especially before 1.0. To allow the
community some time to finalize the API, I would not rush 1.0 right after
0.8, unless we see that the API is stable and something we can commit to.

Thanks, regards,
Marton

On Wed, 15 Jul 2020 at 17:36, Marc Parisi  wrote:


+1 to 0.8.0. Been keeping up with changes and I think the progress is
great.

In my opinion the breaking changes are long coming and probably would be
appreciated by the community.

Arpad are you thinking of going to 1.x? You're discussing 0.8, but is

there

any reason to not jump to 1.x after that?

Thanks,
Marc

On Wed, Jul 15, 2020 at 10:12 AM Joe Witt  wrote:


Arpad

Yep makes sense. Frankly the 0. versioning gives the flexibility to do
these breaking changes during this stage of the lifecycle.

Thanks

On Wed, Jul 15, 2020 at 7:06 AM Arpad Boda  wrote:


Hey,

Quite a lot of time has passed since the last release and also a lot

of

improvements and bug fixes have been made (Memleaks fixed, new

threadpool,

some new processors, etc), so I think it's time for a new release.

Another important aspect would be the release of the current state of

the

source before introducing some breaking changes - which seems to be
necessary at this point.

What do you think?

Thanks, regards,
Arpad



Re: [DISCUSS] rename master branch, look through code for other related issues

2020-06-18 Thread Adam Hunyadi



I propose naming the master branch Voldemort, so that people do not 
speak of its name. Of course this recommendation only applies if noone 
finds choosing the name of a "dark" lord offensive.




Adam Hunyadi

On 2020. 06. 18. 12:17, u...@moosheimer.com wrote:

Language is always changing and the meaning of words is changing,
sometimes positively and sometimes negatively.
I think that now is time for change again and we should discuss the use
of phrases and meanings.

Of course we should change "Master Branch" to "Main Branch".
But I also think that we shouldn't just make quick changes because it's
opportune and hastily change a few words.

An example: We could change Master/Slave to Leader/Follower. This may be
a perfect choice for most people in the world.
In German Leader is the English word for "Führer". And it is precisely
this word that we in Germany do not actually want to use for it.

What I mean is that every country and every group (e.g. religion etc.)
has its own history and certain words or phrases are just not a perfect
choice.
We should try to go the ethically correct way worldwide.

This concerns the adaptation of current words and phrases with a view to
all: in English, Indian, Chinese, German etc. but also for indigenous
peoples, different religions etc.
And cultural differences should also be taken into account.

What I would wish for:
Apache.org should set up an "Ethics Board". A group of people of
different genders, all colors, religions and from different countries
and cultures all over our world.
This Ethics Board should find good and for no one discriminating words
or phrases for all the areas that stand out today as offensive.

And it would be nice if not only computer scientists participated, but
also ethicists, philosophers, engineers, various religious people,
chemists, biologists, physicists, sociologists, etc.

And this Council should set binding targets for all projects.

Am 18.06.2020 um 09:36 schrieb Pierre Villard:

In my perspective this should be an issue for the entire community. Being
able to identify an issue that directly affects another person but not
one’s self is the definition of privilege. If I can look at how the use of
these words in someone’s daily life or career impacts them negatively,

when

the change would not harm me at all, I see that as a failure on my part. I
understand the desire to hear from the silent majority, but active
participation and discussion on the mailing list is the exact measure
described by the Apache process for participation in the community. Those
who speak here are the ones who will have a voice.

I could not agree more with the above.

Le jeu. 18 juin 2020 à 04:29, Tony Kurc  a écrit :


I suppose I was a bit remiss in not unwinding and/or summarizing some of
what was in that yetus thread to prime the discussion, but a some of what
Andy is mentioning is expanded on a bit in this ietf document [1], which is
linked in one of the articles.

1. https://tools.ietf.org/id/draft-knodel-terminology-00.html


On Wed, Jun 17, 2020, 10:02 PM Andy LoPresto  wrote:


Hi Edward, thanks for sharing your thoughts. I’ll reply inline.


- Some of the terms proposed are not industry standard and may

potentially

cause significant issue for non-english speakers.

I actually believe making these changes will _improve_ the clarity for
non-english speakers. “Whitelist” and “blacklist” confer no inherent

reason

to mean allow and deny other than connotative biases. “Allow” and “deny”
explicitly indicate the verb that is happening. Another example is branch
naming. “Masters” don’t have “branches”. “Trunks” do. These terms make
_more_ sense for a non-English speaker than the current terms.


- For each change that is made can we guarantee that we will not lose
clarity of meaning, and then have revert the change down the line if

the

change causes a drop in usage.

I don’t expect the community will opt to change the new terms back to

ones

with negative connotations in the future. If there is discussion about

it,

this thread will provide good historical context for why the decision was
made to change it, just as the mailing list discussions do for other code
changes.


- Of what percentage of people is this truly an issue for and what
percentage isn't. Any change that has the potential to cause a major

split

in the community, there must be as close as possible to a majority, and

not

just from those that are vocal and active on the mailing lists.
Disscustions on other groups are turning toxic, and in some cases are
potentially leading to the collapse of these projects where these

changes

are being implemented with what appears to be without the agreement of

a

signifficant chunk of the community.


In my perspective this should be an issue for the entire community. Being
able to identify an issue that directly affects another person but not
one’s self is the definition of privilege. If I can

Re: Potential Problems on Discarding Return Values

2020-06-10 Thread Adam Hunyadi

Hi,

Sorry, I did not realize, that this confluence page might not be 
available for some devs.


Attached the content as pdf.

Thanks,
Adam

On 2020. 06. 10. 12:11, Adam Hunyadi wrote:


Hi,

Upon checking some behaviours in NiFi with Tamas Palfy, we have found 
that function signatures like this can be a frequent source of error:


|public FlowFile penalize(FlowFile flowFile) { ... }|

I documented the issue here:

https://cloudera.atlassian.net/wiki/spaces/ENG/pages/610534373/Discarding+Return+Values+in+NiFi

It would be nice if a Java dev with some spare time could look more 
into the issue and share their findings.


Cheers,
Adam



Potential Problems on Discarding Return Values

2020-06-10 Thread Adam Hunyadi

Hi,

Upon checking some behaviours in NiFi with Tamas Palfy, we have found 
that function signatures like this can be a frequent source of error:


|public FlowFile penalize(FlowFile flowFile) { ... }|

I documented the issue here:

https://cloudera.atlassian.net/wiki/spaces/ENG/pages/610534373/Discarding+Return+Values+in+NiFi

It would be nice if a Java dev with some spare time could look more into 
the issue and share their findings.


Cheers,
Adam