Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3

[tison]

Hi Justin,

Thank you, and that's not in a hurry. I'd just like to make the status
clear and ensure we can make progress instead of subjective arguing.

Now I know you use ScanOSS and I'd suggest other members in Fury try to
check the project with this tool. I'll try it out if I find some time, and
I'd appreciate it if you could share how you use this tool to do compliance
checks, it would help all the people in the Incubator :D

::OT:: IIRC ScanOSS CEO or CTO gave a talk at the Dev.Together Conf weeks
before, now I found a real use case XD.

Best,
tison.


Justin Mclean  于2024年4月25日周四 13:40写道：

> HI,
>
> I’m happy to share it, but as I said, I'm travelling right now and don't
> have access. I used ScanOSS workbench, but there are other checkers out
> there. And yes, tools like this can sometimes give false positives, and it
> can sometimes be unclear where things were originally copied or, in fact,
> may have been copied themselves.
>
> Kind Regards,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Drop the incubator- prefix for podling's GitHub repo

[Justin Mclean]

Hi,

> 4. To clarify that a repo belongs to a podling, introduce a guideline or
> policy to help PPMCs include the DISCLAIMER in the README of all their
> repos.

Alternatively, perhaps we can come up with something a little shorter shorter 
that points to DISCLAIMER? What is important is that the project is clearly 
understood to be an incubating p[project and what that means, rather than the 
exact wording.

Kind Regards,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3

[Justin Mclean]

HI,

I’m happy to share it, but as I said, I'm travelling right now and don't have 
access. I used ScanOSS workbench, but there are other checkers out there. And 
yes, tools like this can sometimes give false positives, and it can sometimes 
be unclear where things were originally copied or, in fact, may have been 
copied themselves.

Kind Regards,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Improve the website of StreamPark

[tison]

Hi,

Recently I made two patches to improve the content of StreamPark website:

* https://github.com/apache/incubator-streampark-website/pull/347
* https://github.com/apache/incubator-streampark-website/pull/349

They should showcase several common mistakes and less-than-awesome we can
improve:

1. Reduce the number of long and difficult sentences. Break them down into
several simple sentences.
2. Reduce the number of marks (code block, bold content) unless it's
necessary. Otherwise the rendered version is super hard to read.
3. Use correct reference to projects, including HBase rather than Hbase,
ClickHouse rather than Clickhouse, and try to name Apache Project in the
form Apache Foo as much as possible.
4. For Chinese content, please follow [1] to ensure that whitespace and
punctuation are used properly.

[1] https://github.com/sparanoid/chinese-copywriting-guidelines

The website has too many pages for one person to handle, but we have no
more than a few dozen pages to revise. I suppose that with more eyes on all
the pages, we can improve the website to a competitive level from the
product perspective and a good state from the compliance perspective.

cc general@incubator.a.o, as I have always learned a lot from many IPMC
members. This is neither order nor outsourcing, but if anyone has time and
energy as I do to help a podling, we can cooperate and make contributions
together :D

Best,
tison.

Re: [DISCUSS] Drop the incubator- prefix for podling's GitHub repo

[tison]

> For Go based projects dropping the incubator reference in the git repo
makes things easier also when graduating

I support this statement. For Java or Rust release, we generally don't
include the incubator prefix in dep ID. But Golang dependency relies on the
name of the GitHub repository. So it can often be:

* github.com/apache/incubator-xxx/yyy

While redirections can work, IIRC INFRA members sometimes rename before
repo transfer and thus apache/xxx won't have the redirection to
apache/incubator-xxx then.

> I would be for requiring the incubator disclaimer text in the project's
README:

This sounds reasonable. No matter if we drop the incubator- prefix, as [1]
wrote:

> Podling web sites MUST include a clear disclaimer on their website and in
all documentation (including releases) stating that they are in incubation.

The README is somehow documentation.

[1] https://incubator.apache.org/guides/branding.html#disclaimers

Then I'm going to start a vote in the next week on a bunch of the following
resolutions:

1. Establish a consensus to allow podling's GitHub repo to have a name
without incubator- prefix.
2. Allow other podlings to ask the INFRA to drop their incubator- prefix by
now, not MUST during the graduation.
3. Update the docs on incubator.apache.org everywhere if the description
can conflict with this consensus.
4. To clarify that a repo belongs to a podling, introduce a guideline or
policy to help PPMCs include the DISCLAIMER in the README of all their
repos.

I volunteer to go through the Incubator website and update content
accordingly if these resolutions are made.

To IPMC members: I plan to start a vote in general@incubator.a.o. Do we
have other places to record resolutions proposed and concluded?

Best,
tison.


Justin Mclean  于2024年4月25日周四 10:46写道：

> Hi,
>
> I would be for requiring the incubator disclaimer text in the project's
> README:
> "Apache FOO is an effort undergoing incubation at The Apache Software
> Foundation (ASF), sponsored by the Apache Incubator. Incubation is required
> of all newly accepted projects until a further review indicates that the
> infrastructure, communications, and decision making process have stabilized
> in a manner consistent with other successful ASF projects. While incubation
> status is not necessarily a reflection of the completeness or stability of
> the code, it does indicate that the project has yet to be fully endorsed by
> the ASF.”
>
> Kind Regards,
> Justin
>
> > On 24 Apr 2024, at 9:48 pm, tison  wrote:
> >
> > Thanks for your participation!
> >
> > For people who support drop the incubator- prefix, please describe you
> > opinion on:
> >
> >> 3. It's still significant to make it clear that a podling is in the
> > incubating status and thus a DISCLAIMER to protect the ASF branding.
> >> I'd propose to add the "incubating" words to each repo's README. This
> can
> > be regarded as treating those READMEs a homepage for the repo and,
> >>
> >> 1. Name the project as "Apache Foo (Incubating)" in its first and most
> > prominent uses, hopefully and H1 heading.
> >> 2. Add a footer including the Incubator logo and DISCLAIMER, like the
> > current footer of Apache Answer (Incubating) [3]
> >> [3] https://answer.apache.org/
> >
> > Be sure that you know we don't barely drop the prefix, but we need a
> formal
> > way to "make it clear that a podling's repo is in the incubating status",
> > which can be achieved currently by  its prefix.
> >
> > Best,
> > tison.
> >
> >
> > Wilfred Spiegelenburg  于2024年4月23日周二 13:12写道：
> >
> >> For Go based projects dropping the incubator reference in the git repo
> >> makes things easier also when graduating. Packages and dependencies are
> >> referenced based on the repository name. Renaming the repository either
> >> requires changes throughout the code base to remove the incubator
> reference
> >> or the packages will always have the incubator reference in them.
> >>
> >> Wilfred
> >>
> >> On 2024/04/23 01:22:02 tison wrote:
> >>> Hi,
> >>>
> >>> Recently, the new added podlings, namely Amoro and Hertzbeat, have
> their
> >>> GitHub repo in the names:
> >>>
> >>> * https://github.com/apache/amoro
> >>> * https://github.com/apache/hertzbeat
> >>>
> >>> ... which is different to the other 20+ podlings and 200+ repos [1]
> >>> existing (this number counts retired ones and those for the Incubator
> PMC
> >>> itself, but it's approximate).
> >>>
> >>> [1]
> >>>
> >>
> https://github.com/orgs/apache/repositories?language==incubator-==all
> >>>
> >>> My opinion is to agree that generally:
> >>>
> >>> 1. The incubator prefix comes from the SVN days where all podlings were
> >> under
> >>> the incubator SVN tree.
> >>> 2. Dropping the incubator- prefix for podling's GitHub repo can reduce
> >> some
> >>> graduation tasks (although it's somewhat a milestone and ceremony for
> the
> >>> podling, and INFRA does not find it a large job, as well as it won't
> >> break
> >>> downstream almost due to redirections).
> >>> 3. 

Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3

[tison]

> Of course we'd like to add the license info

As you can see, for files we're clear that is derived, we keep their
license headers, and add a link to the origin.

[1]
https://github.com/apache/incubator-fury/blob/dd9f9128d24b418f6a420880c7780ce83d6448a2/licenserc.toml#L28-L54

So what I'm confused about is that you don't want to share how you find the
files questioned are copied and what the origins are.

Of course, if the authors copied it, we would have the answer. But now,
that's not the case. So I ask you to share the evidence you have to support
that [1][2][3][4] is copied. You reply, "It certainly looks like some code
was copied; one file, for instance, is about 70% the same," but you still
wouldn't like to share the reason or name the file and its "origin".

It can be quite easy to proceed that:

[1] is the same as link-A
[2] is the same as link-B
[3] is the same as link-C
[4] is the same as link-D

and we check the content and re-confirm with the author.

Best,
tison.


tison  于2024年4月25日周四 10:50写道：

> > That should be fine, but having an ASF header on the files may be a
> little misleading? What do you think?
>
> Could you elaborate a bit on "misleading"? Shawn owned the code and he
> contributed the code under Apache License 2.0, and also he has filed an
> iCLA. So it follows the headers write:
>
>  Licensed to the Apache Software Foundation (ASF) under one
>  or more contributor license agreements.  See the NOTICE file
>  distributed with this work for additional information
>  regarding copyright ownership.  The ASF licenses this file
>  to you under the Apache License, Version 2.0 (the
>  "License"); you may not use this file except in compliance
>  with the License.  You may obtain a copy of the License at
>
>http://www.apache.org/licenses/LICENSE-2.0
>
>  Unless required by applicable law or agreed to in writing,
>  software distributed under the License is distributed on an
>  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
>  KIND, either express or implied.  See the License for the
>  specific language governing permissions and limitations
>  under the License.
>
> > Licensed to the Apache Software Foundation (ASF) under one or more
> contributor license agreements.
>
> Best,
> tison.
>
>
> tison  于2024年4月25日周四 10:47写道：
>
>> > It certainly looks like some code was copied; one file, for instance,
>> is about 70% the same. This is not an issue as it is under a compatible MIT
>> license, but that needs to be mentioned in the LICENSE file.
>>
>> Could you please tell the file name and the file on OpenSumi that is
>> overlapped? Of course we'd like to add the license info if it's the case,
>> and actually I'd generally add a link to the original file. Now we cannot
>> find the origin and the author states that they write the code by
>> themselves.
>>
>> You state that there is 70% the same, as what? It's quite confusing to
>> give such a conclusion without certain reference.
>>
>> > A possible explanation for what has happened here is that the developer
>> used AI to generate the code, and it’s duplicated that code from somewhere.
>> Do you know if that is the case?
>>
>> If you have a tool to check such similarity, could you share it or share
>> the report. When you state a file is copied from elsewhere, there must be
>> an origin. AFAIK we don't use AI to generate this code, if you take a look
>> at the code (please look), the content is:
>>
>> public static class ArrayAsList extends AbstractList implements
>> RandomAccess, java.io.Serializable {
>> private static final Object[] EMPTY = new Object[0];
>> private Object[] array;
>> private int size;
>> public ArrayAsList(int size) { array = new Object[size]; }
>> @Override public int size() { return size; }
>> @Override public boolean add(Object e) { array[size++] = e; return
>> true; }
>> @Override public Object get(int index) { return array[index]; }
>> public void clearArray() { size = 0; array = EMPTY; }
>> public void setArray(Object[] a) { array = a; size = a.length; }
>> public Object[] getArray() { return array; }
>> @Override public Object set(int index, Object element) { throw new
>> UnsupportedOperationException(); }
>> @Override public int indexOf(Object o) { throw new
>> UnsupportedOperationException(); }
>> @Override public boolean contains(Object o) { throw new
>> UnsupportedOperationException(); }
>> @Override public Object[] toArray() { return array; }
>> @Override public Iterator iterator() { return new
>> Iterator() {
>> private int index;
>> @Override public boolean hasNext() { return index < array.length;
>> }
>> @Override public Object next() { return array[index++]; }
>>   };
>> }
>>   }
>>
>> Getters, trivial add / clear / set, three unsupported methods. The fields
>> and non-inherited methods are also written originally.
>>
>> Best,
>> tison.
>>
>>
>> Justin Mclean  于2024年4月25日周四 10:36写道：
>>
>>> Hi,
>>>
>>> I’m 

Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3

[Calvin Kirs]

On Thu, Apr 25, 2024 at 10:36 AM Justin Mclean 
wrote:

> Hi,
>
> I’m currently travelling and may be slow in responding to emails.
>
> > The MemoryBufferWritableChannel[5] and  MockWritableChannel[6] was
> written
> > by me before we open-sourced Fury and
> > I submitted it to Ray in PR[8] ,which was planned to optimize zero-copy
> > serialization in Ray. I think it's OK to include it
> > here since both are written by me.
>
> That should be fine, but having an ASF header on the files may be a little
> misleading? What do you think?
>
As the original author of the code, you typically retain the original
copyright to the code. You've simply granted Ray the right to use,
distribute, and so on, so adding an Apache header is generally not a
problem.

>
> > For files [1][2][3][4], could you give more details how those files
> include
> > code from OpenSumi. The OpenSumi core developer
> > bytemain[9] does commit some code to Fury, see his commits[10]. But I
> > talked to him offline, he said he didn't copy code from
> > OpenSumi.
>
> It certainly looks like some code was copied; one file, for instance, is
> about 70% the same. This is not an issue as it is under a compatible MIT
> license, but that needs to be mentioned in the LICENSE file.
>
> > For Fury ArrayAsList, could you give more details how this class is
> copied
> > from somewhere? It's just a simple wrapper for java
> > object arrays.
>
> A possible explanation for what has happened here is that the developer
> used AI to generate the code, and it’s duplicated that code from somewhere.
> Do you know if that is the case?
>
> Kind Regards,
> Justin
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

-- 
Best wishes！
CalvinKirs

Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3

[tison]

> That should be fine, but having an ASF header on the files may be a
little misleading? What do you think?

Could you elaborate a bit on "misleading"? Shawn owned the code and he
contributed the code under Apache License 2.0, and also he has filed an
iCLA. So it follows the headers write:

 Licensed to the Apache Software Foundation (ASF) under one
 or more contributor license agreements.  See the NOTICE file
 distributed with this work for additional information
 regarding copyright ownership.  The ASF licenses this file
 to you under the Apache License, Version 2.0 (the
 "License"); you may not use this file except in compliance
 with the License.  You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

 Unless required by applicable law or agreed to in writing,
 software distributed under the License is distributed on an
 "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 KIND, either express or implied.  See the License for the
 specific language governing permissions and limitations
 under the License.

> Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements.

Best,
tison.


tison  于2024年4月25日周四 10:47写道：

> > It certainly looks like some code was copied; one file, for instance,
> is about 70% the same. This is not an issue as it is under a compatible MIT
> license, but that needs to be mentioned in the LICENSE file.
>
> Could you please tell the file name and the file on OpenSumi that is
> overlapped? Of course we'd like to add the license info if it's the case,
> and actually I'd generally add a link to the original file. Now we cannot
> find the origin and the author states that they write the code by
> themselves.
>
> You state that there is 70% the same, as what? It's quite confusing to
> give such a conclusion without certain reference.
>
> > A possible explanation for what has happened here is that the developer
> used AI to generate the code, and it’s duplicated that code from somewhere.
> Do you know if that is the case?
>
> If you have a tool to check such similarity, could you share it or share
> the report. When you state a file is copied from elsewhere, there must be
> an origin. AFAIK we don't use AI to generate this code, if you take a look
> at the code (please look), the content is:
>
> public static class ArrayAsList extends AbstractList implements
> RandomAccess, java.io.Serializable {
> private static final Object[] EMPTY = new Object[0];
> private Object[] array;
> private int size;
> public ArrayAsList(int size) { array = new Object[size]; }
> @Override public int size() { return size; }
> @Override public boolean add(Object e) { array[size++] = e; return
> true; }
> @Override public Object get(int index) { return array[index]; }
> public void clearArray() { size = 0; array = EMPTY; }
> public void setArray(Object[] a) { array = a; size = a.length; }
> public Object[] getArray() { return array; }
> @Override public Object set(int index, Object element) { throw new
> UnsupportedOperationException(); }
> @Override public int indexOf(Object o) { throw new
> UnsupportedOperationException(); }
> @Override public boolean contains(Object o) { throw new
> UnsupportedOperationException(); }
> @Override public Object[] toArray() { return array; }
> @Override public Iterator iterator() { return new
> Iterator() {
> private int index;
> @Override public boolean hasNext() { return index < array.length; }
> @Override public Object next() { return array[index++]; }
>   };
> }
>   }
>
> Getters, trivial add / clear / set, three unsupported methods. The fields
> and non-inherited methods are also written originally.
>
> Best,
> tison.
>
>
> Justin Mclean  于2024年4月25日周四 10:36写道：
>
>> Hi,
>>
>> I’m currently travelling and may be slow in responding to emails.
>>
>> > The MemoryBufferWritableChannel[5] and  MockWritableChannel[6] was
>> written
>> > by me before we open-sourced Fury and
>> > I submitted it to Ray in PR[8] ,which was planned to optimize zero-copy
>> > serialization in Ray. I think it's OK to include it
>> > here since both are written by me.
>>
>> That should be fine, but having an ASF header on the files may be a
>> little misleading? What do you think?
>>
>> > For files [1][2][3][4], could you give more details how those files
>> include
>> > code from OpenSumi. The OpenSumi core developer
>> > bytemain[9] does commit some code to Fury, see his commits[10]. But I
>> > talked to him offline, he said he didn't copy code from
>> > OpenSumi.
>>
>> It certainly looks like some code was copied; one file, for instance, is
>> about 70% the same. This is not an issue as it is under a compatible MIT
>> license, but that needs to be mentioned in the LICENSE file.
>>
>> > For Fury ArrayAsList, could you give more details how this class is
>> copied
>> > from somewhere? It's just a simple wrapper for java
>> > object 

Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3

[tison]

> It certainly looks like some code was copied; one file, for instance, is
about 70% the same. This is not an issue as it is under a compatible MIT
license, but that needs to be mentioned in the LICENSE file.

Could you please tell the file name and the file on OpenSumi that is
overlapped? Of course we'd like to add the license info if it's the case,
and actually I'd generally add a link to the original file. Now we cannot
find the origin and the author states that they write the code by
themselves.

You state that there is 70% the same, as what? It's quite confusing to give
such a conclusion without certain reference.

> A possible explanation for what has happened here is that the developer
used AI to generate the code, and it’s duplicated that code from somewhere.
Do you know if that is the case?

If you have a tool to check such similarity, could you share it or share
the report. When you state a file is copied from elsewhere, there must be
an origin. AFAIK we don't use AI to generate this code, if you take a look
at the code (please look), the content is:

public static class ArrayAsList extends AbstractList implements
RandomAccess, java.io.Serializable {
private static final Object[] EMPTY = new Object[0];
private Object[] array;
private int size;
public ArrayAsList(int size) { array = new Object[size]; }
@Override public int size() { return size; }
@Override public boolean add(Object e) { array[size++] = e; return
true; }
@Override public Object get(int index) { return array[index]; }
public void clearArray() { size = 0; array = EMPTY; }
public void setArray(Object[] a) { array = a; size = a.length; }
public Object[] getArray() { return array; }
@Override public Object set(int index, Object element) { throw new
UnsupportedOperationException(); }
@Override public int indexOf(Object o) { throw new
UnsupportedOperationException(); }
@Override public boolean contains(Object o) { throw new
UnsupportedOperationException(); }
@Override public Object[] toArray() { return array; }
@Override public Iterator iterator() { return new
Iterator() {
private int index;
@Override public boolean hasNext() { return index < array.length; }
@Override public Object next() { return array[index++]; }
  };
}
  }

Getters, trivial add / clear / set, three unsupported methods. The fields
and non-inherited methods are also written originally.

Best,
tison.


Justin Mclean  于2024年4月25日周四 10:36写道：

> Hi,
>
> I’m currently travelling and may be slow in responding to emails.
>
> > The MemoryBufferWritableChannel[5] and  MockWritableChannel[6] was
> written
> > by me before we open-sourced Fury and
> > I submitted it to Ray in PR[8] ,which was planned to optimize zero-copy
> > serialization in Ray. I think it's OK to include it
> > here since both are written by me.
>
> That should be fine, but having an ASF header on the files may be a little
> misleading? What do you think?
>
> > For files [1][2][3][4], could you give more details how those files
> include
> > code from OpenSumi. The OpenSumi core developer
> > bytemain[9] does commit some code to Fury, see his commits[10]. But I
> > talked to him offline, he said he didn't copy code from
> > OpenSumi.
>
> It certainly looks like some code was copied; one file, for instance, is
> about 70% the same. This is not an issue as it is under a compatible MIT
> license, but that needs to be mentioned in the LICENSE file.
>
> > For Fury ArrayAsList, could you give more details how this class is
> copied
> > from somewhere? It's just a simple wrapper for java
> > object arrays.
>
> A possible explanation for what has happened here is that the developer
> used AI to generate the code, and it’s duplicated that code from somewhere.
> Do you know if that is the case?
>
> Kind Regards,
> Justin
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Drop the incubator- prefix for podling's GitHub repo

[Justin Mclean]

Hi,

I would be for requiring the incubator disclaimer text in the project's README:
"Apache FOO is an effort undergoing incubation at The Apache Software 
Foundation (ASF), sponsored by the Apache Incubator. Incubation is required of 
all newly accepted projects until a further review indicates that the 
infrastructure, communications, and decision making process have stabilized in 
a manner consistent with other successful ASF projects. While incubation status 
is not necessarily a reflection of the completeness or stability of the code, 
it does indicate that the project has yet to be fully endorsed by the ASF.”

Kind Regards,
Justin

> On 24 Apr 2024, at 9:48 pm, tison  wrote:
> 
> Thanks for your participation!
> 
> For people who support drop the incubator- prefix, please describe you
> opinion on:
> 
>> 3. It's still significant to make it clear that a podling is in the
> incubating status and thus a DISCLAIMER to protect the ASF branding.
>> I'd propose to add the "incubating" words to each repo's README. This can
> be regarded as treating those READMEs a homepage for the repo and,
>> 
>> 1. Name the project as "Apache Foo (Incubating)" in its first and most
> prominent uses, hopefully and H1 heading.
>> 2. Add a footer including the Incubator logo and DISCLAIMER, like the
> current footer of Apache Answer (Incubating) [3]
>> [3] https://answer.apache.org/
> 
> Be sure that you know we don't barely drop the prefix, but we need a formal
> way to "make it clear that a podling's repo is in the incubating status",
> which can be achieved currently by  its prefix.
> 
> Best,
> tison.
> 
> 
> Wilfred Spiegelenburg  于2024年4月23日周二 13:12写道：
> 
>> For Go based projects dropping the incubator reference in the git repo
>> makes things easier also when graduating. Packages and dependencies are
>> referenced based on the repository name. Renaming the repository either
>> requires changes throughout the code base to remove the incubator reference
>> or the packages will always have the incubator reference in them.
>> 
>> Wilfred
>> 
>> On 2024/04/23 01:22:02 tison wrote:
>>> Hi,
>>> 
>>> Recently, the new added podlings, namely Amoro and Hertzbeat, have their
>>> GitHub repo in the names:
>>> 
>>> * https://github.com/apache/amoro
>>> * https://github.com/apache/hertzbeat
>>> 
>>> ... which is different to the other 20+ podlings and 200+ repos [1]
>>> existing (this number counts retired ones and those for the Incubator PMC
>>> itself, but it's approximate).
>>> 
>>> [1]
>>> 
>> https://github.com/orgs/apache/repositories?language==incubator-==all
>>> 
>>> My opinion is to agree that generally:
>>> 
>>> 1. The incubator prefix comes from the SVN days where all podlings were
>> under
>>> the incubator SVN tree.
>>> 2. Dropping the incubator- prefix for podling's GitHub repo can reduce
>> some
>>> graduation tasks (although it's somewhat a milestone and ceremony for the
>>> podling, and INFRA does not find it a large job, as well as it won't
>> break
>>> downstream almost due to redirections).
>>> 3. It's still significant to make it clear that a podling is in the
>>> incubating status and thus a DISCLAIMER to protect the ASF branding.
>>> 
>>> With these premises, I started this thread with the following proposals
>> and
>>> questions.
>>> 
>>> 1. Establish a consensus to allow podling's GitHub repo to have a name
>>> without incubator- prefix.
>>> 2. Allow other podlings to ask the INFRA to drop their incubator- prefix
>> by
>>> now, not MUST during the graduation.
>>> 3. Update the docs on incubator.apache.org everywhere if the description
>>> can conflict with this consensus.
>>> 4. However, find a way to clarify that a repo belongs to a podling.
>>> 
>>> For 4, I'd propose to add the "incubating" words to each repo's README.
>>> This can be regarded as treating those READMEs a homepage for the repo
>> and,
>>> 
>>> 1. Name the project as "Apache Foo (Incubating)" in its first and most
>>> prominent uses, hopefully and H1 heading.
>>> 2. Add a footer including the Incubator logo and DISCLAIMER, like the
>>> current footer of Apache Answer (Incubating) [3]
>>> 
>>> [3] https://answer.apache.org/
>>> 
>>> This method, however, can be a new chore for podlings that have many
>>> satellite repos that may previously claim their incubating status by
>> naming
>>> the repos incubator-foo-satellite. But it's just another template to
>>> follow, so it won't be a big deal.
>>> 
>>> Looking forward to your thoughts on this proposal and any suggestions to
>>> improve the implementation part.
>>> 
>>> Best,
>>> tison.
>>> 
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
>> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: 

Re: [ANNOUNCE] Release Apache Devlake(incubating) 0.21.0-incubating

[Zikuan An]

Hi,

Thank you very much for the guidance from our mentors.
We have updated the download page: https://devlake.apache.org/download

Best,
Zikuan An

Zikuan An  于2024年4月24日周三 12:41写道：

> Hi Willem,
>
>
> Thank you so much for taking the time to review the download links on the
> DevLake website and for providing valuable feedback. Your guidance is
> greatly appreciated.
>
>
> We will work diligently to implement the necessary changes to ensure that
> our download page meets the required standards, including hosting the KEYS
> and signed asc files.
>
>
> Best regards,
>
> Zikuan An
>

Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3

[Justin Mclean]

Hi,

I’m currently travelling and may be slow in responding to emails.

> The MemoryBufferWritableChannel[5] and  MockWritableChannel[6] was written
> by me before we open-sourced Fury and
> I submitted it to Ray in PR[8] ,which was planned to optimize zero-copy
> serialization in Ray. I think it's OK to include it
> here since both are written by me.

That should be fine, but having an ASF header on the files may be a little 
misleading? What do you think?

> For files [1][2][3][4], could you give more details how those files include
> code from OpenSumi. The OpenSumi core developer
> bytemain[9] does commit some code to Fury, see his commits[10]. But I
> talked to him offline, he said he didn't copy code from
> OpenSumi.

It certainly looks like some code was copied; one file, for instance, is about 
70% the same. This is not an issue as it is under a compatible MIT license, but 
that needs to be mentioned in the LICENSE file.

> For Fury ArrayAsList, could you give more details how this class is copied
> from somewhere? It's just a simple wrapper for java
> object arrays.

A possible explanation for what has happened here is that the developer used AI 
to generate the code, and it’s duplicated that code from somewhere. Do you know 
if that is the case?

Kind Regards,
Justin


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Missing Incubator disclaimer text

[sebb]

On Wed, 24 Apr 2024 at 13:05, tison  wrote:
>
> Hi Sebb,
>
> > quite a few podlings where the text is only present on some of the web
> pages
>
> [1] you refers writes:
>
> >> Podling web sites MUST include a clear disclaimer on their website
>
> So, IMO it's clear that every page should contain such info (typically as
> part of the footer). If you find any podling violates this policy, you can
> name them and I'd like to give a look.
>
> For the podlings I participate in, I spread the docu template [2] to ensure
> that this policy is followed.
>
> [2]
> https://github.com/apache/apache-website-template/blob/f8129ca66fdff1c97e0749eb2ed319f1739f6f34/docusaurus.config.ts#L137
>
> > and in announcement emails
>
> This sounds like a new sentence to me. Have we ever had a consensus before?
> I agree that such a policy can help convey the project's status more
> clearly, and it won't be difficult to add such a section in the
> announcement email. Most of the podlings may be unaware of this point, and
> I didn't hear about this before.

The policy at [1] includes the phrase " in all documentation
(including releases) ".
The announce mail is documentation that the release has occurred.

It is vital that consumers are told up-front about the status of
incubator releases.

> Best,
> tison.
>
>
> sebb  于2024年4月24日周三 15:58写道：
>
> > My understanding is that the Incubator disclaimer text [1] should be
> > present on all website pages and in announcement emails, so consumers
> > are clear about the status of the software.
> >
> > However there are quite a few podlings where the text is only present
> > on some of the web pages, and most announce emails don't include the
> > disclaimer.
> >
> > Note that unlike licensing issues, which can be sorted out during
> > incubation, this is something that must be addressed from the very
> > beginning.
> >
> > Sebb
> > [1] https://incubator.apache.org/guides/branding.html#disclaimers
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Publishing pywayang for pip

[Alexander Alten-Lorenz]

Awesome Xuanwo, thank you!

—Alex 

> On 24. Apr 2024, at 16:07, Xuanwo  wrote:
> 
> Hi,
> 
> Pypi supports OIDC so that we don't need to configure static tokens at all.
> 
> Welcome to take a look over opendal's python release workflow[1]. You can 
> find more at pypa/gh-action-pypi-publish[2]
> 
> [1]: 
> https://www.google.com/url?q=https://github.com/apache/opendal/blob/main/.github/workflows/release_python.yml%23L114-L139=gmail-imap=171457247300=AOvVaw1AtT04WP0yql-SPIqi967O
> [2]: 
> https://www.google.com/url?q=https://github.com/pypa/gh-action-pypi-publish=gmail-imap=171457247300=AOvVaw1AL9hxgRb6Y0gCC9Kpc0TB
> 
> On Wed, Apr 24, 2024, at 21:42, Alexander Alten wrote:
>> Hi Juri et all,
>> 
>> I extend to the incubator community, since that is quite a great question. 
>> 
>> Does any project have a python module released and how does the process 
>> looks like?
>> 
>> Thank you,
>> —Alex 
>> 
>>> On 24. Apr 2024, at 14:23, Juri Petersen  wrote:
>>> 
>>> Hello,
>>> we plan to publish our Python API pywayang as a package to make it 
>>> installable via pip.
>>> In order to do this, we need to generate Python API tokens and store them.
>>> Is there any knowledge on how storing secrets like the token is to be done 
>>> in Apache projects?
>>> Is the infrastructure team responsible for publications like this?
>>> 
>>> Best,
>>> Juri
>> 
>> 
>> -- 
>> *Why Scalytics:* 
>> Break data silos. Put your data to work. All without ever 
>> sharing your data. That's the Scalytics difference.
>> 
>> 
>> --
>> 3401 N. MIAMI AVE. 
>> STE 230
>> 33127 Miami, Florida 
>> United States
>> www.scalytics.io 
>> 
>> 
>> --  Please consider the environment before 
>> printing this email --
>> 
>> Disclaimer:
>> The content of this message is 
>> confidential. If you have received it by mistake, please inform us by an 
>> email reply and then delete the message. It is forbidden to copy, forward, 
>> or in any way reveal the contents of this message to anyone. The integrity 
>> and security of this email cannot be guaranteed over the Internet. 
>> Therefore, the sender will not be held liable for any damage caused by the 
>> message.
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org 
>> 
>> For additional commands, e-mail: general-h...@incubator.apache.org 
>> 
> 
> -- 
> Xuanwo

Re: Publishing pywayang for pip

[Xuanwo]

Hi,

Pypi supports OIDC so that we don't need to configure static tokens at all.

Welcome to take a look over opendal's python release workflow[1]. You can find 
more at pypa/gh-action-pypi-publish[2]

[1]: 
https://github.com/apache/opendal/blob/main/.github/workflows/release_python.yml#L114-L139
[2]: https://github.com/pypa/gh-action-pypi-publish

On Wed, Apr 24, 2024, at 21:42, Alexander Alten wrote:
> Hi Juri et all,
>
> I extend to the incubator community, since that is quite a great question. 
>
> Does any project have a python module released and how does the process 
> looks like?
>
> Thank you,
>  —Alex 
>
>> On 24. Apr 2024, at 14:23, Juri Petersen  wrote:
>> 
>> Hello,
>> we plan to publish our Python API pywayang as a package to make it 
>> installable via pip.
>> In order to do this, we need to generate Python API tokens and store them.
>> Is there any knowledge on how storing secrets like the token is to be done 
>> in Apache projects?
>> Is the infrastructure team responsible for publications like this?
>> 
>> Best,
>> Juri
>
>
> -- 
> *Why Scalytics:* 
> Break data silos. Put your data to work. All without ever 
> sharing your data. That's the Scalytics difference.
>
>
> --
> 3401 N. MIAMI AVE. 
> STE 230
> 33127 Miami, Florida 
> United States
> www.scalytics.io 
> 
>
> --  Please consider the environment before 
> printing this email --
>
> Disclaimer:
> The content of this message is 
> confidential. If you have received it by mistake, please inform us by an 
> email reply and then delete the message. It is forbidden to copy, forward, 
> or in any way reveal the contents of this message to anyone. The integrity 
> and security of this email cannot be guaranteed over the Internet. 
> Therefore, the sender will not be held liable for any damage caused by the 
> message.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org

-- 
Xuanwo

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Publishing pywayang for pip

[Alexander Alten]

Hi Juri et all,

I extend to the incubator community, since that is quite a great question. 

Does any project have a python module released and how does the process looks 
like?

Thank you,
 —Alex 

> On 24. Apr 2024, at 14:23, Juri Petersen  wrote:
> 
> Hello,
> we plan to publish our Python API pywayang as a package to make it 
> installable via pip.
> In order to do this, we need to generate Python API tokens and store them.
> Is there any knowledge on how storing secrets like the token is to be done in 
> Apache projects?
> Is the infrastructure team responsible for publications like this?
> 
> Best,
> Juri


-- 
*Why Scalytics:* 
Break data silos. Put your data to work. All without ever 
sharing your data. That's the Scalytics difference.


--
3401 N. MIAMI AVE. 
STE 230
33127 Miami, Florida 
United States
www.scalytics.io 


--  Please consider the environment before 
printing this email --

Disclaimer:
The content of this message is 
confidential. If you have received it by mistake, please inform us by an 
email reply and then delete the message. It is forbidden to copy, forward, 
or in any way reveal the contents of this message to anyone. The integrity 
and security of this email cannot be guaranteed over the Internet. 
Therefore, the sender will not be held liable for any damage caused by the 
message.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Missing Incubator disclaimer text

[tison]

Hi Sebb,

> quite a few podlings where the text is only present on some of the web
pages

[1] you refers writes:

>> Podling web sites MUST include a clear disclaimer on their website

So, IMO it's clear that every page should contain such info (typically as
part of the footer). If you find any podling violates this policy, you can
name them and I'd like to give a look.

For the podlings I participate in, I spread the docu template [2] to ensure
that this policy is followed.

[2]
https://github.com/apache/apache-website-template/blob/f8129ca66fdff1c97e0749eb2ed319f1739f6f34/docusaurus.config.ts#L137

> and in announcement emails

This sounds like a new sentence to me. Have we ever had a consensus before?
I agree that such a policy can help convey the project's status more
clearly, and it won't be difficult to add such a section in the
announcement email. Most of the podlings may be unaware of this point, and
I didn't hear about this before.

Best,
tison.


sebb  于2024年4月24日周三 15:58写道：

> My understanding is that the Incubator disclaimer text [1] should be
> present on all website pages and in announcement emails, so consumers
> are clear about the status of the software.
>
> However there are quite a few podlings where the text is only present
> on some of the web pages, and most announce emails don't include the
> disclaimer.
>
> Note that unlike licensing issues, which can be sorted out during
> incubation, this is something that must be addressed from the very
> beginning.
>
> Sebb
> [1] https://incubator.apache.org/guides/branding.html#disclaimers
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Drop the incubator- prefix for podling's GitHub repo

[tison]

Thanks for your participation!

For people who support drop the incubator- prefix, please describe you
opinion on:

> 3. It's still significant to make it clear that a podling is in the
incubating status and thus a DISCLAIMER to protect the ASF branding.
> I'd propose to add the "incubating" words to each repo's README. This can
be regarded as treating those READMEs a homepage for the repo and,
>
> 1. Name the project as "Apache Foo (Incubating)" in its first and most
prominent uses, hopefully and H1 heading.
> 2. Add a footer including the Incubator logo and DISCLAIMER, like the
current footer of Apache Answer (Incubating) [3]
> [3] https://answer.apache.org/

Be sure that you know we don't barely drop the prefix, but we need a formal
way to "make it clear that a podling's repo is in the incubating status",
which can be achieved currently by  its prefix.

Best,
tison.


Wilfred Spiegelenburg  于2024年4月23日周二 13:12写道：

> For Go based projects dropping the incubator reference in the git repo
> makes things easier also when graduating. Packages and dependencies are
> referenced based on the repository name. Renaming the repository either
> requires changes throughout the code base to remove the incubator reference
> or the packages will always have the incubator reference in them.
>
> Wilfred
>
> On 2024/04/23 01:22:02 tison wrote:
> > Hi,
> >
> > Recently, the new added podlings, namely Amoro and Hertzbeat, have their
> > GitHub repo in the names:
> >
> > * https://github.com/apache/amoro
> > * https://github.com/apache/hertzbeat
> >
> > ... which is different to the other 20+ podlings and 200+ repos [1]
> > existing (this number counts retired ones and those for the Incubator PMC
> > itself, but it's approximate).
> >
> > [1]
> >
> https://github.com/orgs/apache/repositories?language==incubator-==all
> >
> > My opinion is to agree that generally:
> >
> > 1. The incubator prefix comes from the SVN days where all podlings were
> under
> > the incubator SVN tree.
> > 2. Dropping the incubator- prefix for podling's GitHub repo can reduce
> some
> > graduation tasks (although it's somewhat a milestone and ceremony for the
> > podling, and INFRA does not find it a large job, as well as it won't
> break
> > downstream almost due to redirections).
> > 3. It's still significant to make it clear that a podling is in the
> > incubating status and thus a DISCLAIMER to protect the ASF branding.
> >
> > With these premises, I started this thread with the following proposals
> and
> > questions.
> >
> > 1. Establish a consensus to allow podling's GitHub repo to have a name
> > without incubator- prefix.
> > 2. Allow other podlings to ask the INFRA to drop their incubator- prefix
> by
> > now, not MUST during the graduation.
> > 3. Update the docs on incubator.apache.org everywhere if the description
> > can conflict with this consensus.
> > 4. However, find a way to clarify that a repo belongs to a podling.
> >
> > For 4, I'd propose to add the "incubating" words to each repo's README.
> > This can be regarded as treating those READMEs a homepage for the repo
> and,
> >
> > 1. Name the project as "Apache Foo (Incubating)" in its first and most
> > prominent uses, hopefully and H1 heading.
> > 2. Add a footer including the Incubator logo and DISCLAIMER, like the
> > current footer of Apache Answer (Incubating) [3]
> >
> > [3] https://answer.apache.org/
> >
> > This method, however, can be a new chore for podlings that have many
> > satellite repos that may previously claim their incubating status by
> naming
> > the repos incubator-foo-satellite. But it's just another template to
> > follow, so it won't be a big deal.
> >
> > Looking forward to your thoughts on this proposal and any suggestions to
> > improve the implementation part.
> >
> > Best,
> > tison.
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3

[tison]

Since it's valid that the LICENSE content to benchmark is redundant, I
suggest we cancel this RC and start a new RC.

In order to resolve the other potential compliance issues before the
next RC is out, I'd appreciate if Justin can confirm that the reply above
is clear, that is:

* 5-6 is authored by Shawn Yang. So he has the right to contribute it to
Fury, no matter if the same code is contributed to elsewhere.
* 1-4 are false positive as no evidence implies that it's copied from
elsewhere. The commit authors confirmed that they don't copy also

* 7, especially after the patch [1], is false positive since it's an
original class implement by Shawn Yang and for hacking Fury's
serialization. The comment "A List which wrap a Java array like
`java.util.Arrays.ArrayList`" indicates Shawn feels that the manner to hold
a E[] list is similar, but Fury's class maintain size by itself and all the
methods are written originally, or just as trivial as a getter/setter. If
the comment introduces confusion, I suggest we remove it.

[1] https://github.com/apache/incubator-fury/pull/1560/files

Best,
tison.


Shawn Yang  于2024年4月24日周三 15:52写道：

> Hi Sebb,
>
> The published install page[1] should  look good now, could you check it
> again?
>
> 1. https://fury.apache.org/docs/start/install
>
> 
> Best Regards,
> Chaoun Yang
>
> On Wed, Apr 24, 2024 at 3:44 PM sebb  wrote:
>
> > On Wed, 24 Apr 2024 at 08:29, Shawn Yang 
> wrote:
> > >
> > > Hi Sebb,
> > >
> > > I highlight that the current release is not an asf release in the
> install
> > > page in PR https://github.com/apache/incubator-fury-site/pull/113.
> > >
> > > Could you take a look at it again?
> >
> > I have just looked at the PR you just raised, and it looks OK.
> >
> > Note that my comment was about the published install page, which is
> > still as I described.
> >
> > > Thanks for taking time to review Fury's release.
> > >
> > > Best regards,
> > > Chaokun Yang
> > >
> > > On Wed, Apr 24, 2024 at 3:20 PM sebb  wrote:
> > >
> > > > There is now a link to a potential download page, which is great.
> > > >
> > > > However, the install page does not make it obvious that the 0.4.1
> > > > release is not an ASF release.
> > > > That information should be shown prominently at the start of the
> page,
> > > > not buried in a note near the end.
> > > >
> > > > On Tue, 23 Apr 2024 at 16:07, Shawn Yang 
> > wrote:
> > > > >
> > > > > I updated it in the PR
> > > > > https://github.com/apache/incubator-fury-site/pull/112. Sorry for
> my
> > > > last
> > > > > reply, I forgot to put the PR link.
> > > > >
> > > > > On Tue, Apr 23, 2024 at 10:22 PM sebb  wrote:
> > > > >
> > > > > > On Tue, 23 Apr 2024 at 14:05, Shawn Yang <
> shawn.ck.y...@gmail.com>
> > > > wrote:
> > > > > > >
> > > > > > > Hi Sebb,
> > > > > > >
> > > > > > > I  updated the content in the install doc and added notes that
> > this
> > > > is
> > > > > > not
> > > > > > > an ASF release.
> > > > > > >
> > > > > > > And added a download page for download and verify source
> release
> > > > only.
> > > > > > > Currently this page is basically empty, but will be updated
> once
> > this
> > > > > > vote
> > > > > > > is done, and updated
> > > > > > > to closer.lua according to download-scripts[1].
> > > > > > >
> > > > > > > The cross-links to each other are also added.
> > > > > >
> > > > > > I don't see these changes on the fury.apache.org website.
> > > > > > Are they published anywhere?
> > > > > >
> > > > > > > 1.
> > > >
> https://infra.apache.org/release-download-pages.html#download-scripts
> > > > > > >
> > > > > > > Thanks again for pointing those issues out.
> > > > > > >
> > > > > > > -
> > > > > > > Best Regards,
> > > > > > > Chaokun Yang
> > > > > > >
> > > > > > > On Tue, Apr 23, 2024 at 8:22 PM sebb  wrote:
> > > > > > >
> > > > > > > > On Tue, 23 Apr 2024 at 13:08, tison 
> > wrote:
> > > > > > > > >
> > > > > > > > > > They could fix the page now, while waiting for the
> release
> > > > vote to
> > > > > > > > > complete.
> > > > > > > > >
> > > > > > > > > Make sense. At least remove the page/content now to
> indicate
> > "no
> > > > > > Apache
> > > > > > > > > release" now. Then it won't be some "forth and back"
> updates.
> > > > It's a
> > > > > > > > timing
> > > > > > > > > issue.
> > > > > > > > >
> > > > > > > > > > Note that the page needs more than just an update to
> > version
> > > > > > numbers.
> > > > > > > > > > It needs closer.lua links to the source bundle, links to
> > KEYS,
> > > > sigs
> > > > > > > > > > and hashes, and verification instructions.
> > > > > > > > >
> > > > > > > > > Such an install page can be a simplified quick start page.
> I
> > > > suppose
> > > > > > you
> > > > > > > > > refer to a download page like [1].
> > > > > > > > >
> > > > > > > > > [1] https://hadoop.apache.org/releases.html
> > > > > > > >
> > > > > > > > Yes, though ideally use closer.lua rather than closer.cgi.
> > > > > > > >
> > > > > > > > > And yes, Fury doesn't 

Missing Incubator disclaimer text

[sebb]

My understanding is that the Incubator disclaimer text [1] should be
present on all website pages and in announcement emails, so consumers
are clear about the status of the software.

However there are quite a few podlings where the text is only present
on some of the web pages, and most announce emails don't include the
disclaimer.

Note that unlike licensing issues, which can be sorted out during
incubation, this is something that must be addressed from the very
beginning.

Sebb
[1] https://incubator.apache.org/guides/branding.html#disclaimers

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3

[Shawn Yang]

Hi Sebb,

The published install page[1] should  look good now, could you check it
again?

1. https://fury.apache.org/docs/start/install


Best Regards,
Chaoun Yang

On Wed, Apr 24, 2024 at 3:44 PM sebb  wrote:

> On Wed, 24 Apr 2024 at 08:29, Shawn Yang  wrote:
> >
> > Hi Sebb,
> >
> > I highlight that the current release is not an asf release in the install
> > page in PR https://github.com/apache/incubator-fury-site/pull/113.
> >
> > Could you take a look at it again?
>
> I have just looked at the PR you just raised, and it looks OK.
>
> Note that my comment was about the published install page, which is
> still as I described.
>
> > Thanks for taking time to review Fury's release.
> >
> > Best regards,
> > Chaokun Yang
> >
> > On Wed, Apr 24, 2024 at 3:20 PM sebb  wrote:
> >
> > > There is now a link to a potential download page, which is great.
> > >
> > > However, the install page does not make it obvious that the 0.4.1
> > > release is not an ASF release.
> > > That information should be shown prominently at the start of the page,
> > > not buried in a note near the end.
> > >
> > > On Tue, 23 Apr 2024 at 16:07, Shawn Yang 
> wrote:
> > > >
> > > > I updated it in the PR
> > > > https://github.com/apache/incubator-fury-site/pull/112. Sorry for my
> > > last
> > > > reply, I forgot to put the PR link.
> > > >
> > > > On Tue, Apr 23, 2024 at 10:22 PM sebb  wrote:
> > > >
> > > > > On Tue, 23 Apr 2024 at 14:05, Shawn Yang 
> > > wrote:
> > > > > >
> > > > > > Hi Sebb,
> > > > > >
> > > > > > I  updated the content in the install doc and added notes that
> this
> > > is
> > > > > not
> > > > > > an ASF release.
> > > > > >
> > > > > > And added a download page for download and verify source release
> > > only.
> > > > > > Currently this page is basically empty, but will be updated once
> this
> > > > > vote
> > > > > > is done, and updated
> > > > > > to closer.lua according to download-scripts[1].
> > > > > >
> > > > > > The cross-links to each other are also added.
> > > > >
> > > > > I don't see these changes on the fury.apache.org website.
> > > > > Are they published anywhere?
> > > > >
> > > > > > 1.
> > > https://infra.apache.org/release-download-pages.html#download-scripts
> > > > > >
> > > > > > Thanks again for pointing those issues out.
> > > > > >
> > > > > > -
> > > > > > Best Regards,
> > > > > > Chaokun Yang
> > > > > >
> > > > > > On Tue, Apr 23, 2024 at 8:22 PM sebb  wrote:
> > > > > >
> > > > > > > On Tue, 23 Apr 2024 at 13:08, tison 
> wrote:
> > > > > > > >
> > > > > > > > > They could fix the page now, while waiting for the release
> > > vote to
> > > > > > > > complete.
> > > > > > > >
> > > > > > > > Make sense. At least remove the page/content now to indicate
> "no
> > > > > Apache
> > > > > > > > release" now. Then it won't be some "forth and back" updates.
> > > It's a
> > > > > > > timing
> > > > > > > > issue.
> > > > > > > >
> > > > > > > > > Note that the page needs more than just an update to
> version
> > > > > numbers.
> > > > > > > > > It needs closer.lua links to the source bundle, links to
> KEYS,
> > > sigs
> > > > > > > > > and hashes, and verification instructions.
> > > > > > > >
> > > > > > > > Such an install page can be a simplified quick start page. I
> > > suppose
> > > > > you
> > > > > > > > refer to a download page like [1].
> > > > > > > >
> > > > > > > > [1] https://hadoop.apache.org/releases.html
> > > > > > >
> > > > > > > Yes, though ideally use closer.lua rather than closer.cgi.
> > > > > > >
> > > > > > > > And yes, Fury doesn't have a download page yet, and they
> should
> > > add
> > > > > one.
> > > > > > >
> > > > > > > Agreed.
> > > > > > >
> > > > > > > > But in my experience it's different from a quickstart install
> > > page,
> > > > > like
> > > > > > > > [2] vs [3].
> > > > > > >
> > > > > > > Yes, but that should not be at the expense of a source download
> > > page.
> > > > > > > It must be easy to find the source download.
> > > > > > > The website and the announcement email must link to the
> official
> > > > > download
> > > > > > > page.
> > > > > > >
> > > > > > > The download and install pages could be cross-linked.
> > > > > > >
> > > > > > > > [2] https://opendal.apache.org/docs/quickstart#java-binding
> > > > > > > > [3] https://opendal.apache.org/download
> > > > > > > >
> > > > > > > > Best,
> > > > > > > > tison.
> > > > > > > >
> > > > > > > >
> > > > > > > > sebb  于2024年4月23日周二 20:00写道：
> > > > > > > >
> > > > > > > > > On Tue, 23 Apr 2024 at 12:46, tison 
> > > wrote:
> > > > > > > > > >
> > > > > > > > > > > I would be very disappointed if the podling published
> the
> > > code
> > > > > > > > > > > *knowing* that the download page is missing or
> incorrect.
> > > > > > > > > >
> > > > > > > > > > IIUC Fury will update the content and delete all the
> > > references
> > > > > to
> > > > > > > prior
> > > > > > > > > > releases.
> > > > > > > > >
> > > > > > > > > Note that the page needs more than just an 

Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3

[sebb]

On Wed, 24 Apr 2024 at 08:29, Shawn Yang  wrote:
>
> Hi Sebb,
>
> I highlight that the current release is not an asf release in the install
> page in PR https://github.com/apache/incubator-fury-site/pull/113.
>
> Could you take a look at it again?

I have just looked at the PR you just raised, and it looks OK.

Note that my comment was about the published install page, which is
still as I described.

> Thanks for taking time to review Fury's release.
>
> Best regards,
> Chaokun Yang
>
> On Wed, Apr 24, 2024 at 3:20 PM sebb  wrote:
>
> > There is now a link to a potential download page, which is great.
> >
> > However, the install page does not make it obvious that the 0.4.1
> > release is not an ASF release.
> > That information should be shown prominently at the start of the page,
> > not buried in a note near the end.
> >
> > On Tue, 23 Apr 2024 at 16:07, Shawn Yang  wrote:
> > >
> > > I updated it in the PR
> > > https://github.com/apache/incubator-fury-site/pull/112. Sorry for my
> > last
> > > reply, I forgot to put the PR link.
> > >
> > > On Tue, Apr 23, 2024 at 10:22 PM sebb  wrote:
> > >
> > > > On Tue, 23 Apr 2024 at 14:05, Shawn Yang 
> > wrote:
> > > > >
> > > > > Hi Sebb,
> > > > >
> > > > > I  updated the content in the install doc and added notes that this
> > is
> > > > not
> > > > > an ASF release.
> > > > >
> > > > > And added a download page for download and verify source release
> > only.
> > > > > Currently this page is basically empty, but will be updated once this
> > > > vote
> > > > > is done, and updated
> > > > > to closer.lua according to download-scripts[1].
> > > > >
> > > > > The cross-links to each other are also added.
> > > >
> > > > I don't see these changes on the fury.apache.org website.
> > > > Are they published anywhere?
> > > >
> > > > > 1.
> > https://infra.apache.org/release-download-pages.html#download-scripts
> > > > >
> > > > > Thanks again for pointing those issues out.
> > > > >
> > > > > -
> > > > > Best Regards,
> > > > > Chaokun Yang
> > > > >
> > > > > On Tue, Apr 23, 2024 at 8:22 PM sebb  wrote:
> > > > >
> > > > > > On Tue, 23 Apr 2024 at 13:08, tison  wrote:
> > > > > > >
> > > > > > > > They could fix the page now, while waiting for the release
> > vote to
> > > > > > > complete.
> > > > > > >
> > > > > > > Make sense. At least remove the page/content now to indicate "no
> > > > Apache
> > > > > > > release" now. Then it won't be some "forth and back" updates.
> > It's a
> > > > > > timing
> > > > > > > issue.
> > > > > > >
> > > > > > > > Note that the page needs more than just an update to version
> > > > numbers.
> > > > > > > > It needs closer.lua links to the source bundle, links to KEYS,
> > sigs
> > > > > > > > and hashes, and verification instructions.
> > > > > > >
> > > > > > > Such an install page can be a simplified quick start page. I
> > suppose
> > > > you
> > > > > > > refer to a download page like [1].
> > > > > > >
> > > > > > > [1] https://hadoop.apache.org/releases.html
> > > > > >
> > > > > > Yes, though ideally use closer.lua rather than closer.cgi.
> > > > > >
> > > > > > > And yes, Fury doesn't have a download page yet, and they should
> > add
> > > > one.
> > > > > >
> > > > > > Agreed.
> > > > > >
> > > > > > > But in my experience it's different from a quickstart install
> > page,
> > > > like
> > > > > > > [2] vs [3].
> > > > > >
> > > > > > Yes, but that should not be at the expense of a source download
> > page.
> > > > > > It must be easy to find the source download.
> > > > > > The website and the announcement email must link to the official
> > > > download
> > > > > > page.
> > > > > >
> > > > > > The download and install pages could be cross-linked.
> > > > > >
> > > > > > > [2] https://opendal.apache.org/docs/quickstart#java-binding
> > > > > > > [3] https://opendal.apache.org/download
> > > > > > >
> > > > > > > Best,
> > > > > > > tison.
> > > > > > >
> > > > > > >
> > > > > > > sebb  于2024年4月23日周二 20:00写道：
> > > > > > >
> > > > > > > > On Tue, 23 Apr 2024 at 12:46, tison 
> > wrote:
> > > > > > > > >
> > > > > > > > > > I would be very disappointed if the podling published the
> > code
> > > > > > > > > > *knowing* that the download page is missing or incorrect.
> > > > > > > > >
> > > > > > > > > IIUC Fury will update the content and delete all the
> > references
> > > > to
> > > > > > prior
> > > > > > > > > releases.
> > > > > > > >
> > > > > > > > Note that the page needs more than just an update to version
> > > > numbers.
> > > > > > > > It needs closer.lua links to the source bundle, links to KEYS,
> > sigs
> > > > > > > > and hashes, and verification instrructions.
> > > > > > > >
> > > > > > > > > Or instead, Fury can keep these references and state clearly
> > it's
> > > > > > prior
> > > > > > > > > releases.
> > > > > > > > >
> > > > > > > > > My comment above is with an assumption that prior releases
> > ref
> > > > will
> > > > > > be
> > > > > > > > > removed. But if the PPMC wants to keep 

Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3

[Shawn Yang]

Hi Sebb,

I highlight that the current release is not an asf release in the install
page in PR https://github.com/apache/incubator-fury-site/pull/113.

Could you take a look at it again?

Thanks for taking time to review Fury's release.

Best regards,
Chaokun Yang

On Wed, Apr 24, 2024 at 3:20 PM sebb  wrote:

> There is now a link to a potential download page, which is great.
>
> However, the install page does not make it obvious that the 0.4.1
> release is not an ASF release.
> That information should be shown prominently at the start of the page,
> not buried in a note near the end.
>
> On Tue, 23 Apr 2024 at 16:07, Shawn Yang  wrote:
> >
> > I updated it in the PR
> > https://github.com/apache/incubator-fury-site/pull/112. Sorry for my
> last
> > reply, I forgot to put the PR link.
> >
> > On Tue, Apr 23, 2024 at 10:22 PM sebb  wrote:
> >
> > > On Tue, 23 Apr 2024 at 14:05, Shawn Yang 
> wrote:
> > > >
> > > > Hi Sebb,
> > > >
> > > > I  updated the content in the install doc and added notes that this
> is
> > > not
> > > > an ASF release.
> > > >
> > > > And added a download page for download and verify source release
> only.
> > > > Currently this page is basically empty, but will be updated once this
> > > vote
> > > > is done, and updated
> > > > to closer.lua according to download-scripts[1].
> > > >
> > > > The cross-links to each other are also added.
> > >
> > > I don't see these changes on the fury.apache.org website.
> > > Are they published anywhere?
> > >
> > > > 1.
> https://infra.apache.org/release-download-pages.html#download-scripts
> > > >
> > > > Thanks again for pointing those issues out.
> > > >
> > > > -
> > > > Best Regards,
> > > > Chaokun Yang
> > > >
> > > > On Tue, Apr 23, 2024 at 8:22 PM sebb  wrote:
> > > >
> > > > > On Tue, 23 Apr 2024 at 13:08, tison  wrote:
> > > > > >
> > > > > > > They could fix the page now, while waiting for the release
> vote to
> > > > > > complete.
> > > > > >
> > > > > > Make sense. At least remove the page/content now to indicate "no
> > > Apache
> > > > > > release" now. Then it won't be some "forth and back" updates.
> It's a
> > > > > timing
> > > > > > issue.
> > > > > >
> > > > > > > Note that the page needs more than just an update to version
> > > numbers.
> > > > > > > It needs closer.lua links to the source bundle, links to KEYS,
> sigs
> > > > > > > and hashes, and verification instructions.
> > > > > >
> > > > > > Such an install page can be a simplified quick start page. I
> suppose
> > > you
> > > > > > refer to a download page like [1].
> > > > > >
> > > > > > [1] https://hadoop.apache.org/releases.html
> > > > >
> > > > > Yes, though ideally use closer.lua rather than closer.cgi.
> > > > >
> > > > > > And yes, Fury doesn't have a download page yet, and they should
> add
> > > one.
> > > > >
> > > > > Agreed.
> > > > >
> > > > > > But in my experience it's different from a quickstart install
> page,
> > > like
> > > > > > [2] vs [3].
> > > > >
> > > > > Yes, but that should not be at the expense of a source download
> page.
> > > > > It must be easy to find the source download.
> > > > > The website and the announcement email must link to the official
> > > download
> > > > > page.
> > > > >
> > > > > The download and install pages could be cross-linked.
> > > > >
> > > > > > [2] https://opendal.apache.org/docs/quickstart#java-binding
> > > > > > [3] https://opendal.apache.org/download
> > > > > >
> > > > > > Best,
> > > > > > tison.
> > > > > >
> > > > > >
> > > > > > sebb  于2024年4月23日周二 20:00写道：
> > > > > >
> > > > > > > On Tue, 23 Apr 2024 at 12:46, tison 
> wrote:
> > > > > > > >
> > > > > > > > > I would be very disappointed if the podling published the
> code
> > > > > > > > > *knowing* that the download page is missing or incorrect.
> > > > > > > >
> > > > > > > > IIUC Fury will update the content and delete all the
> references
> > > to
> > > > > prior
> > > > > > > > releases.
> > > > > > >
> > > > > > > Note that the page needs more than just an update to version
> > > numbers.
> > > > > > > It needs closer.lua links to the source bundle, links to KEYS,
> sigs
> > > > > > > and hashes, and verification instrructions.
> > > > > > >
> > > > > > > > Or instead, Fury can keep these references and state clearly
> it's
> > > > > prior
> > > > > > > > releases.
> > > > > > > >
> > > > > > > > My comment above is with an assumption that prior releases
> ref
> > > will
> > > > > be
> > > > > > > > removed. But if the PPMC wants to keep it, they should
> update the
> > > > > > > > description.
> > > > > > >
> > > > > > > They could fix the page now, while waiting for the release
> vote to
> > > > > > > complete.
> > > > > > >
> > > > > > > > Best,
> > > > > > > > tison.
> > > > > > > >
> > > > > > > >
> > > > > > > > sebb  于2024年4月23日周二 19:35写道：
> > > > > > > >
> > > > > > > > > On Tue, 23 Apr 2024 at 09:42, tison 
> > > wrote:
> > > > > > > > > >
> > > > > > > > > > > There is no indication that 0.4.1 is not an ASF
> 

Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3

[sebb]

There is now a link to a potential download page, which is great.

However, the install page does not make it obvious that the 0.4.1
release is not an ASF release.
That information should be shown prominently at the start of the page,
not buried in a note near the end.

On Tue, 23 Apr 2024 at 16:07, Shawn Yang  wrote:
>
> I updated it in the PR
> https://github.com/apache/incubator-fury-site/pull/112. Sorry for my last
> reply, I forgot to put the PR link.
>
> On Tue, Apr 23, 2024 at 10:22 PM sebb  wrote:
>
> > On Tue, 23 Apr 2024 at 14:05, Shawn Yang  wrote:
> > >
> > > Hi Sebb,
> > >
> > > I  updated the content in the install doc and added notes that this is
> > not
> > > an ASF release.
> > >
> > > And added a download page for download and verify source release only.
> > > Currently this page is basically empty, but will be updated once this
> > vote
> > > is done, and updated
> > > to closer.lua according to download-scripts[1].
> > >
> > > The cross-links to each other are also added.
> >
> > I don't see these changes on the fury.apache.org website.
> > Are they published anywhere?
> >
> > > 1. https://infra.apache.org/release-download-pages.html#download-scripts
> > >
> > > Thanks again for pointing those issues out.
> > >
> > > -
> > > Best Regards,
> > > Chaokun Yang
> > >
> > > On Tue, Apr 23, 2024 at 8:22 PM sebb  wrote:
> > >
> > > > On Tue, 23 Apr 2024 at 13:08, tison  wrote:
> > > > >
> > > > > > They could fix the page now, while waiting for the release vote to
> > > > > complete.
> > > > >
> > > > > Make sense. At least remove the page/content now to indicate "no
> > Apache
> > > > > release" now. Then it won't be some "forth and back" updates. It's a
> > > > timing
> > > > > issue.
> > > > >
> > > > > > Note that the page needs more than just an update to version
> > numbers.
> > > > > > It needs closer.lua links to the source bundle, links to KEYS, sigs
> > > > > > and hashes, and verification instructions.
> > > > >
> > > > > Such an install page can be a simplified quick start page. I suppose
> > you
> > > > > refer to a download page like [1].
> > > > >
> > > > > [1] https://hadoop.apache.org/releases.html
> > > >
> > > > Yes, though ideally use closer.lua rather than closer.cgi.
> > > >
> > > > > And yes, Fury doesn't have a download page yet, and they should add
> > one.
> > > >
> > > > Agreed.
> > > >
> > > > > But in my experience it's different from a quickstart install page,
> > like
> > > > > [2] vs [3].
> > > >
> > > > Yes, but that should not be at the expense of a source download page.
> > > > It must be easy to find the source download.
> > > > The website and the announcement email must link to the official
> > download
> > > > page.
> > > >
> > > > The download and install pages could be cross-linked.
> > > >
> > > > > [2] https://opendal.apache.org/docs/quickstart#java-binding
> > > > > [3] https://opendal.apache.org/download
> > > > >
> > > > > Best,
> > > > > tison.
> > > > >
> > > > >
> > > > > sebb  于2024年4月23日周二 20:00写道：
> > > > >
> > > > > > On Tue, 23 Apr 2024 at 12:46, tison  wrote:
> > > > > > >
> > > > > > > > I would be very disappointed if the podling published the code
> > > > > > > > *knowing* that the download page is missing or incorrect.
> > > > > > >
> > > > > > > IIUC Fury will update the content and delete all the references
> > to
> > > > prior
> > > > > > > releases.
> > > > > >
> > > > > > Note that the page needs more than just an update to version
> > numbers.
> > > > > > It needs closer.lua links to the source bundle, links to KEYS, sigs
> > > > > > and hashes, and verification instrructions.
> > > > > >
> > > > > > > Or instead, Fury can keep these references and state clearly it's
> > > > prior
> > > > > > > releases.
> > > > > > >
> > > > > > > My comment above is with an assumption that prior releases ref
> > will
> > > > be
> > > > > > > removed. But if the PPMC wants to keep it, they should update the
> > > > > > > description.
> > > > > >
> > > > > > They could fix the page now, while waiting for the release vote to
> > > > > > complete.
> > > > > >
> > > > > > > Best,
> > > > > > > tison.
> > > > > > >
> > > > > > >
> > > > > > > sebb  于2024年4月23日周二 19:35写道：
> > > > > > >
> > > > > > > > On Tue, 23 Apr 2024 at 09:42, tison 
> > wrote:
> > > > > > > > >
> > > > > > > > > > There is no indication that 0.4.1 is not an ASF release.
> > > > > > > > >
> > > > > > > > > You may found that the group id is not org.apache.fury also.
> > > > > > > >
> > > > > > > > Whilst this is true, it is still not obvious that this is not
> > an
> > > > ASF
> > > > > > > > release; it is easy to overlook this minor detail.
> > > > > > > >
> > > > > > > > Indeed, there is no such indication for the GoLang, Javascript
> > or
> > > > Rust
> > > > > > > > binaries.
> > > > > > > >
> > > > > > > > > This is an intermediate state that we would update the
> > content
> > > > as:
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > >   org.apache.fury
> > > > 

Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3

[Shawn Yang]

Hi Justin,

Thanks for helping review this release.

The MemoryBufferWritableChannel[5] and  MockWritableChannel[6] was written
by me before we open-sourced Fury and
I submitted it to Ray in PR[8] ,which was planned to optimize zero-copy
serialization in Ray. I think it's OK to include it
here since both are written by me.

For files [1][2][3][4], could you give more details how those files include
code from OpenSumi. The OpenSumi core developer
bytemain[9] does commit some code to Fury, see his commits[10]. But I
talked to him offline, he said he didn't copy code from
OpenSumi.

For Fury ArrayAsList, could you give more details how this class is copied
from somewhere? It's just a simple wrapper for java
object arrays. Fury just implements some basic interfaces of java
Collection. I don't think we can write this class in another way
without following the  Java Collection interface. To reduce confusion, I
removed some methods which don't get invoked in PR[11].
But as tison said, this may not  resolve your concerns.

For the benchmark issue, thanks for pointing this out. We excluded the
benchmark directory in the source release, but didn't remove license
reference from LICENSE file. I'll fix this later.

1. /javascript/packages/fury/lib/gen/datetime.ts
2. /javascript/packages/fury/lib/gen/index.ts
3. /javascript/packages/fury/lib/fury.ts
4. /javascript/packages/fury/lib/classResolver.ts
5.
/java/fury-core/src/main/java/org/apache/fury/io/MemoryBufferWritableChannel.java
6. /java/fury-core/src/main/java/org/apache/fury/io/MockWritableChannel.java
7.
/java/fury-core/src/main/java/org/apache/fury/serializer/collection/ArrayAsList.java
8. https://github.com/ray-project/ray/pull/21256
9. https://github.com/bytemain
10. https://github.com/apache/incubator-fury/commits?author=bytemain
11. https://github.com/apache/incubator-fury/pull/1560


On Wed, Apr 24, 2024 at 11:40 AM Justin Mclean 
wrote:

> HI,
>
> Sorry, it’s -1 (binding) from me as it looks like there is additional
> third-party code without correct headers or mentioned in LICENSE.
>
> I checked:
> - incubating in name
> - signatures and hashes are fine
> - LICENSE has some issues (see below)
> - NOTICE is fine
> - It looks like some 3rd party code incorrectly has ASF headers (see below)
> - All source files have ASF headers
>
> For the LICENSE file:
> - there are several references to a benchmark directory, but it is not
> included in the release
> - there seems to be 3rd part code from OpenSumi here [1][2][3][4]
> - there seems to be code from Ray here [5][6]
> - this file may have been copied from somewhere [7]
>
> Kind Regards,
> Justin
>
> 1. /javascript/packages/fury/lib/gen/datetime.ts
> 2. /javascript/packages/fury/lib/gen/index.ts
> 3. /javascript/packages/fury/lib/fury.ts
> 4. /javascript/packages/fury/lib/classResolver.ts
> 5.
> /java/fury-core/src/main/java/org/apache/fury/io/MemoryBufferWritableChannel.java
> 6.
> /java/fury-core/src/main/java/org/apache/fury/io/MockWritableChannel.java
> 7.
> /java/fury-core/src/main/java/org/apache/fury/serializer/collection/ArrayAsList.java
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3

[tison]

Hi Justin,

Thanks for verifying potential compliance issue.

For 1-6 that you specify certain possible origins, do you have a report of
the overlap files? I try to search the content of datetime.ts in OpenSumi
but fail to find a result:

https://github.com/search?q=repo:opensumi/core%20DateSerializerGenerator=code

Also cc @chaokunyang and @weipeng if you're sure they're originally copied
from elsewhere.

For 7, the class seems no more than a thin wrapper of ArrayList that can be
written by any Java developer. The file author confirmed that it was
written by himself independently. Although Fury committers open [1] to make
some changes, I don't think it can resolve any issue in your description if
exist.

[1] https://github.com/apache/incubator-fury/pull/1560

Best,
tison.


Justin Mclean  于2024年4月24日周三 11:40写道：

> HI,
>
> Sorry, it’s -1 (binding) from me as it looks like there is additional
> third-party code without correct headers or mentioned in LICENSE.
>
> I checked:
> - incubating in name
> - signatures and hashes are fine
> - LICENSE has some issues (see below)
> - NOTICE is fine
> - It looks like some 3rd party code incorrectly has ASF headers (see below)
> - All source files have ASF headers
>
> For the LICENSE file:
> - there are several references to a benchmark directory, but it is not
> included in the release
> - there seems to be 3rd part code from OpenSumi here [1][2][3][4]
> - there seems to be code from Ray here [5][6]
> - this file may have been copied from somewhere [7]
>
> Kind Regards,
> Justin
>
> 1. /javascript/packages/fury/lib/gen/datetime.ts
> 2. /javascript/packages/fury/lib/gen/index.ts
> 3. /javascript/packages/fury/lib/fury.ts
> 4. /javascript/packages/fury/lib/classResolver.ts
> 5.
> /java/fury-core/src/main/java/org/apache/fury/io/MemoryBufferWritableChannel.java
> 6.
> /java/fury-core/src/main/java/org/apache/fury/io/MockWritableChannel.java
> 7.
> /java/fury-core/src/main/java/org/apache/fury/serializer/collection/ArrayAsList.java
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>