Re: [DISCUSS] Drop the incubator- prefix for podling's GitHub repo
> https://github.com/apache/incubator-fury/pull/1574/commits/2ac9d808af75d17c0ea74a9755fe165b13de15f2 > > That is, keep the first and most prominent uses in form "Apache Foo > (incubating)" and add a hyperlink to "incubating" to the DISCLAIMER. This > should be a shorter solution and at least as good as the incubator- prefix. > Ensuring the repo description contain "incubating" can help. > that looks good and compensates for the loss of incubating in the name easily. Wilfred - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Verification of download pages and links
On the one hand, we release sources. We should ensure that the source code is released (on our platform), or else the pivotal character "open source" is challenged. On the other hand, library users do always "download" the software with a dependency manager, and thus, a heavy download page may never be used. So it's not surprising PMC members would not want to do something unhelpful for the real users. Best, tison. tison 于2024年4月26日周五 02:01写道： > Here is a new situation for projects that may not carry source releases > heavily: [1] > > [1] https://github.com/apache/datafusion/pull/10233/files#r1579895024 > > They may not even maintain a download page, but just leverage > https://downloads.apache.org/. > > I suggest we rethink the form of distribution and whether it's necessary > to have a customized download page on the website. > > Best, > tison. > > > sebb 于2024年4月23日周二 20:47写道： > >> On Tue, 23 Apr 2024 at 13:25, tison wrote: >> > >> > Thanks for starting this thread and thanks a lot for verifying the >> download >> > page for a lot of podlings! >> > >> > For previewing a staging website, with .asf.yaml config, there is a way >> [1] >> > to do so self-served by any (P)PMC. And I agree that we should spread >> such >> > practices to every project. >> > >> > [1] >> > >> https://github.com/apache/infrastructure-asfyaml/blob/main/README.md#staging-a-web-site-preview-domain >> > >> > For example, to recommend every project's verifying release docs (like >> [2]) >> > have a check item to verify the (staged) download page. And instruct >> the RM >> > to build such a staged page. >> > >> > [2] https://opendal.apache.org/community/committers/verify >> >> VOTE emails will need to include: >> - a link to the preview site >> - checklist for reviewing the download page: >> as well as the required contents of the page itself, reviewers should >> check that it is easy to find the download page from the home page. >> >> > Best, >> > tison. >> > >> > >> > sebb 于2024年4月23日周二 19:52写道： >> > >> > > The primary mission of the ASF is to produce open SOURCE, so it seems >> > > to me that an essential part of a release is a download page with >> > > properly constituted links to the source bundle and the associated >> > > download verification files. >> > > >> > > However, no attention seems to be given to this aspect of a release, >> > > vital though it is. >> > > >> > > Obviously, the current download page cannot be updated with the >> > > details of an upcoming release, but there are ways of providing access >> > > to a staging website which shows how the page will look. >> > > >> > > Sebb >> > > >> > > - >> > > 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: Verification of download pages and links
Here is a new situation for projects that may not carry source releases heavily: [1] [1] https://github.com/apache/datafusion/pull/10233/files#r1579895024 They may not even maintain a download page, but just leverage https://downloads.apache.org/. I suggest we rethink the form of distribution and whether it's necessary to have a customized download page on the website. Best, tison. sebb 于2024年4月23日周二 20:47写道： > On Tue, 23 Apr 2024 at 13:25, tison wrote: > > > > Thanks for starting this thread and thanks a lot for verifying the > download > > page for a lot of podlings! > > > > For previewing a staging website, with .asf.yaml config, there is a way > [1] > > to do so self-served by any (P)PMC. And I agree that we should spread > such > > practices to every project. > > > > [1] > > > https://github.com/apache/infrastructure-asfyaml/blob/main/README.md#staging-a-web-site-preview-domain > > > > For example, to recommend every project's verifying release docs (like > [2]) > > have a check item to verify the (staged) download page. And instruct the > RM > > to build such a staged page. > > > > [2] https://opendal.apache.org/community/committers/verify > > VOTE emails will need to include: > - a link to the preview site > - checklist for reviewing the download page: > as well as the required contents of the page itself, reviewers should > check that it is easy to find the download page from the home page. > > > Best, > > tison. > > > > > > sebb 于2024年4月23日周二 19:52写道： > > > > > The primary mission of the ASF is to produce open SOURCE, so it seems > > > to me that an essential part of a release is a download page with > > > properly constituted links to the source bundle and the associated > > > download verification files. > > > > > > However, no attention seems to be given to this aspect of a release, > > > vital though it is. > > > > > > Obviously, the current download page cannot be updated with the > > > details of an upcoming release, but there are ways of providing access > > > to a staging website which shows how the page will look. > > > > > > Sebb > > > > > > - > > > 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: [VOTE] Release Apache StreamPark(Incubating) 2.1.4-rc1
hi tison: Thanks very much for your thorough checking work. You even found such a minor issue as the version number mismatch in the README.md file, We have created an issues[1] to tracking DISCLAIMER and README.md issue [1] https://github.com/apache/incubator-streampark/issues/3680 > This is not yet a clear and strong conclusion, so as an IPMC member, I encourage you to give your own feedback on such suggestions. > https://streampark.apache.org/community/release/how_to_release#4-complete-the-final-publishing-steps I will send an email to the community for discussing and resolving this issue. Best, Huajie Wang tison 于2024年4月25日周四 20:04写道： > +1 binding with a few suggestions. > > I checked: > > * Download links valid. > * Signature and checksum match. > * LICENSE, NOTICE and DISCLAIMER are included in both source and binary > releases. The content looks good to me. > * No binary files in the source release > > Below are two suggestions: > > 1. You may evaluate to add a DISCLAIM in the announcement template, which > is the same content as DISCLAIMER file in your sources. > > This is proposed at [1] and may related to your email template in 4.5 at > [2]. This is not yet a clear and strong conclusion, so as an IPMC member, I > encourage you to give your own feedback on such suggestions. > > [1] https://lists.apache.org/thread/3fosfz2jv0yhcrzt6mtwbwtxg4vtwxpy > [2] > > https://streampark.apache.org/community/release/how_to_release#4-complete-the-final-publishing-steps > > 2. You may write a dedicated README.md file for your binary release. It now > contains the same content as the main repo's, which is mismatched from the > binary release's content. > > For example, it has: > > ## QuickStart > - [Start with Docker](docker/README.md) > - [Start with Kubernetes](helm/README.md) > > which are missing in the binary release. I suppose you should talk about > how to use and configure the release artifacts instead. > > Best, > tison. > > > Shaokang Lv 于2024年4月25日周四 16:01写道： > > > Hello Incubator Community: > > > > This is a call for a vote to release Apache StreamPark(Incubating) > version > > 2.1.4-RC1. > > The Apache StreamPark community has voted on and approved a proposal to > > release Apache StreamPark(Incubating) version 2.1.4-RC1. > > We now kindly request the Incubator PMC members review and vote on this > > incubator release. > > Apache StreamPark, Make stream processing easier! Easy-to-use streaming > > application development framework and operation platform. > > > > StreamPark community vote thread: > > https://lists.apache.org/thread/v4yx0f0xgmr53g795cgn4ppblytqhvqh > > > > Vote result thread: > > https://lists.apache.org/thread/f85yn1j6y6k9fcmc8qvl7ltob706twcs > > > > The release candidate: > > https://dist.apache.org/repos/dist/dev/incubator/streampark/2.1.4-RC1/ > > > > Git tag for the release: > > https://github.com/apache/incubator-streampark/releases/tag/v2.1.4-rc1 > > > > The artifacts signed with PGP key [D38791FF], corresponding to [ > > lvshaok...@apache.org], that can be found in keys file: > > https://downloads.apache.org/incubator/streampark/KEYS > > > > The vote will be open for at least 72 hours or until the necessary number > > of votes are reached. > > > > Please vote accordingly: > > [ ] +1 approve > > [ ] +0 no opinion > > [ ] -1 disapprove with the reason > > > > More detailed checklist please refer: > > • > > > https://cwiki.apache.org/confluence/display/INCUBATOR/Incubator+Release+Checklist > > > > Steps to validate the release， Please refer to: > > • https://www.apache.org/info/verification.html > > • https://streampark.apache.org/community/release/how_to_verify_release > > > > > > How to Build: > > > > 1) clone source code: > > > git clone -b v2.1.4-rc1 g...@github.com:apache/incubator-streampark.git > > > > 2) build project: > > > cd incubator-streampark && sh ./build.sh > > > > > > Thanks, > > > > On behalf of Apache StreamPark(Incubating) community > > > > > > Best, > > Shaokang Lv > > >
Re: Missing Incubator disclaimer text
On Thu, 25 Apr 2024 at 16:56, tison wrote: > > Thanks for your explanation and good catch. I sent [1] to improve the case > here and it should be resolved now. > > [1] https://github.com/apache/incubator-streampark-website/pull/351 > > To search other pages, perhaps you can try to read the /sitemap.xml file to > find pages. Although I can see some hidden pages are included in > StreamPark's sitemap.xml, it's an issue of the project, not the approach to > walk through all the pages by sitemap.xml. The intention is to check a few pages other than the main page. If any pages don't have disclaimers, then it is likely that there are others without disclaimers. Once alerted to this, it is expected that podlings will take responsibility to follow through and check all their pages. Note also that not all podlings have a sitemap.xml file > Best, > tison. > > > sebb 于2024年4月25日周四 22:43写道： > > > On Thu, 25 Apr 2024 at 15:18, tison wrote: > > > > > > > The array is a list of pages in which the disclaimer could not be > > found. > > > > > > I do a quick check for the podlings I'm familiar with: > > > > > > For StreamPark, it reports: > > >"disclaimers": [ > > > 14, > > > [ > > > "https://streampark.incubator.apache.org/team;, > > > "https://streampark.incubator.apache.org/user; > > > ] > > > ] > > > But both pages should have the disclaimer at the footer. > > > > The checker does not currently support pages generated by Javascript. > > > > Those pages display as completely empty if Javascript is not enabled; > > that is not very friendly. > > > > > > > > For Fury, Answer, and HoraeDB, the result seems correct. It reports that > > > HoraeDB doesn't have the DISCLAIMER on all of its pages; this is the > > > case. I'll reach out to them to resolve this. > > > > > > I mentor a new podling GraphAr, which seems missing in the report. > > > > > > Best, > > > tison. > > > > > > > > > sebb 于2024年4月25日周四 22:11写道： > > > > > > > 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. > > > > > > > > I updated the Whimsy site scanner to report on top-level links to > > > > podling pages which don't appear to have the disclaimer. > > > > This does not yet appear in the Whimsy podlings report, but the raw > > > > data is in the JSON file at > > > > > > > > https://whimsy.apache.org/public/pods-scan.json > > > > > > > > Search for "disclaimers", e.g. > > > > > > > > "disclaimers": [ > > > > 1, > > > > [ > > > > "https://hugegraph.incubator.apache.org/docs/;, > > > > " > > https://hugegraph.incubator.apache.org/docs/download/download/;, > > > > "https://hugegraph.incubator.apache.org/community/; > > > > ] > > > > > > > > The initial number (1 above) is the count of references that do appear > > > > to have the disclaimer. > > > > The array is a list of pages in which the disclaimer could not be > > found. > > > > > > > > In the above case, I think they all need the disclaimer, but there may > > > > be some cases where it is not appropriate. > > > > > > > > > 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
Re: [DISCUSS] Drop the incubator- prefix for podling's GitHub repo
Hi Willem, Good point. I suppose the current incubator- prefix doesn't give more information than the "incubator" words itself. Thus, trying to merge the inputs above, I made a third candidate: * https://github.com/apache/incubator-fury/pull/1574/commits/2ac9d808af75d17c0ea74a9755fe165b13de15f2 That is, keep the first and most prominent uses in form "Apache Foo (incubating)" and add a hyperlink to "incubating" to the DISCLAIMER. This should be a shorter solution and at least as good as the incubator- prefix. Ensuring the repo description contain "incubating" can help. I'm going to prepare a patch on the incubator website to review the wording we'd use before next week. Best, tison. Willem Jiang 于2024年4月25日周四 17:02写道： > Just have a comment on the Github repo descriptions of Incubating projects: > " We need to have word of (Incubating) in the repo description." > It can be updated by editing the file of .asf.yaml in the repo. > > Willem Jiang > > On Tue, Apr 23, 2024 at 9:23 AM 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: Missing Incubator disclaimer text
Thanks for your explanation and good catch. I sent [1] to improve the case here and it should be resolved now. [1] https://github.com/apache/incubator-streampark-website/pull/351 To search other pages, perhaps you can try to read the /sitemap.xml file to find pages. Although I can see some hidden pages are included in StreamPark's sitemap.xml, it's an issue of the project, not the approach to walk through all the pages by sitemap.xml. Best, tison. sebb 于2024年4月25日周四 22:43写道： > On Thu, 25 Apr 2024 at 15:18, tison wrote: > > > > > The array is a list of pages in which the disclaimer could not be > found. > > > > I do a quick check for the podlings I'm familiar with: > > > > For StreamPark, it reports: > >"disclaimers": [ > > 14, > > [ > > "https://streampark.incubator.apache.org/team;, > > "https://streampark.incubator.apache.org/user; > > ] > > ] > > But both pages should have the disclaimer at the footer. > > The checker does not currently support pages generated by Javascript. > > Those pages display as completely empty if Javascript is not enabled; > that is not very friendly. > > > > > For Fury, Answer, and HoraeDB, the result seems correct. It reports that > > HoraeDB doesn't have the DISCLAIMER on all of its pages; this is the > > case. I'll reach out to them to resolve this. > > > > I mentor a new podling GraphAr, which seems missing in the report. > > > > Best, > > tison. > > > > > > sebb 于2024年4月25日周四 22:11写道： > > > > > 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. > > > > > > I updated the Whimsy site scanner to report on top-level links to > > > podling pages which don't appear to have the disclaimer. > > > This does not yet appear in the Whimsy podlings report, but the raw > > > data is in the JSON file at > > > > > > https://whimsy.apache.org/public/pods-scan.json > > > > > > Search for "disclaimers", e.g. > > > > > > "disclaimers": [ > > > 1, > > > [ > > > "https://hugegraph.incubator.apache.org/docs/;, > > > " > https://hugegraph.incubator.apache.org/docs/download/download/;, > > > "https://hugegraph.incubator.apache.org/community/; > > > ] > > > > > > The initial number (1 above) is the count of references that do appear > > > to have the disclaimer. > > > The array is a list of pages in which the disclaimer could not be > found. > > > > > > In the above case, I think they all need the disclaimer, but there may > > > be some cases where it is not appropriate. > > > > > > > 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 > > > > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Missing Incubator disclaimer text
On Thu, 25 Apr 2024 at 15:18, tison wrote: > > > The array is a list of pages in which the disclaimer could not be found. > > I do a quick check for the podlings I'm familiar with: > > For StreamPark, it reports: >"disclaimers": [ > 14, > [ > "https://streampark.incubator.apache.org/team;, > "https://streampark.incubator.apache.org/user; > ] > ] > But both pages should have the disclaimer at the footer. The checker does not currently support pages generated by Javascript. Those pages display as completely empty if Javascript is not enabled; that is not very friendly. > > For Fury, Answer, and HoraeDB, the result seems correct. It reports that > HoraeDB doesn't have the DISCLAIMER on all of its pages; this is the > case. I'll reach out to them to resolve this. > > I mentor a new podling GraphAr, which seems missing in the report. > > Best, > tison. > > > sebb 于2024年4月25日周四 22:11写道： > > > 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. > > > > I updated the Whimsy site scanner to report on top-level links to > > podling pages which don't appear to have the disclaimer. > > This does not yet appear in the Whimsy podlings report, but the raw > > data is in the JSON file at > > > > https://whimsy.apache.org/public/pods-scan.json > > > > Search for "disclaimers", e.g. > > > > "disclaimers": [ > > 1, > > [ > > "https://hugegraph.incubator.apache.org/docs/;, > > "https://hugegraph.incubator.apache.org/docs/download/download/;, > > "https://hugegraph.incubator.apache.org/community/; > > ] > > > > The initial number (1 above) is the count of references that do appear > > to have the disclaimer. > > The array is a list of pages in which the disclaimer could not be found. > > > > In the above case, I think they all need the disclaimer, but there may > > be some cases where it is not appropriate. > > > > > 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 > > > > > > > > > > > > - > > 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: Missing Incubator disclaimer text
> The array is a list of pages in which the disclaimer could not be found. I do a quick check for the podlings I'm familiar with: For StreamPark, it reports: "disclaimers": [ 14, [ "https://streampark.incubator.apache.org/team;, "https://streampark.incubator.apache.org/user; ] ] But both pages should have the disclaimer at the footer. For Fury, Answer, and HoraeDB, the result seems correct. It reports that HoraeDB doesn't have the DISCLAIMER on all of its pages; this is the case. I'll reach out to them to resolve this. I mentor a new podling GraphAr, which seems missing in the report. Best, tison. sebb 于2024年4月25日周四 22:11写道： > 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. > > I updated the Whimsy site scanner to report on top-level links to > podling pages which don't appear to have the disclaimer. > This does not yet appear in the Whimsy podlings report, but the raw > data is in the JSON file at > > https://whimsy.apache.org/public/pods-scan.json > > Search for "disclaimers", e.g. > > "disclaimers": [ > 1, > [ > "https://hugegraph.incubator.apache.org/docs/;, > "https://hugegraph.incubator.apache.org/docs/download/download/;, > "https://hugegraph.incubator.apache.org/community/; > ] > > The initial number (1 above) is the count of references that do appear > to have the disclaimer. > The array is a list of pages in which the disclaimer could not be found. > > In the above case, I think they all need the disclaimer, but there may > be some cases where it is not appropriate. > > > 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 > > > > > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Missing Incubator disclaimer text
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. I updated the Whimsy site scanner to report on top-level links to podling pages which don't appear to have the disclaimer. This does not yet appear in the Whimsy podlings report, but the raw data is in the JSON file at https://whimsy.apache.org/public/pods-scan.json Search for "disclaimers", e.g. "disclaimers": [ 1, [ "https://hugegraph.incubator.apache.org/docs/;, "https://hugegraph.incubator.apache.org/docs/download/download/;, "https://hugegraph.incubator.apache.org/community/; ] The initial number (1 above) is the count of references that do appear to have the disclaimer. The array is a list of pages in which the disclaimer could not be found. In the above case, I think they all need the disclaimer, but there may be some cases where it is not appropriate. > 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 > > > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Helping podlings to follow our culture and policy
Hi, This is mainly for IPMC members. But I think it's suitable to discuss publicly also. I suggest we actively give positive feedback on podlings making progress on improving themselves. We're all volunteers. TBH, most IPMC members do not participate in the development of podling too much. So, it's common for an IPMC member to know little about the background and motivation of an "obvious mistake". I remember a podling failed to proceed with an argument: "The incubator spends more energy on failing us than helping us". This alarms me. Although I believe all the IPMC members are helping ensure podlings follow our cultures and policy and later become well-deserved ASF TLPs, expression, tone, and sympathy can significantly affect how podlings interpret feedback. I highly respect and encourage IPMC members to share their concerns and give suggestions to podlings to align themselves with the ASF way. However, keeping the feedback concrete, objective, and actionable as much as possible can greatly help the feedback loop and give a positive impression. The ASF is growing and extending new members and projects continuously. We're always meeting people who lack the background we may feed intuitively because we have years of experience here. We're peers in the community and help each other. And while the IPMC mainly focuses on the community, today I learned the CoPDoC abbr. in the ASF that is: > (Co)mmunity - You can join us via our mailing list, issue trackers, discussions page to interact with community members, and share vision and knowledge > (P)roject - a clear vision and consensus are needed > (Do)cumentation - without it, the stuff remains only in the minds of the authors > (C)ode - discussion goes nowhere without code The PPMC, committers, and contributors to the podling are the workhorse for creating the project, the document, and the code. The ASF exists to provide software for the public good [1]. So, I highly respect people who create the software (mainly code and projects), too. [1] https://www.apache.org/foundation/ Best, tison.
Re: [VOTE] Release Apache StreamPark(Incubating) 2.1.4-rc1
+1 binding with a few suggestions. I checked: * Download links valid. * Signature and checksum match. * LICENSE, NOTICE and DISCLAIMER are included in both source and binary releases. The content looks good to me. * No binary files in the source release Below are two suggestions: 1. You may evaluate to add a DISCLAIM in the announcement template, which is the same content as DISCLAIMER file in your sources. This is proposed at [1] and may related to your email template in 4.5 at [2]. This is not yet a clear and strong conclusion, so as an IPMC member, I encourage you to give your own feedback on such suggestions. [1] https://lists.apache.org/thread/3fosfz2jv0yhcrzt6mtwbwtxg4vtwxpy [2] https://streampark.apache.org/community/release/how_to_release#4-complete-the-final-publishing-steps 2. You may write a dedicated README.md file for your binary release. It now contains the same content as the main repo's, which is mismatched from the binary release's content. For example, it has: ## QuickStart - [Start with Docker](docker/README.md) - [Start with Kubernetes](helm/README.md) which are missing in the binary release. I suppose you should talk about how to use and configure the release artifacts instead. Best, tison. Shaokang Lv 于2024年4月25日周四 16:01写道： > Hello Incubator Community: > > This is a call for a vote to release Apache StreamPark(Incubating) version > 2.1.4-RC1. > The Apache StreamPark community has voted on and approved a proposal to > release Apache StreamPark(Incubating) version 2.1.4-RC1. > We now kindly request the Incubator PMC members review and vote on this > incubator release. > Apache StreamPark, Make stream processing easier! Easy-to-use streaming > application development framework and operation platform. > > StreamPark community vote thread: > https://lists.apache.org/thread/v4yx0f0xgmr53g795cgn4ppblytqhvqh > > Vote result thread: > https://lists.apache.org/thread/f85yn1j6y6k9fcmc8qvl7ltob706twcs > > The release candidate: > https://dist.apache.org/repos/dist/dev/incubator/streampark/2.1.4-RC1/ > > Git tag for the release: > https://github.com/apache/incubator-streampark/releases/tag/v2.1.4-rc1 > > The artifacts signed with PGP key [D38791FF], corresponding to [ > lvshaok...@apache.org], that can be found in keys file: > https://downloads.apache.org/incubator/streampark/KEYS > > The vote will be open for at least 72 hours or until the necessary number > of votes are reached. > > Please vote accordingly: > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove with the reason > > More detailed checklist please refer: > • > https://cwiki.apache.org/confluence/display/INCUBATOR/Incubator+Release+Checklist > > Steps to validate the release， Please refer to: > • https://www.apache.org/info/verification.html > • https://streampark.apache.org/community/release/how_to_verify_release > > > How to Build: > > 1) clone source code: > > git clone -b v2.1.4-rc1 g...@github.com:apache/incubator-streampark.git > > 2) build project: > > cd incubator-streampark && sh ./build.sh > > > Thanks, > > On behalf of Apache StreamPark(Incubating) community > > > Best, > Shaokang Lv >
[CANCEL][VOTE] Release Apache Fury(incubating) v0.5.0-rc3
Hi, The release for Apache Fury(incubating) v0.5.0-rc3 is canceled. We didn't include the benchmark code in the source release, but the LICENSE file did contain the reference to benchmark code. This has been fixed in [1] 1. https://github.com/apache/incubator-fury/pull/1562 We will propose a new release candidate in theFury community later. Thanks everyone for helping review this release. Best regards, Chaokun Yang
Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3
Hi tison, My previous reply is a little confusing. What the "we don't release furyjs in 0.5.0" means is that we don't upload release bundles to npm in this release. Best, Chaokun Yang On Thu, Apr 25, 2024 at 5:36 PM tison wrote: > Let me first summarize the result of the feedback on LICENSE issues: > > > - there are several references to a benchmark directory, but it is not > included in the release > > This is correct. We made [10] to address it. And We're preparing a new > release candidate. > > [10] https://github.com/apache/incubator-fury/pull/1562 > > > - there seems to be 3rd part code from OpenSumi here [1][2][3][4] > > This is false positive. OpenSumi's release bundle contains the code from > Fury. The origin comes from Fury. > > > - there seems to be code from Ray here [5][6] > > This is false positive. Shawn owns the code and they are "Licensed to the > Apache Software Foundation (ASF) under one or more contributor license > agreements." > > > - this file may have been copied from somewhere [7] > > This is false positive. The content of ArrayAsList is shared above. I > suppose most Java developers would argue that it's a trivial class. Also, > there is no evidence to show other origins possibility. > > To Shawn, > > > We can cooperate with OpenSumi after we make the first formal release of > furyjs under ASF later. > > Although this can be a good way to go, I notice that in this RC the tarball > packages furyjs' code: > > 0.5.0-rc3/apache-fury-incubating-0.5.0-src/javascript > > I'd like to know the details about "we don't release furyjs in 0.5.0" > because you seem to release furyjs' sources in 0.5.0. > > Best, > tison. > > > Shawn Yang 于2024年4月25日周四 17:16写道： > > > Hi tison, > > > > Thanks for the suggestion, we don't release furyjs in 0.5.0. > > > > We can cooperate with OpenSumi after we make the first formal release of > > furyjs > > under ASF later. > > > > Best, > > Chaokun > > > > On Thu, Apr 25, 2024 at 5:11 PM tison wrote: > > > > > Hi Shawn, > > > > > > Thanks for sharing the finding. I can see the dependency from OpenSumi > to > > > Fury as in [1] now. > > > > > > [1] https://github.com/search?q=repo:opensumi/core%20fury=code > > > > > > After we make the first formal release, we can cooperate with OpenSumi > to > > > upgrade to an incubating release and thus update the mention in their > > docs > > > to Apache Fury also, like [2][3]. > > > > > > [2] https://github.com/GreptimeTeam/greptimedb/pull/2653 > > > [3] https://github.com/GreptimeTeam/greptimedb/pull/3168 > > > > > > Best, > > > tison. > > > > > > > > > Shawn Yang 于2024年4月25日周四 17:04写道： > > > > > > > Hi Justin, > > > > > > > > Thanks for sharing this tool. I checked the code in Fury with this > > tool. > > > > > > > > Here is the result: > > > > 1) [5][6] are osscan results. > > > > 2) Those files has duplication with package/lib/worker-host.js in > > > > opensumi[7] > > > > > > > > Opensumi relies on furyjs, so it packaged the code in apache fury > into > > > its > > > > release bundle. > > > > As you can see from the opensumi code repository[8]. There is no such > > > > worker-host.js file, > > > > It's a file generated at opensum build process, which packaged apache > > > > furyjs code into their bundle. > > > > > > > > So I think this is not an issue in fury. > > > > > > > > Do you have further issues? If not, I'll close this vote and start a > > new > > > > release candidate 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 > > > > > > > > > > > > > > https://github.com/apache/incubator-fury/assets/12445254/cfa0fb06-bf23-468d-bf76-f9b106467611 > > > > 6. > > > > > > > > > > > > > > https://github.com/apache/incubator-fury/assets/12445254/7698a87d-ffd9-4400-9a79-a2f27f191c1d > > > > 7. https://www.npmjs.com/package/%40opensumi/ide-extension > > > > 8. https://github.com/opensumi/core/ > > > > > > > > -- > > > > Best regards, > > > > Chaokun Yang > > > > > > > > On Thu, Apr 25, 2024 at 1:52 PM tison wrote: > > > > > > > > > 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写道： > >
Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3
Let me first summarize the result of the feedback on LICENSE issues: > - there are several references to a benchmark directory, but it is not included in the release This is correct. We made [10] to address it. And We're preparing a new release candidate. [10] https://github.com/apache/incubator-fury/pull/1562 > - there seems to be 3rd part code from OpenSumi here [1][2][3][4] This is false positive. OpenSumi's release bundle contains the code from Fury. The origin comes from Fury. > - there seems to be code from Ray here [5][6] This is false positive. Shawn owns the code and they are "Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements." > - this file may have been copied from somewhere [7] This is false positive. The content of ArrayAsList is shared above. I suppose most Java developers would argue that it's a trivial class. Also, there is no evidence to show other origins possibility. To Shawn, > We can cooperate with OpenSumi after we make the first formal release of furyjs under ASF later. Although this can be a good way to go, I notice that in this RC the tarball packages furyjs' code: 0.5.0-rc3/apache-fury-incubating-0.5.0-src/javascript I'd like to know the details about "we don't release furyjs in 0.5.0" because you seem to release furyjs' sources in 0.5.0. Best, tison. Shawn Yang 于2024年4月25日周四 17:16写道： > Hi tison, > > Thanks for the suggestion, we don't release furyjs in 0.5.0. > > We can cooperate with OpenSumi after we make the first formal release of > furyjs > under ASF later. > > Best, > Chaokun > > On Thu, Apr 25, 2024 at 5:11 PM tison wrote: > > > Hi Shawn, > > > > Thanks for sharing the finding. I can see the dependency from OpenSumi to > > Fury as in [1] now. > > > > [1] https://github.com/search?q=repo:opensumi/core%20fury=code > > > > After we make the first formal release, we can cooperate with OpenSumi to > > upgrade to an incubating release and thus update the mention in their > docs > > to Apache Fury also, like [2][3]. > > > > [2] https://github.com/GreptimeTeam/greptimedb/pull/2653 > > [3] https://github.com/GreptimeTeam/greptimedb/pull/3168 > > > > Best, > > tison. > > > > > > Shawn Yang 于2024年4月25日周四 17:04写道： > > > > > Hi Justin, > > > > > > Thanks for sharing this tool. I checked the code in Fury with this > tool. > > > > > > Here is the result: > > > 1) [5][6] are osscan results. > > > 2) Those files has duplication with package/lib/worker-host.js in > > > opensumi[7] > > > > > > Opensumi relies on furyjs, so it packaged the code in apache fury into > > its > > > release bundle. > > > As you can see from the opensumi code repository[8]. There is no such > > > worker-host.js file, > > > It's a file generated at opensum build process, which packaged apache > > > furyjs code into their bundle. > > > > > > So I think this is not an issue in fury. > > > > > > Do you have further issues? If not, I'll close this vote and start a > new > > > release candidate 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 > > > > > > > > > https://github.com/apache/incubator-fury/assets/12445254/cfa0fb06-bf23-468d-bf76-f9b106467611 > > > 6. > > > > > > > > > https://github.com/apache/incubator-fury/assets/12445254/7698a87d-ffd9-4400-9a79-a2f27f191c1d > > > 7. https://www.npmjs.com/package/%40opensumi/ide-extension > > > 8. https://github.com/opensumi/core/ > > > > > > -- > > > Best regards, > > > Chaokun Yang > > > > > > On Thu, Apr 25, 2024 at 1:52 PM tison wrote: > > > > > > > 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 > > > > > >
Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3
> close this vote and start a new release candidate later. There is no blocker to cancel this vote now. You can test the new release packaging logics correctly exclude benchmark license info and we're ready to make the next RC. To cancel a vote. You can send a reply to this thread with a replaced title: [CANCEL][VOTE] Release Apache Fury(incubating) v0.5.0-rc3 This release has been canceled. Due to ... Best, tison. tison 于2024年4月25日周四 17:10写道： > Hi Shawn, > > Thanks for sharing the finding. I can see the dependency from OpenSumi to > Fury as in [1] now. > > [1] https://github.com/search?q=repo:opensumi/core%20fury=code > > After we make the first formal release, we can cooperate with OpenSumi to > upgrade to an incubating release and thus update the mention in their docs > to Apache Fury also, like [2][3]. > > [2] https://github.com/GreptimeTeam/greptimedb/pull/2653 > [3] https://github.com/GreptimeTeam/greptimedb/pull/3168 > > Best, > tison. > > > Shawn Yang 于2024年4月25日周四 17:04写道： > >> Hi Justin, >> >> Thanks for sharing this tool. I checked the code in Fury with this tool. >> >> Here is the result: >> 1) [5][6] are osscan results. >> 2) Those files has duplication with package/lib/worker-host.js in >> opensumi[7] >> >> Opensumi relies on furyjs, so it packaged the code in apache fury into its >> release bundle. >> As you can see from the opensumi code repository[8]. There is no such >> worker-host.js file, >> It's a file generated at opensum build process, which packaged apache >> furyjs code into their bundle. >> >> So I think this is not an issue in fury. >> >> Do you have further issues? If not, I'll close this vote and start a new >> release candidate 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 >> >> https://github.com/apache/incubator-fury/assets/12445254/cfa0fb06-bf23-468d-bf76-f9b106467611 >> 6. >> >> https://github.com/apache/incubator-fury/assets/12445254/7698a87d-ffd9-4400-9a79-a2f27f191c1d >> 7. https://www.npmjs.com/package/%40opensumi/ide-extension >> 8. https://github.com/opensumi/core/ >> >> -- >> Best regards, >> Chaokun Yang >> >> On Thu, Apr 25, 2024 at 1:52 PM tison wrote: >> >> > 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: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3
Hi tison, Thanks for the suggestion, we don't release furyjs in 0.5.0. We can cooperate with OpenSumi after we make the first formal release of furyjs under ASF later. Best, Chaokun On Thu, Apr 25, 2024 at 5:11 PM tison wrote: > Hi Shawn, > > Thanks for sharing the finding. I can see the dependency from OpenSumi to > Fury as in [1] now. > > [1] https://github.com/search?q=repo:opensumi/core%20fury=code > > After we make the first formal release, we can cooperate with OpenSumi to > upgrade to an incubating release and thus update the mention in their docs > to Apache Fury also, like [2][3]. > > [2] https://github.com/GreptimeTeam/greptimedb/pull/2653 > [3] https://github.com/GreptimeTeam/greptimedb/pull/3168 > > Best, > tison. > > > Shawn Yang 于2024年4月25日周四 17:04写道： > > > Hi Justin, > > > > Thanks for sharing this tool. I checked the code in Fury with this tool. > > > > Here is the result: > > 1) [5][6] are osscan results. > > 2) Those files has duplication with package/lib/worker-host.js in > > opensumi[7] > > > > Opensumi relies on furyjs, so it packaged the code in apache fury into > its > > release bundle. > > As you can see from the opensumi code repository[8]. There is no such > > worker-host.js file, > > It's a file generated at opensum build process, which packaged apache > > furyjs code into their bundle. > > > > So I think this is not an issue in fury. > > > > Do you have further issues? If not, I'll close this vote and start a new > > release candidate 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 > > > > > https://github.com/apache/incubator-fury/assets/12445254/cfa0fb06-bf23-468d-bf76-f9b106467611 > > 6. > > > > > https://github.com/apache/incubator-fury/assets/12445254/7698a87d-ffd9-4400-9a79-a2f27f191c1d > > 7. https://www.npmjs.com/package/%40opensumi/ide-extension > > 8. https://github.com/opensumi/core/ > > > > -- > > Best regards, > > Chaokun Yang > > > > On Thu, Apr 25, 2024 at 1:52 PM tison wrote: > > > > > 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: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3
Hi Shawn, Thanks for sharing the finding. I can see the dependency from OpenSumi to Fury as in [1] now. [1] https://github.com/search?q=repo:opensumi/core%20fury=code After we make the first formal release, we can cooperate with OpenSumi to upgrade to an incubating release and thus update the mention in their docs to Apache Fury also, like [2][3]. [2] https://github.com/GreptimeTeam/greptimedb/pull/2653 [3] https://github.com/GreptimeTeam/greptimedb/pull/3168 Best, tison. Shawn Yang 于2024年4月25日周四 17:04写道： > Hi Justin, > > Thanks for sharing this tool. I checked the code in Fury with this tool. > > Here is the result: > 1) [5][6] are osscan results. > 2) Those files has duplication with package/lib/worker-host.js in > opensumi[7] > > Opensumi relies on furyjs, so it packaged the code in apache fury into its > release bundle. > As you can see from the opensumi code repository[8]. There is no such > worker-host.js file, > It's a file generated at opensum build process, which packaged apache > furyjs code into their bundle. > > So I think this is not an issue in fury. > > Do you have further issues? If not, I'll close this vote and start a new > release candidate 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 > > https://github.com/apache/incubator-fury/assets/12445254/cfa0fb06-bf23-468d-bf76-f9b106467611 > 6. > > https://github.com/apache/incubator-fury/assets/12445254/7698a87d-ffd9-4400-9a79-a2f27f191c1d > 7. https://www.npmjs.com/package/%40opensumi/ide-extension > 8. https://github.com/opensumi/core/ > > -- > Best regards, > Chaokun Yang > > On Thu, Apr 25, 2024 at 1:52 PM tison wrote: > > > 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: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3
Hi Justin, Thanks for sharing this tool. I checked the code in Fury with this tool. Here is the result: 1) [5][6] are osscan results. 2) Those files has duplication with package/lib/worker-host.js in opensumi[7] Opensumi relies on furyjs, so it packaged the code in apache fury into its release bundle. As you can see from the opensumi code repository[8]. There is no such worker-host.js file, It's a file generated at opensum build process, which packaged apache furyjs code into their bundle. So I think this is not an issue in fury. Do you have further issues? If not, I'll close this vote and start a new release candidate 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 https://github.com/apache/incubator-fury/assets/12445254/cfa0fb06-bf23-468d-bf76-f9b106467611 6. https://github.com/apache/incubator-fury/assets/12445254/7698a87d-ffd9-4400-9a79-a2f27f191c1d 7. https://www.npmjs.com/package/%40opensumi/ide-extension 8. https://github.com/opensumi/core/ -- Best regards, Chaokun Yang On Thu, Apr 25, 2024 at 1:52 PM tison wrote: > 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
Just have a comment on the Github repo descriptions of Incubating projects: " We need to have word of (Incubating) in the repo description." It can be updated by editing the file of .asf.yaml in the repo. Willem Jiang On Tue, Apr 23, 2024 at 9:23 AM 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
[VOTE] Release Apache StreamPark(Incubating) 2.1.4-rc1
Hello Incubator Community: This is a call for a vote to release Apache StreamPark(Incubating) version 2.1.4-RC1. The Apache StreamPark community has voted on and approved a proposal to release Apache StreamPark(Incubating) version 2.1.4-RC1. We now kindly request the Incubator PMC members review and vote on this incubator release. Apache StreamPark, Make stream processing easier! Easy-to-use streaming application development framework and operation platform. StreamPark community vote thread: https://lists.apache.org/thread/v4yx0f0xgmr53g795cgn4ppblytqhvqh Vote result thread: https://lists.apache.org/thread/f85yn1j6y6k9fcmc8qvl7ltob706twcs The release candidate: https://dist.apache.org/repos/dist/dev/incubator/streampark/2.1.4-RC1/ Git tag for the release: https://github.com/apache/incubator-streampark/releases/tag/v2.1.4-rc1 The artifacts signed with PGP key [D38791FF], corresponding to [ lvshaok...@apache.org], that can be found in keys file: https://downloads.apache.org/incubator/streampark/KEYS The vote will be open for at least 72 hours or until the necessary number of votes are reached. Please vote accordingly: [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove with the reason More detailed checklist please refer: • https://cwiki.apache.org/confluence/display/INCUBATOR/Incubator+Release+Checklist Steps to validate the release， Please refer to: • https://www.apache.org/info/verification.html • https://streampark.apache.org/community/release/how_to_verify_release How to Build: 1) clone source code: > git clone -b v2.1.4-rc1 g...@github.com:apache/incubator-streampark.git 2) build project: > cd incubator-streampark && sh ./build.sh Thanks, On behalf of Apache StreamPark(Incubating) community Best, Shaokang Lv
Re: [DISCUSS] Drop the incubator- prefix for podling's GitHub repo
To preview the render result I made https://github.com/apache/incubator-fury/pull/1574 to showcase. You can head to https://github.com/apache/incubator-fury/tree/tisonkun-patch-1 to see the render version. I made two candidates: 1. Inline the DISCLAIMER with an IMPORTANT callout 2. Add a badge with the word "INCUBATING" and link to the DISCLAIM file. IMO 1 doesn't take too much place and 2 is not quite clear to be found by readers. > 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 I agree. We can use the expression on Incubator guides, but we'd still better provide some examples so that podlings can easily follow. Best, tison. Justin Mclean 于2024年4月25日周四 13:46写道： > 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 > >
