As you know, originally there were essentially 2 different options for us
during this incubation when dealing with the existing codebase:
1) Get the code donated, granted, however you want to call it.
Unfortunately nobody could be found to even decide on this issue for all
sorts of reasons that are
Hi,
> Understood. I'll remove the code. It's probably better to use a parser
> library from a project like Apache Calcite anyway.
I think you may have misunderstood. Sure removing the code is one option, bull
all code from that repo would need to be removed not just that one file. My
understand
Understood. I'll remove the code. It's probably better to use a parser
library from a project like Apache Calcite anyway.
On Mon, Jun 14, 2021 at 10:09 AM Justin Mclean
wrote:
> Hi,
>
> > The Simple SQL Parser that was included recently and where we had the one
> > file with incorrect header was
Hi,
> The Simple SQL Parser that was included recently and where we had the one
> file with incorrect header was included for completeness sake but it was
> the notable exception I think. But even that code needed refactoring,
> cleanup and actually quite a bit of work to port over.
Even if som
Just a final note on the "foreign code" problem. It's literally impossible
to now simply include anything from the original source code. The codebase
and API of Apace Hop have drifted so far away from where we once were that
for new feature requests (like for example the recent addition of Parque
Hello Team,
The vote to release Apache Hop (incubating) 0.99 - RC1 has failed.
Although we have sufficient votes to create a release, the issues raised
were too big to feel comfortable releasing the code. We would like to thank
everyone participating in this vote.
+1 (binding):
- Julian Hyde
-
Hi,
The vote has ended, thank you all for the feedback.
As you pointed out, were it only the header issue in hpl/hwf it would have
been an option, the foreign code is a bigger problem.
I will go back to the dev list to discuss creating rc2.
Cheers,
Hans
On Mon, 14 Jun 2021 at 02:02, Justin Mcle
Hi,
I suggest you discuss this with you mentors and together come up with the best
approach.
There's a higher bar for release without the work in progress disclaimer. I had
noticed the issue in a previous release but I didn’t say anything about it on
the assumption that it wold be corrected o
For me I think it's been too frustrating because of a lack of vacation and
the whole pandemic, more than the technical issues.
In the end, this is not that big of a deal I think:
1) add an option through an environment variable like
HOP_LICENSE_HEADER_FILE
2) create a file with the ASF header in it
Hi,
What I don't get about this whole discussion is that we already had 169 hpl
and hwf files in the 0.70 release, and these files weren't even mentioned
in the reviews.
Now that we have about 400 hpl/hwf files in the 0.99 release, this
is/becomes an issue.
I'm sure we'll sort this out, but if thi
After thinking about it some more I really believe strongly that our
developers should have an easy time adding more integration tests. It's
really critical to our project in the longer term.
Manually editing XML files to copy/paste an ASF header in there can not be
part of that experience. It's
Hi,
What Matt was pointing at is to include a (or , but
let's forget about that for now) element in the XML documents that the hpl
and hwf files are.
We could do this by including an option in Hop Gui (our visual IDE that
generates the hpl and hwf files) to include the ASF header for the
integra
Hi,
I'm a little confused, and I may be missing some context here. If the work a
part of an ASF project, why do you need to include a copyright statements
anywhere? If the code is not part of the project then we do need to know the
license and copyright owner. While this might be a good place t
Let's set the past aside for a moment. The last thing I want is to make
this in any way personal. I have nothing but appreciation for everything
you've all done for our project.
So what this comes down to is that we need to engineer our way out of the
fact that Hop pipeline and workflow files (.
Hi,
> That specific unit test can be found here [1]
Thanks for that. I assume the other files there [1] were moved and their
headers changed?
Kind Regards,
Justin
1.
https://github.com/pentaho/pdi-dataservice-plugin/tree/master/pdi-dataservice-client/src/test/java/org/pentaho/di/core/sql
Hi,
That specific unit test can be found here [1], but we will strip out
everything to move forward.
Kind regards,
Hans
[1]
https://github.com/pentaho/pdi-dataservice-plugin/blob/master/pdi-dataservice-client/src/test/java/org/pentaho/di/core/sql/SQLFieldsUnitTest.java
On Sat, 12 Jun 2021 at 11
Hi,
Thanks for the information.
> There are more files that have altered headers (though all with apache 2.0
> license) and are adapted from the following repository [1],
That is unfortunate, both in changing the headers and that code doesn't have a
clear license. 3rd party headers, even if the
Hi Justin,
There are more files that have altered headers (though all with apache 2.0
license) and are adapted from the following repository [1], bits and pieces
were used and adapted to our needs, this repository is a module that was
bundled with the original source we started from it has no sepa
Hi,’
Perhaps this will help: A software grant / initial donation consists of a set
of files, their 3rd party headers will be replaced with ASF ones and that noted
in the NOTICE file. If any other files 3rd party files, were then copied into
the same ASF repo they should retain their original 3r
Hi,
> Well Justin, these files are typically generated by our software. It would
> not be OK to force the license into all files since that wouldn't be
> appropriate and right since we don't force Apache copyright on the work of
> others.
The ASF header doesn’t include a copyright line and the A
Hi,
> It wasn't part of the software grant so we were just following the bundling
> apache licensed 2.0 code route as explained here [1].
See [1] "However, for completeness it is useful to list the products and their
versions, as is done for products under other licenses.” Common practice is
th
Hi Justin,
It wasn't part of the software grant so we were just following the bundling
apache licensed 2.0 code route as explained here [1].
No addition to the LICENSE was needed as the code already was Apache 2
licensed. As the necessary mentions already are in our notice file, no
change was need
Well Justin, these files are typically generated by our software. It would
not be OK to force the license into all files since that wouldn't be
appropriate and right since we don't force Apache copyright on the work of
others. Without that possibility we're down to manually editing the files
ever
Hi,
> We see integration tests as an even more important and integral part of the
> source code compared to unit tests since they offer so much more value in
> ensuring that functionality and compatibility remain the same when we push
> our software forward.
So in that case they should have ASF
HI,
> That file should be switched to the standard ASF header and is part of the
> original code and covered by the notice file.
Except it wasn’t in the previous release and I assume wasn’t part of the
original software grant.
Thanks,
Justin
--
We see integration tests as an even more important and integral part of the
source code compared to unit tests since they offer so much more value in
ensuring that functionality and compatibility remain the same when we push
our software forward. It gives us the freedom to continue progressing in
Hi Justin,
That file should be switched to the standard ASF header and is part of the
original code and covered by the notice file.
As for the no header in hpl and hwf files, these are files created using
the application and are used for samples and for our integration testing
framework. This fra
Hi,
-1 (binding)
This 3rd party file [1] is not mentioned in LICENSE. While this is just one
file my concern is that that this may indicate a bigger issue where headers of
3rd party files have been changed.
I checked:
- incubating in name
- signatures and hash are fine
- LICENSE is missing a m
Forwarding my PPMC vote
+1 (binding)
Good job to all the Hop team!
regards,
François
fpa...@apache.org
Le 09/06/2021 à 10:47, Hans Van Akelyen a écrit :
> Hi All,
>
> This will be our preview 1.0 release, this release contains both the source
> code and binary to run the client. This will also
+1 ( binding )
I checked the following.
- Incubating in name.
- PGP Signatures.
- SHA512 Checksums.
- DISCLAIMER exists.
- LICENSE and NOTICE are fine.
- Maven Build passes on MacOS. ( Maven - 3.6.3 JAVA - AdoptOpenJDK Java
1.8.0_252 ).
Regards
Kevin
On Thu, Jun 10, 2021 at 11:20 PM Jul
Forwarding my vote from the PPMC poll:
+1 (binding)
On Wed, Jun 9, 2021 at 5:54 AM Xun Liu wrote:
>
> +1 (non-binding) from me, I have checked the following items:
>
> - Incubating in name
> - NOTICE is fine
> - DISCLAIMER exists
> - All links are valid
> - No unexpected binary files
> - All ASF
+1 (non-binding) from me, I have checked the following items:
- Incubating in name
- NOTICE is fine
- DISCLAIMER exists
- All links are valid
- No unexpected binary files
- All ASF files have ASF headers
Best regards
Xun Liu
On Wed, Jun 9, 2021 at 4:47 PM Hans Van Akelyen
wrote:
> Hi All,
>
>
Hi All,
This will be our preview 1.0 release, this release contains both the source
code and binary to run the client. This will also be our first release
without DISCLAIMER-WIP but the regular disclaimer.
This release aims to get as much feedback as possible so we can remove some
final bugs befo
33 matches
Mail list logo
