Re: What is sufficient Incubation notification for Git repos?
Hi, This is a discussed topic at [1]. [1] https://lists.apache.org/thread/kxvdkrf8g8yr6hww1n08r21xdy67y4ok I agree on the '(Incubating)' in the repo description part. For the disclaimer part, [1] first had: > I would be for requiring the incubator disclaimer text in the project's > README. But later Justin suggested [2]: [2] https://lists.apache.org/thread/n1otdvff6fw14xmpjwlc8xy40dh0grms > 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. I made a few preview candidates at [3]. [3] https://github.com/apache/incubator-fury/tree/tisonkun-patch-1. So now, I think we can evaluate these opinions at HoraeDB's ticket [4] to make a reference. [4] https://issues.apache.org/jira/browse/INFRA-25790 I can see that either: 1. Inline the DISCLAIMER content in the README; or, 2. Add a link to the '(Incubating)' words to the DISCLAIMER. should work. cc dev@horaedb.a.o for their information and participation. Please keep general@incubator.o.o in cc. Best, tison. Justin Mclean 于2024年5月24日周五 07:52写道： > Hi, > > > Whilst the DISCLAIMER file is helpful, and having '(Incubating)' in > > the repo description/About, neither of these are all that obvious. > > Yep, that should be done. > > > It seems to me that the repo README should also contain the Incubator > > disclaimer, as is done on website pages. > > That is also my expectation. > > See for instance: > https://issues.apache.org/jira/browse/INFRA-25790 > > Kind Regards, > Justin > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [DISCUSS] GravitinoProposal to the incubator
+1 looks promising and I believe this initial group and the mentors :D Best, tison. 俊平堵 于2024年5月23日周四 22:53写道： > +1. Thanks JB for the proposal. > Unified Data Catalog is more and more important in the data and AI domain. > Project gravitino should be the first one in ASF to address this area. > The project is very active and has outstanding contributors from different > organizations and companies. > Glad to see it joins the ASF family and grows the community by following > the Apache way. :) > > Thanks, > > JP > > Jean-Baptiste Onofré 于2024年5月23日周四 13:08写道： > > > Hi folks, > > > > We would like to propose a new project to the ASF incubator: Gravitino. > > > > Gravitino is a high-performance, geo-distributed, and federated > > metadata lake designed to manage metadata seamlessly across diverse > > data sources, vendors, and regions. Its primary goal is to provide > > users with unified metadata access for both data and AI assets. > > > > Here is the proposal: > > https://cwiki.apache.org/confluence/display/INCUBATOR/GravitinoProposal > > > > Comments and feedback are welcome. > > > > Thanks ! > > Regards > > JB > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > >
Re: [RESULT][VOTE] Drop the incubator- prefix for podling's GitHub repo name
You can review the implementation PRs at: * https://github.com/apache/incubator/pull/127 * https://github.com/apache/incubator/pull/128 Hopefully it's clear and we can use the description to guide podlings to make progress. Best, tison. tison 于2024年5月14日周二 00:08写道： > Thanks for your participation! > > This vote has passed with 12 +1 bindings, 2 -1 bindings, 13 +1 > non-bindings, 2 +0 bindings, 3 -0 bindings, and 2 -0 non-bindings. > > I'll follow the update tasks on the incubator site this week and help > podlings make the upgrade with help from INFRA if the podlings would like > to do so. According to the vote above, we'd "finally converge podling's > GitHub repo to have a name without the incubator- prefix". > > Details of the vote are as below: > > +1 bindings (12): > * Francis Chuang > * Craig Russell > * Xuanwo > * Xinyu Zhou > * Daniel Gruno > * Ayush Saxena > * larry mccay > * Christofer Dutz > * Justin Mclean > * Yu Xiao > * Vinayakumar B > * tison > > +0 bindings (2): > * Dave Fisher > * PJ Fanning > > -0 bindings (3): > * Richard Zowalla > * hulk > * suyanhanx > > -1 bindings (2): > * Sheng Wu (reason [1]) > * Alexander Alten (reason [2]) > > [1] https://lists.apache.org/thread/yt80przs9mvd2752gcqqqs4ky1q29ymm > [2] https://lists.apache.org/thread/g9hkvj7y2t0jmz87p9658rs37ztlnptp > > +1 non-bindings (13): > * Alex Porcelli > * ZhangJian He > * Wilfred Spiegelenburg > * Alin.Jerpelea > * Imba Jin > * Cédric Champeau > * Rui Fan > * Chunshao Ren > * Hongyu Guo > * Jermaine Hua > * Weibin Zeng > * ConradJam > * Cheng Pan > > -0 non-binding (2): > * vin jake > * Huajie Wang > > Best, > tison. >
Re: [QUESTION] KIE - NPM package names
Hi Tiago, > How? Every package we ever published to NPM under KIE is owned by > https://www.npmjs.com/~kie-tools-bot now (some of them were > removed/renamed). We can give control to the ~theasf user, no problem. You can open an INFRA JIRA ticket like [1]. [1] https://issues.apache.org/jira/browse/INFRA-25325 > if this could be postponed to the next release, it would be great. I listed the suggestion in priority (desc order), so it's OK that your first release keeps this @kie namespace, especially since Kie's trademark is (to be) transferred to the ASF. However, @apache/kie-xxx is more appropriate and I'll appreciate it if you can arrive there in the following releases. You may think of ASF Java packages that are released with org.apache. group id. I hope the NPM scope is the idiom that accomplishes the same thing on that platform. > Renaming it would mean essentially creating new extensions, without any relationship to the old ones whatsoever. >From my experience using VS Code extensions, it should be possible to deprecate the old extension and suggest a successor extension in the README. If you'd release those VS Code extensions under the existing name for now, I'd suggest the following things to improve: 1. State the relationship between the extension and Apache KIE™ (Incubating) in the README. 2. Update the description and the display name of the owner account "KIE" [2]. I may prefer to work with ASF INFRA to register an official ASF account to own these extensions, but the INFRA team may have a different opinion since they may not manage all the accounts among all release channels. You should try to reach out to them. [2] https://marketplace.visualstudio.com/publishers/kie-group To be clear, these are the first few improvement items that came to mind. But they may not be all you can or should do. > If you type "sonataflow" in the search input at the right-hand-side > you'll see that a JAR was published based on the NPM package. See I think it's generally possible to move the group ID to org.apache.kie. Best, tison. Tiago Bento 于2024年5月17日周五 03:55写道： > Thanks all for the replies. > > I'll try to postpone renaming the packages we have today, so we'll > start the release vote without this renaming. All packages will > include the DISCLAIMER in their README files. E.g., > > https://github.com/apache/incubator-kie-tools/blob/main/packages/dmn-editor/README.md > > I hope that's ok for a first incubator release. We'll address any > feedback we receive on the voting thread. > > Of course, for the next release I'll have a plan for renaming all > Apache KIE (incubating) NPM packages and for publishing them under > ~theasf, and @apache or @apache-kie scopes. > > Thanks again for your input. > > Regards, > > Tiago Bento > > On Wed, May 15, 2024 at 4:36 PM Dave Fisher wrote: > > > > Here’s my 2 cents. > > > > Incubation is a journey, and if there are parts that are yet to be > compliant that should be fine. In the end all will be squared away. > > > > For the IPMC - should we have something like DISCLAIMER-WIP for binary > convenience packaging? > > > > Best, > > Dave > > > > > On May 15, 2024, at 1:13 PM, Tiago Bento > wrote: > > > > > > Tison, > > > > > > Thanks for the reply! > > > > > > On Wed, May 15, 2024 at 1:43 PM tison wander4...@gmail.com>> wrote: > > >> > > >> We have an official account on NPM [1] and the associated org [2] (cc > @Mark > > >> Thomas IIRC who manages this account). > > >> > > >> [1] https://www.npmjs.com/~theasf > > >> [2] https://www.npmjs.com/org/apache > > >> > > >> Both of these associations can improve the verification and brand for > your > > >> release, while you may use the @apache scope in your package's name to > > >> replace the handy apache- prefix that isn't endorsed by NPM's > mechanism. > > >> > > >> For the name and branding topic, I would suggest (in priority): > > >> > > >> 1. State your display name as Apache KIE™ (incubating) on the release > page > > >> (README). > > > Ok. > > > > > >> 2. Build an association with our official NPM organization, following > NPM's > > >> mechanism. > > > How? Every package we ever published to NPM under KIE is owned by > > > https://www.npmjs.com/~kie-tools-bot < > https://www.npmjs.com/~kie-tools-bot> now (some of them were > > > removed/renamed). We can give control to the ~theasf user, no problem. > > > > > >> 3. Change your package name (handle) to @apache/kie-xxx. > >
Re: [QUESTION] KIE - NPM package names
We have an official account on NPM [1] and the associated org [2] (cc @Mark Thomas IIRC who manages this account). [1] https://www.npmjs.com/~theasf [2] https://www.npmjs.com/org/apache Both of these associations can improve the verification and brand for your release, while you may use the @apache scope in your package's name to replace the handy apache- prefix that isn't endorsed by NPM's mechanism. For the name and branding topic, I would suggest (in priority): 1. State your display name as Apache KIE™ (incubating) on the release page (README). 2. Build an association with our official NPM organization, following NPM's mechanism. 3. Change your package name (handle) to @apache/kie-xxx. As for the VS Code Extensions, I'm unfamiliar with this scope, but it seems there are other names like "kogito". What are the relations between them and KIE? As for the WebJar, I'm unfamiliar with this scope also. And I don't find an entry called sonataflow-deployment-webapp on the page you linked. The official name of an ASF project is always Apache Foo [3], and we should use this name when possible. [3] https://www.apache.org/foundation/marks/guide Best, tison. Tiago Bento 于2024年5月16日周四 00:43写道： > Shawn, > > Does that mean you didn't publish anything to NPM as part of your > releases while in the incubator? > > On Wed, May 15, 2024 at 12:31 PM Shawn Yang > wrote: > > > > Hi Tiago, > > > > From the current incubator release policy, you need to rename all npm > > packages to apache-xxx before releasing. The packages released before > > should be on to left intact. > > > > I came across same issue when we release apache fury. In your case, most > > packages starts with kie. Fury has similar rules which starts with > furyjs. > > Rename to apache-xxx has many works to do and breaks the compatibility > with > > downstreams. So fury just skipped release binary packages for fury > > JavaScript. > > > > I was wondering whether the incubator release policy remove such name > > rules. It does introduce extra work and confusion to podlings. And It's > not > > idiomatic in npm. Similar confusion exists for Python wheels. In Python, > > the naming needs to be consise and be as short as possible. We barely > see a > > wheel in a organization name wheel as $orgname-xxx. > > > > > > > > On Wednesday, May 15, 2024, Tiago Bento wrote: > > > > > Hi general@incubator, > > > > > > The distribution guidelines [1] say packages published to NPM should > > > be named `apache-`, however, at KIE, we have a somewhat big > > > set of packages that are published under these scopes: > > > - @kie-tools/* > > > - @kie-tools-core/* > > > - @kie-tools-scripts/* > > > > > > There are also some VS Code Extensions (which can't have a scope): > > > - yard-vscode-extension > > > - swf-vscode-extension > > > - pmml-vscode-extension > > > - dmn-vscode-extension > > > - bpmn-vscode-extension > > > - vscode-extension-kogito-bundle > > > - vscode-extension-kie-ba-bundle > > > - vscode-extension-dashbuilder-editor > > > > > > And a one-off package that is later then transformed into a Maven > > > WebJar [2] (which can't have a scope either) > > > - sonataflow-deployment-webapp > > > > > > Those do not conform with the guidelines, but have been published > > > under these scopes/names for quite some time now, before KIE became a > > > podling. > > > > > > My question is: Are we required to rename everything prior to > > > releasing? Or are we able to pass a vote with the current package > > > names? Asking because that's a substantial amount of work prior to > > > releasing, and also because renaming everything would mean consumers > > > would have to manually "migrate" to the new package names. > > > > > > Thanks a lot in advance! > > > > > > Regards, > > > > > > Tiago Bento > > > > > > > > > [1] https://incubator.apache.org/guides/distribution.html#npm > > > [2] https://www.webjars.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 > >
[RESULT][VOTE] Drop the incubator- prefix for podling's GitHub repo name
Thanks for your participation! This vote has passed with 12 +1 bindings, 2 -1 bindings, 13 +1 non-bindings, 2 +0 bindings, 3 -0 bindings, and 2 -0 non-bindings. I'll follow the update tasks on the incubator site this week and help podlings make the upgrade with help from INFRA if the podlings would like to do so. According to the vote above, we'd "finally converge podling's GitHub repo to have a name without the incubator- prefix". Details of the vote are as below: +1 bindings (12): * Francis Chuang * Craig Russell * Xuanwo * Xinyu Zhou * Daniel Gruno * Ayush Saxena * larry mccay * Christofer Dutz * Justin Mclean * Yu Xiao * Vinayakumar B * tison +0 bindings (2): * Dave Fisher * PJ Fanning -0 bindings (3): * Richard Zowalla * hulk * suyanhanx -1 bindings (2): * Sheng Wu (reason [1]) * Alexander Alten (reason [2]) [1] https://lists.apache.org/thread/yt80przs9mvd2752gcqqqs4ky1q29ymm [2] https://lists.apache.org/thread/g9hkvj7y2t0jmz87p9658rs37ztlnptp +1 non-bindings (13): * Alex Porcelli * ZhangJian He * Wilfred Spiegelenburg * Alin.Jerpelea * Imba Jin * Cédric Champeau * Rui Fan * Chunshao Ren * Hongyu Guo * Jermaine Hua * Weibin Zeng * ConradJam * Cheng Pan -0 non-binding (2): * vin jake * Huajie Wang Best, tison.
Re: [VOTE] Release Apache StreamPark(Incubating) 2.1.4-rc2
+1 binding 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 * Compile from sources. Best, tison. li gang 于2024年5月13日周一 20:57写道： > +1 (binding) > I checked > - Download links are valid. > - Files have the word incubating in their name. > - Checksums and signatures are valid. > - DISCLAIMER,LICENSE and NOTICE files exist. > - No unexpected Binary Files in the source release. > > Shaokang Lv 于2024年5月9日周四 13:50写道： > > > Hello Incubator Community: > > > > This is a call for a vote to release Apache StreamPark(Incubating) > version > > 2.1.4-RC2. > > The Apache StreamPark community has voted on and approved a proposal to > > release Apache StreamPark(Incubating) version 2.1.4-RC2. > > 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/fb3qomvr9ty54s46ltrz37rqwvx7lwvz > > > > Vote result thread: > > https://lists.apache.org/thread/v5l70gdfczc54g2knn06p7rh69d5pq2n > > > > The release candidate: > > https://dist.apache.org/repos/dist/dev/incubator/streampark/2.1.4-RC2/ > > > > Git tag for the release: > > https://github.com/apache/incubator-streampark/releases/tag/v2.1.4-rc2 > > > > 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-rc2 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 > > > > > -- > > > -- > Best Regards > Gang Li 李岗 > > lgcar...@apache.org >
Re: [VOTE] Drop the incubator- prefix for podling's GitHub repo name
Here is my +1 binding. Reading from the feedback above, I suggest that the INFRA team would prefer that podlings handle branding by themselves, and it's good for podlings to understand what we should add the DISCLAIMER and how to identify the incubating status. Besides, we can avoid the large renaming repo issues, especially for Go projects, and the confusing redirection assumptions. I'll count the votes and conclude the result today. Best, tison. Vinayakumar B 于2024年5月12日周日 22:53写道： > +1 (binding) > > -Vinay > > > On Sat, 11 May 2024 at 5:48 PM, Suyan wrote: > > > -0 binding from suyanhanx > > > > Sincerely, > > Suyan > > > > tison 于2024年5月8日周三 08:32写道： > > > > > > Hi, > > > > > > Following the discussion thread [1], I'd start a vote on the following > > > proposals: > > > > > > 1. Establish a consensus to allow and finally converge podling's GitHub > > repo to > > > have a name without the incubator- prefix. > > > 2. Allow existing ongoing 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. Update the docs on incubator.apache.org to guide how to describe > > > podling's incubating status on the GitHub repo (namely, including > > > "incubating" in the repo description and README, point to the > DISCLAIMER > > > content). > > > > > > [1] https://lists.apache.org/thread/kxvdkrf8g8yr6hww1n08r21xdy67y4ok > > > > > > +1 allow podling's GitHub repo to have a name without the incubator- > > > prefix, and other items above > > > +0 do not care strongly > > > -1 disagree the proposals above, because ... > > > > > > Please vote with your ASF ID followed by (binding) if you are a member > of > > > the Incubator PMC or (not binding) if not. > > > > > > Vote will be open for at least 72 hours. > > > > > > Best, > > > tison. > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > >
[VOTE] Drop the incubator- prefix for podling's GitHub repo name
Hi, Following the discussion thread [1], I'd start a vote on the following proposals: 1. Establish a consensus to allow and finally converge podling's GitHub repo to have a name without the incubator- prefix. 2. Allow existing ongoing 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. Update the docs on incubator.apache.org to guide how to describe podling's incubating status on the GitHub repo (namely, including "incubating" in the repo description and README, point to the DISCLAIMER content). [1] https://lists.apache.org/thread/kxvdkrf8g8yr6hww1n08r21xdy67y4ok +1 allow podling's GitHub repo to have a name without the incubator- prefix, and other items above +0 do not care strongly -1 disagree the proposals above, because ... Please vote with your ASF ID followed by (binding) if you are a member of the Incubator PMC or (not binding) if not. Vote will be open for at least 72 hours. Best, tison.
Re: License for text content
Thank you! Using Apache License 2.0 as the single license makes sense to me. Best, tison. Shane Curcuru 于2024年5月2日周四 19:55写道： > (Moving general@incubator and dev@community to BCC since this is really > a legal question about ASF licensing) > > tison wrote on 5/1/24 11:25 PM: > > Hi, > > > > IIUC, the Apache License 2.0 is mainly to license code and related stuff > > that constructs the final software. > > > > However, projects may also create text content like documents. Is it > > appropriate to use Apache License 2.0 for them (since quite a few terms > > may not be applicable)? Or what licenses shall we use? > > The ASF uses the Apache-2.0 license for our projects' own content that > is put into any releases, immaterial of type of content: > > https://apache.org/legal/src-headers.html#faq-docs > > Using a single license reduces complexity, and makes it simpler for > users to understand the issues around re-using ASF products. > > -- > - Shane >Member >The Apache Software Foundation > >
License for text content
Hi, IIUC, the Apache License 2.0 is mainly to license code and related stuff that constructs the final software. However, projects may also create text content like documents. Is it appropriate to use Apache License 2.0 for them (since quite a few terms may not be applicable)? Or what licenses shall we use? For example, a website repo can contain both code and docs. In my personal site, I wrote: > Code is licensed under Apache-2.0, words and images are licensed under CC BY 4.0. But I don't know if we can write the same to a site repo of an ASF project. Best, tison.
Re: Verification of download pages and links
Hi Sebb, I'm trying to make a reference in the next OpenDAL release, that staging the download pages and links. Here is a technical issue. Before the release is out, which link should be used? IIUC we can use the link at [1]. But it doesn't follow the INFRA policy for formal releases. However, before the release it out, no artifact of the specific version is available at [2] or [3]. [1] https://dist.apache.org/repos/dist/dev/opendal/ [2] https://www.apache.org/dyn/closer.lua/opendal/ [3] https://downloads.apache.org/opendal/ This is the ongoing patch [4] where I left a TODO inline. [4] https://github.com/apache/opendal/pull/4565 Best, tison. tison 于2024年4月29日周一 08:43写道： > > The link to the source download and keys and hashes is broken. > > Thank you! File [1] to fix it. > > [1] https://github.com/apache/opendal/pull/4547 > > This shows the necessity of previewing the download page. At least since > we provide it, we should ensure its correctness. > > Best, > tison. > > > Justin Mclean 于2024年4月29日周一 08:15写道： > >> Hi, >> >> > Here is a patch to cover a minimal download page [1], which is derived >> from >> > OpenDAL's download page [2]. Welcome to leave comments if you find any >> > issues or things we can improve on. >> > >> > [1] https://github.com/apache/datafusion/pull/10271 >> > [2] https://opendal.apache.org/download >> >> The link to the source download and keys and hashes is broken. >> >> 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-rc4
Carry my +1 binding vote. Best, tison. Shawn Yang 于2024年4月30日周二 22:17写道： > Hello everyone, > > This is a call for the vote to release Apache Fury(Incubating) v0.5.0-rc4. > > The Apache Fury community has voted and approved the release of Apache > Fury(incubating) v0.5.0-rc4. We now kindly request the IPMC members > review and vote for this release. > > Apache Fury(incubating) - A blazingly fast multi-language serialization > framework powered by JIT and zero-copy. > > Fury community vote thread: > https://lists.apache.org/thread/35slclopfngmz5ff47tt32m1fwjz1316 > > Vote result thread: > https://lists.apache.org/thread/lnogbwfxw4hlkckl7nxpwwpy94zz6kv8 > > The release candidate: > https://dist.apache.org/repos/dist/dev/incubator/fury/0.5.0-rc4/ > > This release has been signed with a PGP available here: > https://downloads.apache.org/incubator/fury/KEYS > > Git tag for the release: > https://github.com/apache/incubator-fury/releases/tag/v0.5.0-rc4 > > Git commit for the release: > > https://github.com/apache/incubator-fury/commit/51beb134f517917d572dd0cf2b21534d74ecc726 > > Maven staging repo: > https://repository.apache.org/content/repositories/orgapachefury-1006 > > How to Build and Test, please refer to: > > https://github.com/apache/incubator-fury/blob/main/docs/guide/DEVELOPMENT.md > > The vote will be open for at least 72 hours or until the necessary number > of votes is reached. > > Please vote accordingly: > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove with the reason > > To learn more about apache fury, please see https://fury.apache.org/ > > Checklist for reference: > > [ ] Download links are valid. > [ ] Checksums and signatures. > [ ] LICENSE/NOTICE files exist > [ ] No unexpected binary files > [ ] All source files have ASF headers > [ ] Can compile from source > > > Thanks, > > Chaokun Yang >
Re: [DISCUSS] Drop the incubator- prefix for podling's GitHub repo
Before starting the vote, I found (perhaps) a final question: Shall we thus guide all the new podlings to enter the incubator without incubator- prefix and thus converge all the current podlings are in form apache/foo? I'm afraid that if new podling can still have the incubator- prefix, it can give a confusing impression to end-users. I can't find a good place to document this point but perhaps we spread the consensus when reviewing new podling proposal's "Git Repositories" section. Best, tison. ConradJam 于2024年4月29日周一 14:17写道： > As a developer on the Apache Amoro project, I believe it's crucial to > prominently display the project's status as an incubator, whether by > attaching it to the project prefix or featuring it on the website. Most > individuals typically recognize that a project is in incubation through the > project's website or GitHub description (including myself when initially > encountering or learning about a project). Every project developer has an > obligation to indicate the project's incubation status when promoting or > publicizing it. Additionally, displaying a clear logo on the website > indicating its incubation status is essential. As a user, simply having > that incubator logo or description suffices for me. Therefore, I’m +0 for > incubator- prefix . > > tison 于2024年4月24日周三 19:49写道： > > > 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
Re: [VOTE] Release Apache StreamPark(Incubating) 2.1.4-rc1
> Even if they have changed a lot, that could still be an issue. Copying an earlier version of a file is still an issue that needs to be dealt with. Even copying 5% of something needs to be treated correctly. The files seem to have permissive licenses, so there is no category X licensing issue, at least. Agree. My expression bad. I originally wanted to say, that the reported similar file's content is different, and there is no history to show they're ever the same. Best, tison. Justin Mclean 于2024年4月29日周一 17:19写道： > Hi, > > > * Some false positive on testing assertions utils. Match rate < 50%, file > > is small, and those utilities are trivial. Even when I go to the > "origins", > > they are lost or changed a lot. Clearly not the same origin. > > Even if they have changed a lot, that could still be an issue. Copying an > earlier version of a file is still an issue that needs to be dealt with. > Even copying 5% of something needs to be treated correctly. The files seem > to have permissive licenses, so there is no category X licensing issue, at > least. > > 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 StreamPark(Incubating) 2.1.4-rc1
But I found a potential issue that it's possible StreamPark copied some code from flink-sql-gateway to streampark-flink-sql-gateway. If that's the case, we should convey this info in the LICENSE file. But since Flink is also an ASF project, we don't need to convey another copy of ALv2 and no need to remove the license header, while add a comment to the origin file can be helpful. Best, tison. tison 于2024年4月29日周一 16:59写道： > > It looks like additional third-party code might also be in the release, > but it is difficult to tell. > > Yeah. The result gives a lot of noise. I run SCANOSS locally, and don't > find any other third-party code included: > > * Many of the reference to streamx is the original project before > StreamPark donated to the ASF. > * Some false positive on testing assertions utils. Match rate < 50%, file > is small, and those utilities are trivial. Even when I go to the "origins", > they are lost or changed a lot. Clearly not the same origin. > * streampark-console is reported to be the same as a few frontend > projects, where we know that it's because we copy the sources > from vue-vben-admin and we convey the license info now. > > To sum up, AFAICS there is no more potential violation. > > Best, > tison. > > > tison 于2024年4月29日周一 16:26写道： > >> > vue-vben-admin is under MIT[1] license, In the LICENST[2] file of >> > StreamPark, we listed which files are copied from vue-vben-admin >> >> The issue here is that, as MIT license writes: >> >> > The above copyright notice and this permission notice shall be included >> in all copies or substantial portions of the Software. >> >> But the "copyright notice and this permission notice" of vue-vben-admin, >> i.e., LICENSE-vue-vben-admin.txt added at [10] doesn't included in the >> source releases of streampark and that is the issue. I suppose you also >> check if you distribute streampark-console at your binary release, and if >> so, ensure that the binary release contains a copy of this license file >> also. >> >> [10] https://github.com/apache/incubator-streampark/pull/3689 >> >> Best, >> tison. >> >> >> Huajie Wang 于2024年4月29日周一 16:16写道： >> >>> > So a condition of including MIT licensed code is to include the >>> relevant >>> MIT license text. That seems to be missing for for vue-vben-admin , as I >>> can’t find it anywhere in the release >>> >>> vue-vben-admin is under MIT[1] license, In the LICENST[2] file of >>> StreamPark, we listed which files are copied from vue-vben-admin >>> >>> [1] https://github.com/vbenjs/vue-vben-admin/blob/main/LICENSE [2] >>> >>> https://github.com/apache/incubator-streampark/blob/release-2.1.4-rc1/LICENSE#L228 >>> >>> Best, >>> Huajie Wang >>> >>> >>> >>> Best, >>> Huajie Wang >>> >>> >>> >>> Justin Mclean 于2024年4月29日周一 15:32写道： >>> >>> > Hi, >>> > >>> > -1 (binding) from me >>> > >>> > I checked: >>> > - incubating in name >>> > - signatures and hashes correct >>> > - disclaimer exists >>> > - LICENSE is missing some info on the MIT license >>> > - NOTICE looks fine >>> > - I didn't compile from source >>> > >>> > So a condition of including MIT licensed code is to include the >>> relevant >>> > MIT license text. That seems to be missing for for vue-vben-admin , as >>> I >>> > can’t find it anywhere in the release. Oddly, the license file here >>> [1] is >>> > an Apache one, not an MIT one, and it also fails to mention the MIT >>> code >>> > under it. >>> > >>> > It looks like additional third-party code might also be in the release, >>> > but it is difficult to tell. I think you should run SCANOSS ( >>> > https://www.softwaretransparency.org/download) on your release and >>> look >>> > into its results. >>> > >>> > Kind Regards, >>> > Justin >>> > >>> > >>> > 1. streampark-console/streampark-console-webapp/LICENSE >>> > - >>> > 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
> It looks like additional third-party code might also be in the release, but it is difficult to tell. Yeah. The result gives a lot of noise. I run SCANOSS locally, and don't find any other third-party code included: * Many of the reference to streamx is the original project before StreamPark donated to the ASF. * Some false positive on testing assertions utils. Match rate < 50%, file is small, and those utilities are trivial. Even when I go to the "origins", they are lost or changed a lot. Clearly not the same origin. * streampark-console is reported to be the same as a few frontend projects, where we know that it's because we copy the sources from vue-vben-admin and we convey the license info now. To sum up, AFAICS there is no more potential violation. Best, tison. tison 于2024年4月29日周一 16:26写道： > > vue-vben-admin is under MIT[1] license, In the LICENST[2] file of > > StreamPark, we listed which files are copied from vue-vben-admin > > The issue here is that, as MIT license writes: > > > The above copyright notice and this permission notice shall be included > in all copies or substantial portions of the Software. > > But the "copyright notice and this permission notice" of vue-vben-admin, > i.e., LICENSE-vue-vben-admin.txt added at [10] doesn't included in the > source releases of streampark and that is the issue. I suppose you also > check if you distribute streampark-console at your binary release, and if > so, ensure that the binary release contains a copy of this license file > also. > > [10] https://github.com/apache/incubator-streampark/pull/3689 > > Best, > tison. > > > Huajie Wang 于2024年4月29日周一 16:16写道： > >> > So a condition of including MIT licensed code is to include the relevant >> MIT license text. That seems to be missing for for vue-vben-admin , as I >> can’t find it anywhere in the release >> >> vue-vben-admin is under MIT[1] license, In the LICENST[2] file of >> StreamPark, we listed which files are copied from vue-vben-admin >> >> [1] https://github.com/vbenjs/vue-vben-admin/blob/main/LICENSE [2] >> >> https://github.com/apache/incubator-streampark/blob/release-2.1.4-rc1/LICENSE#L228 >> >> Best, >> Huajie Wang >> >> >> >> Best, >> Huajie Wang >> >> >> >> Justin Mclean 于2024年4月29日周一 15:32写道： >> >> > Hi, >> > >> > -1 (binding) from me >> > >> > I checked: >> > - incubating in name >> > - signatures and hashes correct >> > - disclaimer exists >> > - LICENSE is missing some info on the MIT license >> > - NOTICE looks fine >> > - I didn't compile from source >> > >> > So a condition of including MIT licensed code is to include the relevant >> > MIT license text. That seems to be missing for for vue-vben-admin , as I >> > can’t find it anywhere in the release. Oddly, the license file here [1] >> is >> > an Apache one, not an MIT one, and it also fails to mention the MIT code >> > under it. >> > >> > It looks like additional third-party code might also be in the release, >> > but it is difficult to tell. I think you should run SCANOSS ( >> > https://www.softwaretransparency.org/download) on your release and look >> > into its results. >> > >> > Kind Regards, >> > Justin >> > >> > >> > 1. streampark-console/streampark-console-webapp/LICENSE >> > - >> > 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
> vue-vben-admin is under MIT[1] license, In the LICENST[2] file of > StreamPark, we listed which files are copied from vue-vben-admin The issue here is that, as MIT license writes: > The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. But the "copyright notice and this permission notice" of vue-vben-admin, i.e., LICENSE-vue-vben-admin.txt added at [10] doesn't included in the source releases of streampark and that is the issue. I suppose you also check if you distribute streampark-console at your binary release, and if so, ensure that the binary release contains a copy of this license file also. [10] https://github.com/apache/incubator-streampark/pull/3689 Best, tison. Huajie Wang 于2024年4月29日周一 16:16写道： > > So a condition of including MIT licensed code is to include the relevant > MIT license text. That seems to be missing for for vue-vben-admin , as I > can’t find it anywhere in the release > > vue-vben-admin is under MIT[1] license, In the LICENST[2] file of > StreamPark, we listed which files are copied from vue-vben-admin > > [1] https://github.com/vbenjs/vue-vben-admin/blob/main/LICENSE [2] > > https://github.com/apache/incubator-streampark/blob/release-2.1.4-rc1/LICENSE#L228 > > Best, > Huajie Wang > > > > Best, > Huajie Wang > > > > Justin Mclean 于2024年4月29日周一 15:32写道： > > > Hi, > > > > -1 (binding) from me > > > > I checked: > > - incubating in name > > - signatures and hashes correct > > - disclaimer exists > > - LICENSE is missing some info on the MIT license > > - NOTICE looks fine > > - I didn't compile from source > > > > So a condition of including MIT licensed code is to include the relevant > > MIT license text. That seems to be missing for for vue-vben-admin , as I > > can’t find it anywhere in the release. Oddly, the license file here [1] > is > > an Apache one, not an MIT one, and it also fails to mention the MIT code > > under it. > > > > It looks like additional third-party code might also be in the release, > > but it is difficult to tell. I think you should run SCANOSS ( > > https://www.softwaretransparency.org/download) on your release and look > > into its results. > > > > Kind Regards, > > Justin > > > > > > 1. streampark-console/streampark-console-webapp/LICENSE > > - > > 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
Here is a draft that participants in this thread can review: [1] [1] https://github.com/apache/incubator-streampark/pull/3689 Best, tison. tison 于2024年4月29日周一 16:01写道： > > So a condition of including MIT licensed code is to include the > relevant MIT license text. > > Confirmed this is the case. > > I found the mention to vue-vben-admin is licensed under MIT at [1] but I > don't find the LICENSE of vue-vben-admin bundled also. > > I agree that the LICENSE file at [2] seems to be misleading and since > those MIT licensed files doesn't have a license header, it would be better > to update the LICENSE content at the root path of streampark-console-webapp. > > [1] > https://github.com/apache/incubator-streampark/blob/fe536ef7e24db2adeaaa298e1e8933899b61f834/LICENSE#L223-L251 > [2] streampark-console/streampark-console-webapp/LICENSE > > The license issue of vue-vben-admin was pointed out at previous releases > [3]. It seems StreamPark still has some issues to resolve. > > [3] https://lists.apache.org/thread/p1f9k83q3tvz2pykfmjvpcsnxl8x4wl3 > > For using SCANOSS, Shawn Yang shares a video that you may leverage from > [4]. > > [4] https://lists.apache.org/thread/13s0cgfd6b5m7qtkcffz1rk1jbywy3wv > > Best, > tison. > > > Justin Mclean 于2024年4月29日周一 15:32写道： > >> Hi, >> >> -1 (binding) from me >> >> I checked: >> - incubating in name >> - signatures and hashes correct >> - disclaimer exists >> - LICENSE is missing some info on the MIT license >> - NOTICE looks fine >> - I didn't compile from source >> >> So a condition of including MIT licensed code is to include the relevant >> MIT license text. That seems to be missing for for vue-vben-admin , as I >> can’t find it anywhere in the release. Oddly, the license file here [1] is >> an Apache one, not an MIT one, and it also fails to mention the MIT code >> under it. >> >> It looks like additional third-party code might also be in the release, >> but it is difficult to tell. I think you should run SCANOSS ( >> https://www.softwaretransparency.org/download) on your release and look >> into its results. >> >> Kind Regards, >> Justin >> >> >> 1. streampark-console/streampark-console-webapp/LICENSE >> - >> 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
> So a condition of including MIT licensed code is to include the relevant MIT license text. Confirmed this is the case. I found the mention to vue-vben-admin is licensed under MIT at [1] but I don't find the LICENSE of vue-vben-admin bundled also. I agree that the LICENSE file at [2] seems to be misleading and since those MIT licensed files doesn't have a license header, it would be better to update the LICENSE content at the root path of streampark-console-webapp. [1] https://github.com/apache/incubator-streampark/blob/fe536ef7e24db2adeaaa298e1e8933899b61f834/LICENSE#L223-L251 [2] streampark-console/streampark-console-webapp/LICENSE The license issue of vue-vben-admin was pointed out at previous releases [3]. It seems StreamPark still has some issues to resolve. [3] https://lists.apache.org/thread/p1f9k83q3tvz2pykfmjvpcsnxl8x4wl3 For using SCANOSS, Shawn Yang shares a video that you may leverage from [4]. [4] https://lists.apache.org/thread/13s0cgfd6b5m7qtkcffz1rk1jbywy3wv Best, tison. Justin Mclean 于2024年4月29日周一 15:32写道： > Hi, > > -1 (binding) from me > > I checked: > - incubating in name > - signatures and hashes correct > - disclaimer exists > - LICENSE is missing some info on the MIT license > - NOTICE looks fine > - I didn't compile from source > > So a condition of including MIT licensed code is to include the relevant > MIT license text. That seems to be missing for for vue-vben-admin , as I > can’t find it anywhere in the release. Oddly, the license file here [1] is > an Apache one, not an MIT one, and it also fails to mention the MIT code > under it. > > It looks like additional third-party code might also be in the release, > but it is difficult to tell. I think you should run SCANOSS ( > https://www.softwaretransparency.org/download) on your release and look > into its results. > > Kind Regards, > Justin > > > 1. streampark-console/streampark-console-webapp/LICENSE > - > 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
> The link to the source download and keys and hashes is broken. Thank you! File [1] to fix it. [1] https://github.com/apache/opendal/pull/4547 This shows the necessity of previewing the download page. At least since we provide it, we should ensure its correctness. Best, tison. Justin Mclean 于2024年4月29日周一 08:15写道： > Hi, > > > Here is a patch to cover a minimal download page [1], which is derived > from > > OpenDAL's download page [2]. Welcome to leave comments if you find any > > issues or things we can improve on. > > > > [1] https://github.com/apache/datafusion/pull/10271 > > [2] https://opendal.apache.org/download > > The link to the source download and keys and hashes is broken. > > Kind Regards, > Justin > > - > 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
Thank you, Dave :D It gives a reason. I'm OK with this explanation now so that I won't bring it to the INFRA. Back to the original purpose of this thread, I suggest: 1. Go through our Incubator Guide and find if we have some references to this release distribution policy (maybe in [1][2]). Then, make this requirement clear and discoverable. 2. Try to implement the preview feature and add the verify items in one project so later we use it as a reference. [1] https://incubator.apache.org/guides/distribution.html [2] https://incubator.apache.org/guides/releasemanagement.html I'll try my best to find time to work on it, but I don't declare it an assignment. Best, tison. Dave Fisher 于2024年4月29日周一 02:46写道： > > > > On Apr 28, 2024, at 9:58 AM, tison wrote: > > > > Thank you! > > > > I found there is no rationale for these links, and thus, it's quite a bit > > challenging in memory. > > > > IIRC the closer.lua script is for selecting the most proper CDN for > > source/binary bundles in use. They can, technically, work for SHASUM and > > signatures also. Why do we use https://downloads.apache.org for the > latter > > two? > > Historically we had a mirror network and closer.lua picked out a mirror > near you. In order to be sure that the download source or binary on the > mirror was not altered on (or on its way to or from) the mirror, the > detached signature and checksums must be served from ASF controlled > resources. > > Whether or not this still makes sense is a discussion for Infra since they > are charged with enforcing and supporting the release distribution policy. > > Best, > Dave > > > > > Best, > > tison. > > > > > > sebb 于2024年4月29日周一 00:34写道： > > > >> On Sun, 28 Apr 2024 at 15:38, tison wrote: > >>> > >>> Yeah. I support that we always need to release sources on our platform. > >>> > >>> Given the links to downloads.apache.org, archive.apache.org, > >>> https://www.apache.org/dyn/closer.lua, can be unintuitive for users, I > >>> agree that we can have a simple Download page for such library-only > >>> projects. > >> > >> The download page can also be used for links to release notes, and to > >> provide other support information. > >> > >>> Here is a patch to cover a minimal download page [1], which is derived > >> from > >>> OpenDAL's download page [2]. Welcome to leave comments if you find any > >>> issues or things we can improve on. > >>> > >>> [1] https://github.com/apache/datafusion/pull/10271 > >> > >> The closer.lua script is only intended for the source and binary > bundles. > >> > >> The sigs and hashes (and KEYS) should link directly to > >> https://downloads.apache.org/datafusion/... > >> > >>> [2] https://opendal.apache.org/download > >>> > >>> Best, > >>> tison. > >>> > >>> > >>> Justin Mclean 于2024年4月28日周日 10:02写道： > >>> > >>>> Hi, > >>>> > >>>> Projects need to make source releases on ASF infrastructure and have a > >>>> download page for good reasons. Some users need a place to verify and > >>>> download a trusted release. Having it hosted on ASF infrastructure > >> means > >>>> people can 100% trust it, unlike 3rd party providers. 3rd party > >> providers > >>>> have gone rogue in the past (e.g . Source Forge), disappeared (e.g. > >> Google > >>>> Code), or had multiple serious issues (e.g. NPM). Also by placing a > >> release > >>>> in the ASF distribution area / a project download page gives > confidence > >>>> that the ASF release process has been followed and that it is not a > >> release > >>>> by a 3rd party or an unofficial release of some sort. IMO, all > >> projects > >>>> need to have a download page, even if it may not be used by the > >> majority of > >>>> users. > >>>> > >>>> Kind Regards, > >>>> Justin > >>>> - > >>>> 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: Verification of download pages and links
Thank you! I found there is no rationale for these links, and thus, it's quite a bit challenging in memory. IIRC the closer.lua script is for selecting the most proper CDN for source/binary bundles in use. They can, technically, work for SHASUM and signatures also. Why do we use https://downloads.apache.org for the latter two? Best, tison. sebb 于2024年4月29日周一 00:34写道： > On Sun, 28 Apr 2024 at 15:38, tison wrote: > > > > Yeah. I support that we always need to release sources on our platform. > > > > Given the links to downloads.apache.org, archive.apache.org, > > https://www.apache.org/dyn/closer.lua, can be unintuitive for users, I > > agree that we can have a simple Download page for such library-only > > projects. > > The download page can also be used for links to release notes, and to > provide other support information. > > > Here is a patch to cover a minimal download page [1], which is derived > from > > OpenDAL's download page [2]. Welcome to leave comments if you find any > > issues or things we can improve on. > > > > [1] https://github.com/apache/datafusion/pull/10271 > > The closer.lua script is only intended for the source and binary bundles. > > The sigs and hashes (and KEYS) should link directly to > https://downloads.apache.org/datafusion/... > > > [2] https://opendal.apache.org/download > > > > Best, > > tison. > > > > > > Justin Mclean 于2024年4月28日周日 10:02写道： > > > > > Hi, > > > > > > Projects need to make source releases on ASF infrastructure and have a > > > download page for good reasons. Some users need a place to verify and > > > download a trusted release. Having it hosted on ASF infrastructure > means > > > people can 100% trust it, unlike 3rd party providers. 3rd party > providers > > > have gone rogue in the past (e.g . Source Forge), disappeared (e.g. > Google > > > Code), or had multiple serious issues (e.g. NPM). Also by placing a > release > > > in the ASF distribution area / a project download page gives confidence > > > that the ASF release process has been followed and that it is not a > release > > > by a 3rd party or an unofficial release of some sort. IMO, all > projects > > > need to have a download page, even if it may not be used by the > majority of > > > users. > > > > > > Kind Regards, > > > Justin > > > - > > > 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
Yeah. I support that we always need to release sources on our platform. Given the links to downloads.apache.org, archive.apache.org, https://www.apache.org/dyn/closer.lua, can be unintuitive for users, I agree that we can have a simple Download page for such library-only projects. Here is a patch to cover a minimal download page [1], which is derived from OpenDAL's download page [2]. Welcome to leave comments if you find any issues or things we can improve on. [1] https://github.com/apache/datafusion/pull/10271 [2] https://opendal.apache.org/download Best, tison. Justin Mclean 于2024年4月28日周日 10:02写道： > Hi, > > Projects need to make source releases on ASF infrastructure and have a > download page for good reasons. Some users need a place to verify and > download a trusted release. Having it hosted on ASF infrastructure means > people can 100% trust it, unlike 3rd party providers. 3rd party providers > have gone rogue in the past (e.g . Source Forge), disappeared (e.g. Google > Code), or had multiple serious issues (e.g. NPM). Also by placing a release > in the ASF distribution area / a project download page gives confidence > that the ASF release process has been followed and that it is not a release > by a 3rd party or an unofficial release of some sort. IMO, all projects > need to have a download page, even if it may not be used by the majority of > users. > > Kind Regards, > Justin > - > 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: [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
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 > >
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 >
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 > &
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 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: [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 > >
Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3
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 > >
Improve the website of StreamPark
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
> 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] > >>> > >> >
Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3
> 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() {
>>
Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3
> 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.
>&
Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3
> 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: Missing Incubator disclaimer text
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
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
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 a
Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3
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 > >
Re: Verification of download pages and links
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 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 > >
Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3
> 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 And yes, Fury doesn't have a download page yet, and they should add one. But in my experience it's different from a quickstart install page, like [2] vs [3]. [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 > > > > fury-core > > > > 0.5.0 > > > > > > > > > > > > And then the content is correct. > > > > > > Strictly speaking the content of the Maven reference to 0.4.1 is not > > > 'incorrect'. > > > The problem is that the page does not make it clear that the release > > > is not an ASF release. > > > > > > It's OK to refer to prior releases, but the reader must be clearly > > > informed of their provenance. > > > > > > > If we make any workaround or patch to make > > > > it "look good", it would be updated as soon as 0.5.0 is released. So > I > > > > won't treat that as a release blocker. > > > > > > I would be very disappointed if the podling published the code > > > *knowing* that the download page is missing or incorrect. > > > > > > > Best, > > > > tison. > > > > > > > > > > > > sebb 于2024年4月23日周二 15:59写道： > > > > > > > > > On Mon, 22 Apr 2024 at 10:11, PJ Fanning > wrote: > > > > > > > > > > > > Hi Sebb, > > > > > > This email thread is a vote for an RC. If this vote passes, > v0.5.0 > > > > > > will be the first release of Fury since it became a podling. > > > > > > We will add a download page but at the moment, there is nothing > to > > > > > > link to there (except perhaps a KEYS file). > > > > > > > > > > > > The Install page does need to be updated to not mention > snapshots. > > > > > > > > > > If 0.5.0 is to be the first ASF release, then the Install page is > very > > > > > misleading. > > > > > > > > > > There is no indication that 0.4.1 is not an ASF release. > > > > > > > > > > > Thanks, > > > > > > PJ > > > > > > > > > > > > On Mon, 22 Apr 2024 at 10:35, sebb wrote: > > > > > > > > > > > &g
Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3
+1 binding Please remember to update the installation page, replace the current content with the first Apache release, and remove all the prior releases refs, once this release is concluded. Otherwise, if you'd like to keep the refs to prior releases, make it clear that they are not Apache releases. I checked: [x] Download Fury is valid. [x] Checksums and PGP signatures are valid. apache-fury-incubating-0.5.0-src.tar.gz gpg: Signature made 三 4/17 23:49:45 2024 CST gpg:using RSA key 1E2CDAE4C08AD7D694D1CB139D7BE8E45E580BA4 gpg: Good signature from "chaokunyang (CODE SIGNING KEY) < chaokuny...@apache.org>" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 1E2C DAE4 C08A D7D6 94D1 CB13 9D7B E8E4 5E58 0BA4 [x] Source code distributions have correct names matching the current release. [x] LICENSE, NOTICE, and DISCLAIMER files are correct. [x] All files have license headers if necessary. [x] No compiled archives bundled in source archive. [x] Build from source: # work on macOS M2 & JDK 22 cd java mvn clean install -DskipTests=true # work on macOS M2 & nightly toolchain cd rust cargo test Best, tison. tison 于2024年4月23日周二 19:44写道： > > 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. > > 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. > > 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 >> > fury-core >> > 0.5.0 >> > >> > >> > And then the content is correct. >> >> Strictly speaking the content of the Maven reference to 0.4.1 is not >> 'incorrect'. >> The problem is that the page does not make it clear that the release >> is not an ASF release. >> >> It's OK to refer to prior releases, but the reader must be clearly >> informed of their provenance. >> >> > If we make any workaround or patch to make >> > it "look good", it would be updated as soon as 0.5.0 is released. So I >> > won't treat that as a release blocker. >> >> I would be very disappointed if the podling published the code >> *knowing* that the download page is missing or incorrect. >> >> > Best, >> > tison. >> > >> > >> > sebb 于2024年4月23日周二 15:59写道： >> > >> > > On Mon, 22 Apr 2024 at 10:11, PJ Fanning >> wrote: >> > > > >> > > > Hi Sebb, >> > > > This email thread is a vote for an RC. If this vote passes, v0.5.0 >> > > > will be the first release of Fury since it became a podling. >> > > > We will add a download page but at the moment, there is nothing to >> > > > link to there (except perhaps a KEYS file). >> > > > >> > > > The Install page does need to be updated to not mention snapshots. >> > > >> > > If 0.5.0 is to be the first ASF release, then the Install page is very >> > > misleading. >> > > >> > > There is no indication that 0.4.1 is not an ASF release. >> > > >> > > > Thanks, >> > > > PJ >> > > > >> > > > On Mon, 22 Apr 2024 at 10:35, sebb wrote: >> > > > > >> > > > > On Sat, 20 Apr 2024 at 16:26, Shawn Yang > > >> > > wrote: >> > > > > > >> > > > > > Hello everyone, >> > > > > > >> > > > > > This is a call for the vote to release Apache Fury(Incubating) >> > > v0.5.0-rc3. >> > > > > > >> > > > > > The Apache Fury
Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3
> 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. 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. 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 > > fury-core > > 0.5.0 > > > > > > And then the content is correct. > > Strictly speaking the content of the Maven reference to 0.4.1 is not > 'incorrect'. > The problem is that the page does not make it clear that the release > is not an ASF release. > > It's OK to refer to prior releases, but the reader must be clearly > informed of their provenance. > > > If we make any workaround or patch to make > > it "look good", it would be updated as soon as 0.5.0 is released. So I > > won't treat that as a release blocker. > > I would be very disappointed if the podling published the code > *knowing* that the download page is missing or incorrect. > > > Best, > > tison. > > > > > > sebb 于2024年4月23日周二 15:59写道： > > > > > On Mon, 22 Apr 2024 at 10:11, PJ Fanning wrote: > > > > > > > > Hi Sebb, > > > > This email thread is a vote for an RC. If this vote passes, v0.5.0 > > > > will be the first release of Fury since it became a podling. > > > > We will add a download page but at the moment, there is nothing to > > > > link to there (except perhaps a KEYS file). > > > > > > > > The Install page does need to be updated to not mention snapshots. > > > > > > If 0.5.0 is to be the first ASF release, then the Install page is very > > > misleading. > > > > > > There is no indication that 0.4.1 is not an ASF release. > > > > > > > Thanks, > > > > PJ > > > > > > > > On Mon, 22 Apr 2024 at 10:35, sebb wrote: > > > > > > > > > > On Sat, 20 Apr 2024 at 16:26, Shawn Yang > > > wrote: > > > > > > > > > > > > Hello everyone, > > > > > > > > > > > > This is a call for the vote to release Apache Fury(Incubating) > > > v0.5.0-rc3. > > > > > > > > > > > > The Apache Fury community has voted and approved the release of > > > Apache > > > > > > Fury(incubating) v0.5.0-rc3. We now kindly request the IPMC > members > > > > > > review and vote for this release. > > > > > > > > > > > > Apache Fury(incubating) - A blazingly fast multi-language > > > serialization > > > > > > framework powered by JIT and zero-copy. > > > > > > > > > > > > Fury community vote thread: > > > > > > https://lists.apache.org/thread/g49qt1v99d0ncfvonng39lcs1s56m7v5 > > > > > > > > > > > > Vote result thread: > > > > > > https://lists.apache.org/thread/9rtl03g650pojyfb5d67785tffyo4hbs > > > > > > > > > > > > The release candidate: > > > > > > https://dist.apache.org/repos/dist/dev/incubator/fury/0.5.0-rc3/ > > > > > > > > > > > > This release has been signed with a PGP available here: > > > > > > https://downloads.apache.org/incubator/fury/KEYS > > > > > > > > > > > > > > > > I could not find a proper download page for the release. > > > > > This must have links to the source bundle which must use > closer.lua, > > > > > as well as links to KEYS, sigs and hashes, with instructions on > how to > > > > > validate downloads. > > > > > > > > > > There is an install page on the website at > > > > > https://fury.apache.org/docs/start/install, but th
Re: [VOTE] Release Apache Fury(incubating) v0.5.0-rc3
> 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. This is an intermediate state that we would update the content as: org.apache.fury fury-core 0.5.0 And then the content is correct. If we make any workaround or patch to make it "look good", it would be updated as soon as 0.5.0 is released. So I won't treat that as a release blocker. Best, tison. sebb 于2024年4月23日周二 15:59写道： > On Mon, 22 Apr 2024 at 10:11, PJ Fanning wrote: > > > > Hi Sebb, > > This email thread is a vote for an RC. If this vote passes, v0.5.0 > > will be the first release of Fury since it became a podling. > > We will add a download page but at the moment, there is nothing to > > link to there (except perhaps a KEYS file). > > > > The Install page does need to be updated to not mention snapshots. > > If 0.5.0 is to be the first ASF release, then the Install page is very > misleading. > > There is no indication that 0.4.1 is not an ASF release. > > > Thanks, > > PJ > > > > On Mon, 22 Apr 2024 at 10:35, sebb wrote: > > > > > > On Sat, 20 Apr 2024 at 16:26, Shawn Yang > wrote: > > > > > > > > Hello everyone, > > > > > > > > This is a call for the vote to release Apache Fury(Incubating) > v0.5.0-rc3. > > > > > > > > The Apache Fury community has voted and approved the release of > Apache > > > > Fury(incubating) v0.5.0-rc3. We now kindly request the IPMC members > > > > review and vote for this release. > > > > > > > > Apache Fury(incubating) - A blazingly fast multi-language > serialization > > > > framework powered by JIT and zero-copy. > > > > > > > > Fury community vote thread: > > > > https://lists.apache.org/thread/g49qt1v99d0ncfvonng39lcs1s56m7v5 > > > > > > > > Vote result thread: > > > > https://lists.apache.org/thread/9rtl03g650pojyfb5d67785tffyo4hbs > > > > > > > > The release candidate: > > > > https://dist.apache.org/repos/dist/dev/incubator/fury/0.5.0-rc3/ > > > > > > > > This release has been signed with a PGP available here: > > > > https://downloads.apache.org/incubator/fury/KEYS > > > > > > > > > > I could not find a proper download page for the release. > > > This must have links to the source bundle which must use closer.lua, > > > as well as links to KEYS, sigs and hashes, with instructions on how to > > > validate downloads. > > > > > > There is an install page on the website at > > > https://fury.apache.org/docs/start/install, but that does not link to > > > any source bundle. > > > > > > Furthermore, the install page links to nightly snapshots; this is not > > > allowed except on a page intended for Fury developers, who should be > > > made aware that nightly code has not been vetted. > > > > > > > Git tag for the release: > > > > https://github.com/apache/incubator-fury/releases/tag/v0.5.0-rc3 > > > > > > > > Git commit for the release: > > > > > https://github.com/apache/incubator-fury/commit/fae06330edd049bb960536e978a45b97bca66faf > > > > > > > > Maven staging repo: > > > > > https://repository.apache.org/content/repositories/orgapachefury-1003 > > > > > > > > How to Build and Test, please refer to: > > > > > https://github.com/apache/incubator-fury/blob/main/docs/guide/DEVELOPMENT.md > > > > > > > > The vote will be open for at least 72 hours or until the necessary > number > > > > of votes is reached. > > > > > > > > Please vote accordingly: > > > > > > > > [ ] +1 approve > > > > [ ] +0 no opinion > > > > [ ] -1 disapprove with the reason > > > > > > > > To learn more about apache fury, please see https://fury.apache.org/ > > > > > > > > Checklist for reference: > > > > > > > > [ ] Download links are valid. > > > > [ ] Checksums and signatures. > > > > [ ] LICENSE/NOTICE files exist > > > > [ ] No unexpected binary files > > > > [ ] All source files have ASF headers > > > > [ ] Can compile from source > > > > > > > > > > > > Thanks, > > > > > > > > Chaokun Yang > > > > > > - > > > 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 > >
[DISCUSS] Drop the incubator- prefix for podling's GitHub repo
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.
Re: [REMINDER] The Apache Answer project has been waiting for votes for quite some time now
This seems to be a delayed email? I saw it arrived at 18:56+08:00, but the RESULT email concluded about half an hour ago. Best, tison. LinkinStar 于2024年4月17日周三 18:56写道： > Hello, > > The Apache Answer project has been waiting for votes way too long … would > be great, if at least one IPMC member could spare a bit of time to provide > the missing third vote. > > https://lists.apache.org/thread/lh3nvmr0gr1qh869zg76q6gcjj4ll3w0 > > Best regards, > LinkinStar >
Re: Questions about a new project entering Apache Incubator
And [1] is actually update the community docs without INFRA changes. Previously (and now?), foo.incubator.apache.org has the same content with foo.apache.org unless you explicitly ask INFRA to change. Like even https://flink.incubator.apache.org/. I guess the main "pain point" is whimsy Web check checks " foo.incubator.apache.org" in config in some file on SVN before, and thus cause the Web check having a red mark. Best, tison. tison 于2024年4月17日 周三17:02写道： > I vote in [1] since it's how we practice for quite a while and it's a > clear consensus by the vote. > > All the repo of podlings have incubator- prefix, I don't see a motivation > to change. > > In [2] it says: > > > make less work for Infra > > I wonder if INFRA complained for this process. And what is the associated > JIRA ticket in INFRA to do the rename. I'd like to take INFRA's opinion > into consideration. > > In my previous experience, keep the name "foo", let INFRA move the repo, > rename it to "incubator-foo", and drop the prefix on graduation. In this > way, the link "apache/foo" will always work with GH redirections. > > To John: > > > , it can be confusing that they do. > > What is the certain redirection causing your confusion? > > Best, > tison. > > [1] > https://lists.apache.org/thread/n18gkb23bp005gb176jnwo2nrxty3z84 > [2] > https://github.com/apache/amoro/issues/2700 > > > Sheng Wu 于2024年4月17日 周三12:09写道： > >> This is not to get the conclusion, and it is not clear, and many other >> project repositories are with this prefix. >> >> >> https://incubator.apache.org/guides/transferring.html#first_steps_outside_the_incubator >> (tison >> found) >> >> Graduation doc is there indicating incaubtor- prefix is expected. This is >> just a 10s operation on GitHub admin page, not a heavy work. Graduation is >> not happening every day, even not every month. Developer don't have to >> change remote git, as that redirect forward is supported too. >> >> More importantly, I don't agree this is clear without prefix. >> >> This us serious change, if you inist this is clear, start a vote. A lot of >> ppl in this context don't agree too. >> >> Sheng Wu 吴晟 >> >> Apache SkyWalking >> Twitter, wusheng1108 >> >> >> Justin Mclean 于2024年4月17日 周三11:59写道： >> >> > Hi, >> > >> > Both of these projects are new and just getting set up. I'd give them a >> > little time to do that. Infra in recent years have asked to minimise >> work >> > for them on graduation. We recently dropped the requirement for having >> > incubating in podling domain names so I don't see it's needed in repo >> names >> > as long as it clear the project is an incubating project. >> > Kind Regards, >> > Justin >> > >> > >> > On Wed, 17 Apr 2024, 1:47 pm Willem Jiang, >> wrote: >> > >> > > With the "incubator" profix, it's easy for us to tell if the project >> > > belongs to the incubator and it is still in the incubating process. >> > > Currently I cannot find any disclaimer document[1] in the repo root >> > > directory from [2][3] to tell if they are still in the incubator or >> > > not. >> > > >> > > [1]https://incubator.apache.org/policy/incubation.html#disclaimers >> > > [2]https://github.com/apache/amoro >> > > [3]https://github.com/apache/hertzbeat >> > > >> > > Willem Jiang >> > > >> > > On Wed, Apr 17, 2024 at 11:06 AM Calvin Kirs wrote: >> > > > >> > > > Podlings are not yet fully accepted as part of the Apache Software >> > > > Foundation. >> > > > >> > > > I haven't specifically witnessed any formal decision or process for >> > > > removing the "incubator" prefix from repository names. >> > > > >> > > > Unless there are compelling reasons to remove the "incubator" >> prefix, I >> > > > believe it's important to maintain a clear distinction between >> Podlings >> > > and >> > > > TLPs, especially in situations where confusion is likely to arise. >> > > > >> > > > On Wed, Apr 17, 2024 at 10:32 AM Sheng Wu < >> wu.sheng.841...@gmail.com> >> > > wrote: >> > > > >> > > > > Same mistake for Armoro as Hertzbeat team was misguided from >> > > > > https://github.com/apache/a
Re: Questions about a new project entering Apache Incubator
I vote in [1] since it's how we practice for quite a while and it's a clear consensus by the vote. All the repo of podlings have incubator- prefix, I don't see a motivation to change. In [2] it says: > make less work for Infra I wonder if INFRA complained for this process. And what is the associated JIRA ticket in INFRA to do the rename. I'd like to take INFRA's opinion into consideration. In my previous experience, keep the name "foo", let INFRA move the repo, rename it to "incubator-foo", and drop the prefix on graduation. In this way, the link "apache/foo" will always work with GH redirections. To John: > , it can be confusing that they do. What is the certain redirection causing your confusion? Best, tison. [1] https://lists.apache.org/thread/n18gkb23bp005gb176jnwo2nrxty3z84 [2] https://github.com/apache/amoro/issues/2700 Sheng Wu 于2024年4月17日 周三12:09写道： > This is not to get the conclusion, and it is not clear, and many other > project repositories are with this prefix. > > > https://incubator.apache.org/guides/transferring.html#first_steps_outside_the_incubator > (tison > found) > > Graduation doc is there indicating incaubtor- prefix is expected. This is > just a 10s operation on GitHub admin page, not a heavy work. Graduation is > not happening every day, even not every month. Developer don't have to > change remote git, as that redirect forward is supported too. > > More importantly, I don't agree this is clear without prefix. > > This us serious change, if you inist this is clear, start a vote. A lot of > ppl in this context don't agree too. > > Sheng Wu 吴晟 > > Apache SkyWalking > Twitter, wusheng1108 > > > Justin Mclean 于2024年4月17日 周三11:59写道： > > > Hi, > > > > Both of these projects are new and just getting set up. I'd give them a > > little time to do that. Infra in recent years have asked to minimise work > > for them on graduation. We recently dropped the requirement for having > > incubating in podling domain names so I don't see it's needed in repo > names > > as long as it clear the project is an incubating project. > > Kind Regards, > > Justin > > > > > > On Wed, 17 Apr 2024, 1:47 pm Willem Jiang, > wrote: > > > > > With the "incubator" profix, it's easy for us to tell if the project > > > belongs to the incubator and it is still in the incubating process. > > > Currently I cannot find any disclaimer document[1] in the repo root > > > directory from [2][3] to tell if they are still in the incubator or > > > not. > > > > > > [1]https://incubator.apache.org/policy/incubation.html#disclaimers > > > [2]https://github.com/apache/amoro > > > [3]https://github.com/apache/hertzbeat > > > > > > Willem Jiang > > > > > > On Wed, Apr 17, 2024 at 11:06 AM Calvin Kirs wrote: > > > > > > > > Podlings are not yet fully accepted as part of the Apache Software > > > > Foundation. > > > > > > > > I haven't specifically witnessed any formal decision or process for > > > > removing the "incubator" prefix from repository names. > > > > > > > > Unless there are compelling reasons to remove the "incubator" > prefix, I > > > > believe it's important to maintain a clear distinction between > Podlings > > > and > > > > TLPs, especially in situations where confusion is likely to arise. > > > > > > > > On Wed, Apr 17, 2024 at 10:32 AM Sheng Wu > > > > wrote: > > > > > > > > > Same mistake for Armoro as Hertzbeat team was misguided from > > > > > https://github.com/apache/amoro/issues/2700 > > > > > > > > > > This is not discussed AFAIK, and the description is not correct. > > > > > GitHub supported renaming and repository path forward automatically > > > > > years ago. apache/incubator-foo -> apache/foo is transparent and > both > > > > > addresses work. > > > > > > > > > > This should not be changed randomly considering many other projects > > > > > are using incubator- prefix. This renaming causes confusion. IPMC > are > > > > > making sure the website has `incubating` and disclaimer as always, > > > > > suddenly some projects even could use repository names without > > > > > prefixes. This is wrong. > > > > > > > > > > Mentors of Armoro and Hertzbeat should follow the existing > > > > > requirements, and PPMC members of these two
Re: [RESULT][VOTE] Release Apache HoraeDB(incubating) v2.0.0-RC6 - Incubator Vote Round 2
Cool. I encourage the RM to drop a vote on his/her release and the voter on dev@ to convey their vote on general@ also. Best, tison. 任春韶 于2024年4月16日周二 16:06写道： > The vote passes with 5 +1s and no negative votes. There were 4 binding +1s. > > Vote Thread: > https://lists.apache.org/thread/dmc4x441jxjqkbzzxqo1j6tzpy72jcrz > > Votes: > ShaoFeng Shi (binding) > Xuanwo (binding) > suyan > Li Gang (binding) > tison (binding) > > Thanks to everyone who participated in the development and review. I will > proceed with the release. >
Re: [VOTE] Release Apache HoraeDB(incubating) v2.0.0-RC6 - Incubator Vote Round 2
+1 (binding) I checked - Files have the word incubating in their name. - Checksums and signatures are valid. - DISCLAIMER,LICENSE and NOTICE files exist. - No unexpected Binary Files. - LICENSE and NOTICE files look good to me. - Build from source with `make` One suggestion: the license information can be conveyed in the LICENSE file, not the NOTCIE file. This is not a release blocker for such an incubating release. Best, tison. li gang 于2024年4月10日周三 20:33写道： > +1 (binding) > I checked > - Files have the word incubating in their name. > - Checksums and signatures are valid. > - DISCLAIMER,LICENSE and NOTICE files exist. > - No unexpected Binary Files. > - LICENSE and NOTICE files look good to me. > > 任春韶 于2024年4月9日周二 15:44写道： > > > Hello, Incubator Community, > > > > This is a call for a vote to release Apache HoraeDB(incubating) version > > v2.0.0-RC6 > > > > HoraeDB PPMC Vote Thread > > https://lists.apache.org/thread/clhrgx4mzfq2jc2m9w5y783dvp378wx8 > > > > HoraeDB PPMC Vote Result > > https://lists.apache.org/thread/tkp2bkm0y88dpyvkn2c831h8poctxl0w > > > > The release candidate: > > > > > https://dist.apache.org/repos/dist/dev/incubator/horaedb/horaedb/v2.0.0-rc.6 > > > > This release has been signed with a PGP available here: > > https://downloads.apache.org/incubator/horaedb/KEYS > > > > Git tag for the release > > https://github.com/apache/incubator-horaedb/releases/tag/v2.0.0-rc.6 > > > > Git commit id for the release: > > > > > https://github.com/apache/incubator-horaedb/commit/1c56d2b1d70fc740fc6a62b92b4ac0cbd5f904d7 > > > > Please download, verify, and test. > > > > The VOTE will pass after got 3 binding approve. > > > > [ ] +1 approve > > [ ] +0 no opinion > > [ ] -1 disapprove with the reason > > > > To learn more about Apache HoraeDB, please see > https://horaedb.apache.org/ > > > > Checklist for reference: > > > > [ ] Download links are valid. > > [ ] Checksums and signatures. > > [ ] LICENSE/NOTICE files exist > > [ ] No unexpected binary files > > [ ] All source files have ASF headers > > [ ] Can compile from source > > > > Thanks > > > > > -- > > > -- > Best Regards > Gang Li 李岗 > > lgcar...@apache.org >
Re: Trademarks and incubation (was: [DISCUSS] Graduate Apache AGE Incubating as a Top Level Project)
Related discussions - https://lists.apache.org/thread/oc9jft1tyo7cbphcyrtwobf4w5rcbhfw I'll try to send a more complete reply in days. In short, let's update the maturity model and provide more case studies. Best, tison. Shane Curcuru 于2024年4月3日周三 19:33写道： > Question: where did the incubation process fail in this case? How can > we prevent something like this from happening again? > > On 2021/12/20 22:50:13 Eya Badal Abdisho wrote: > > Hello Justin, > > > > Thank you for your feedback. Please find more information following: > > ...snip...> - There are some minor trademark issues on the Bitnine site > e.g [2] → All > > will be fixed in a day. > > One issue today is that both the Bitnine site advertises several > software products with names that start with "AGE...", including a > graph-based tool. The other issue is that AgeDB is a company using > similar names and branding as Apache Age. > > These issues clearly weren't fixed, nor do they appear to really have > been seriously addressed in the past two years. > >https://bitnine.net/ >https://agedb.io/ > > ...snip... > > - I notice one person who replied to this thread had a agedb.io email > > address - what is it relationship with the project? > > > > Agedb is a US startup (incorporated in California May this year) and is > > affiliated with Bitnine Global, who contributed the original AGE source > > codes to the Apache Software Foundation. The purpose of Agedb is not yet > > clearly defined but it is expected to be to provide graph database > > solutions and related services. > > I definitely appreciate our Incubator mentors, who do an incredible job > in their volunteer time. Helping build communities is hard work, and is > to be celebrated. > > How can we improve documentation, education, or training so that the > below sentence would leap out at any mentor as a "You can't do that!" > > "purpose of Agedb is ... provide graph database solutions and related > services" > > Given we were trying to incubate Apache AGE as a graph database, the > above sentence is literally describing trademark infringement! How can > we make it easier to ensure podlings and their donating organizations > actually take trademark transfer seriously? > > -- > - Shane >Member >The Apache Software Foundation > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Update project maturity model to include trademark and branding?
cc @Shane Here is a related thread we ever initialized. I'm trying to find some time to pick it up, but yet to achieve it. Best, tison. tison 于2023年12月29日周五 15:21写道： > Besides, the maturity model is applied for all ASF projects and under the > management of ComDev pmc. > > Shall we cc this thread to dev@community.a.o or start a new thread after > we have a consensus within the Incubator first? > > Best, > tison. > > > tison 于2023年12月29日 周五12:58写道： > >> > This varies from project to project: >> > 1. Some projects have PMC members working at a company who use their >> trademark, and they make sure that things are correctly done. >> > 2. Some projects have people who actively look out for these types of >> issues and report them. >> > 3. Some projects are more active and set up automated Google searches >> and the like. >> > 4. Not all issues occur on web pages. Some of these issues arise at >> conferences or 3rd party events and are often noticed by PMC members or ASF >> members. >> >> Could you name projects of 3? "Some" is hard to follow, if there is a >> concrete podling/TLP does the thing correctly, we can reuse the >> workflow. >> >> > Yes, in most cases, the PMC should spend time addressing it. >> >> Could you name projects that do well in this direction? >> >> > how the project wishes to implement this is up to them. >> >> As mentors, we should help the podling to follow certain policies, >> either we can verify it by actionable check items or references. >> Otherwise it's totally subjective according to a member's >> interpretation it and it can increase the burden. >> >> Looking at the policy, it writes[1]: >> >> > COMPLY WITH APACHE BRAND POLICY >> > All PMCs must to comply with the Apache Project Branding Requirements. >> If your project does not comply, or is having issues in determining >> compliance, including a recognition of this set of PMC responsibilities to >> handle brand issues, work with trademarks@ to resolve the issue. >> > Much as complying with Apache legal policy to ensure that our software >> is safely covered under our license, projects must follow the branding >> requirements to ensure that we maintain our projects' brands and the Apache >> brand - and public reputations - for the future benefit of all of Apache >> projects. >> >> So how a PMC complies with the policy is that you should comply with >> the policy .. circular definition. >> >> Of course, there are other scattered docs having sentences on this >> topic, but since we are currently talking about this, we'd better >> foster a clear actionable guideline, or at lest feeling how a podling >> suffers when they are searching these sentences. >> >> We don't stop podling by requiring them comply with guidelines, we >> help them to follow. >> >> Best, >> tison. >> >> [1] https://www.apache.org/foundation/marks/responsibility#compliance >> >> tison 于2023年12月29日周五 12:39写道： >> > >> > > TB50 Any existing previous domain names are in control of the PMC. >> > >> > This is hard to follow. If the domain names are under the donating >> > compay's top domain, said if there is a foo.google.com, shall the PMC >> > take control of Google? >> > >> > > TB60 Any existing trademarks have been or are in the process of being >> transferred to the ASF. >> > >> > Just in case the trademarks are donated to ASF in the proposal. Given >> > Ignite as an example, GridGain doesn't donate its "GridGain InMemory >> > Platform" trademark but choose a new trademark "Ignite". So "GridGain" >> > trademark is still held by GridGain Systems. >> > >> > I believe this process should be done with the signed SGAs so if SGAs >> > are signed properly, this guideline is followed. >> > >> > Best, >> > tison. >> > >> > tison 于2023年12月29日周五 12:33写道： >> > > >> > > >> It seems the updated podling report template has not had the >> impact it was hoped to have around issues of branding and trademarks. >> > > >> > > > For example, a doable mechanism is that, during each quarter's >> report, >> > > > the (P)PMC includes a section on what checks they did and if they >> > > > found any 3rdparty misuse. >> > > >> > > And this report to be included for TLPs also. Podlings are to be a >> > > TLP.
Re: New project invitations
Here is the source https://github.com/apache/www-site/blob/main/content/licenses/contributor-agreements.md Check the readme for how to preview locally or by creating a preview branch. It's a foundation wise repo so you should have the permission for push. Best, tison. Xuanwo 于2024年3月21日 周四12:53写道： > Firstly, we can enhance the document at > https://www.apache.org/licenses/contributor-agreements.html by adding > clearer instructions on how to complete the forms. I'm ready to tackle this > task. Where can I find the repository to get started? > > Then, I believe the mentors should be responsible for guiding new initial > committers > on how to correctly fill out the ICLA forms. > > On Thu, Mar 21, 2024, at 12:20, Craig Russell wrote: > > I have seen several instances where initial committers send ICLAs to > > secretary with this text: > > > > Hello Apache, > > I am willing to contribute to the ASF. The attachment is my ICLA > > information. My Github account is : > > > > This is bad. Most of the ICLAs do not have sufficient information to > > allow secretary to process the forms and create the new accounts. > > > > Where is this information? How can we improve it so that submitters > include: > > > > full residence address > > full name > > proper requested ASF id > > podling name > > signature (not script font) > > date > > > > We really can do better, but we have to have better documentation. > > > > Craig L Russell > > c...@apache.org > > > > > > - > > 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: [VOTE] Graduate Apache SDAP (Incubating) as a Top Level Project
+1 binding So this is the VOTE thread. I remember that we almost reached a consensus on SDAP's graduation days before :D Best, tison. Julian Hyde 于2024年3月17日周日 08:43写道： > +1 (binding) > > ...and good luck! > > Julian > > On Fri, Mar 15, 2024 at 3:19 PM Riley Kuttruff wrote: > > > > Hi all, > > > > Following the positive feedback we received in the DISCUSS thread [1], > > we would like to open the official VOTE to graduate now. > > > > Below are some facts and project highlights from the incubation phase as > > well as the draft resolution: > > > > - Our community consists of 21 committers, with 2 being mentors and > > the remaining 19 serving as our PPMC > > - Several pending and planned invites to bring on new committers and/or > > PPMC members from additional organizations > > - Completed 3 releases with 3 release managers > > - Our software is currently being utilized by organizations such as NASA > > Jet Propulsion Laboratory, NSF National Center for Atmospheric Research, > > Florida State University, and George Mason University in support of > projects > > such as the NASA Sea Level Change Portal, Estimating the Circulation and > > Climate of the Ocean (ECCO) project, GRACE/GRACE-FO, Cloud-based > > Data Match-Up Service, Integrated Digital Earth Analysis System (IDEAS), > > and many others. > > - Opened 400+ PRs across 3 main code repositories, 350+ of which are > > merged or closed (some are pending our next release) > > - Maturity model self assessment [2] > > > > Please vote on the resolution below the line to graduate and establish > > Apache SDAP as a Top-Level Project > > > > [ ] +1 Graduate Apache SDAP from the Incubator to a TLP > > [ ] 0 No opinion > > [ ] -1 Do not graduate Apache SDAP because… > > > > This vote will remain open for at least 72 hours. > > > > We’d like to also extend a sincere thank you to our mentors, current and > > former for their invaluable insight and assistance with getting us to > this > > point. > > > > Thank you, Julian, Jörn, Trevor, Lewis, Suneel, and Raphael! > > > > We’d also like to thank the SDAP community as well as the Incubator > > community for your time and support in getting us to where we are now. > > > > [1] https://lists.apache.org/thread/pv21d9kf05166hkj89lv11s65oyvbdrk > > [2] > https://github.com/apache/incubator-sdap-website/blob/asf-site/maturity.md > > > > --- > > > > Establish the Apache SDAP Project > > > > WHEREAS, the Board of Directors deems it to be in the best interests of > > the Foundation and consistent with the Foundation's purpose to establish > > a Project Management Committee charged with the creation and maintenance > > of open-source software, for distribution at no charge to the public, > > related to an integrated data analytic center for Big Science problems. > > > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee > > (PMC), to be known as the "Apache SDAP Project", be and hereby is > > established pursuant to Bylaws of the Foundation; and be it further > > > > RESOLVED, that the Apache SDAP Project be and hereby is responsible > > for the creation and maintenance of software related to an integrated > data > > analytic center for Big Science problems; and be it further > > > > RESOLVED, that the office of "Vice President, Apache SDAP" be and > > hereby is created, the person holding such office to serve at the > > direction of the Board of Directors as the chair of the Apache SDAP > > Project, and to have primary responsibility for management of the > > projects within the scope of responsibility of the Apache SDAP > > Project; and be it further > > > > RESOLVED, that the persons listed immediately below be and hereby are > > appointed to serve as the initial members of the Apache SDAP Project: > > > > - Edward M Armstrong > > - Nga Thien Chung > > - Thomas Cram > > - Frank Greguska > > - Thomas Huang > > - Julian Hyde > > - Joseph C. Jacob > > - Jason Kang > > - Riley Kuttruff > > - Thomas G Loubrieu > > - Kevin Marlis > > - Stepheny Perez > > - Wai Linn Phyo > > > > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Nga Thien Chung > > be appointed to the office of Vice President, Apache SDAP, to serve in > > accordance with and subject to the direction of the Board of Directors > > and the Bylaws
Re: [VOTE] Accept GraphAr into the ASF Incubator
+1 binding Best, tison. Kent Yao 于2024年3月15日 周五16:18写道： > +1 binding & Good luck! > > Kent Yao > > Calvin Kirs 于2024年3月15日周五 14:02写道： > > > > +1 binding > > > > On Fri, Mar 15, 2024 at 1:58 PM Yu Li wrote: > > > > > Hi All, > > > > > > With positive feedback from the proposal discussion [1], I am starting > > > this official vote to accept GraphAr into the Incubator. Here is the > > > proposal: > > > > > > https://cwiki.apache.org/confluence/display/INCUBATOR/GraphArProposal > > > > > > Please cast your vote: > > > [ ] +1, accept GraphAr into the Incubator > > > [ ] +0, I don't care either way > > > [ ] -1, do not accept GraphAr into the Incubator, because... > > > > > > The vote will open for one week from today, 15 March, 2024. Thanks. > > > > > > Best Regards, > > > Yu > > > > > > [1] https://lists.apache.org/thread/bldz3rnp8nvhlmrd2gqkl30fgk9z3zhx > > > > > > - > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > -- > > Best wishes！ > > CalvinKirs > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Podling web sites: make (incubator.) optional in podling urls
+1 binding Best, tison. Zhang Yonglun 于2024年3月13日周三 12:12写道： > +1 binding > > -- > > Zhang Yonglun > Apache ShenYu & ShardingSphere > > Craig Russell 于2024年3月13日周三 02:38写道： > > > > After this discussion > > https://lists.apache.org/thread/frwsy1g1pkx3ppbvzt538xxh9qo9y319 > > I'd like to propose that we make the incubator. part of the URL optional > for podlings. > > > > This is a way to minimize the work needed to graduate. No redirect or > reimplementation of the web site is required. > > > > https://incubator.apache.org/guides/branding.html will need to change > only the URL requirement. Other branding requirements are still applicable. > > > > While most podlings do have incubator. in their URL, several do not and > it is a flag for the web site checker. > > > > +1 make incubator. optional in URL > > +0 do not care strongly > > -1 keep the requirement for incubator. in URL > > > > Please vote with your ASF id followed by (binding) if you are a member > of the Incubator PMC or (not binding) if not. > > > > Vote will be open for at least 72 hours. > > > > Here is my +1 > > > > Craig L Russell > > c...@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: [VOTE] Graduate Apache Paimon (Incubating) as a Top Level Project
+1 binding Good project. Best, tison. Xin Wang 于2024年3月9日周六 15:18写道： > > +1, binding > > Becket Qin 于2024年3月9日周六 11:24写道： > > > +1 (binding) > > > > Cheers, > > > > Jiangjie (Becket) Qin > > > > > > > > On Fri, Mar 8, 2024 at 4:49 PM Calvin Kirs wrote: > > > > > +1 binding > > > > > > On Fri, Mar 8, 2024 at 7:05 PM Nicholas wrote: > > > > > > > > +1(non-binding) > > > > > > > > > > > > Regards, > > > > Nicholas Jiang > > > > > > > > > > > > - Original Message - > > > > From: "Yu Li" > > > > To: general@incubator.apache.org > > > > Sent: Fri, 8 Mar 2024 18:50:36 +0800 > > > > Subject: [VOTE] Graduate Apache Paimon (Incubating) as a Top Level > > > Project > > > > > > > > Hi All, > > > > > > > > We've got positive feedback on the DISCUSS thread for graduation [1], > > > > and would like to start an official VOTE thread now. > > > > > > > > Below are some facts and project highlights from the incubation phase > > > > as well as the draft resolution: > > > > > > > > - Currently, our community consists of 18 committers (including > > > > mentors) from ~10 different companies, with 11 serving as PPMC > > > > members. > > > > - So far, we have boasted 132 contributors. > > > > - Throughout the incubation period, we've made 5 releases in 12 > > > > months, at a stable pace. > > > > - We've had 3 different release managers to date. > > > > - Our software is used in production by 20+ well known entities. > > > > - As yet, we have opened 1,363 issues with 1,083 successfully > > > > resolved, including the period as a sub-project of Apache Flink. > > > > - We have submitted a total of 2,166 PRs, out of which 2,091 have been > > > > merged or closed. > > > > - We have met all maturity criteria as outlined in [2]. > > > > > > > > Please vote on the resolution pasted below to graduate Apache Paimon > > > > from the Incubator to the Top Level Project. > > > > > > > > [ ] +1 Graduate Apache Paimon from the Incubator. > > > > [ ] +0 No opinion. > > > > [ ] -1 Don't graduate Apache Paimon from the Incubator because ... > > > > > > > > This vote will open for at least 72 hours. > > > > > > > > We would like to thank everyone who has participated in the Apache > > > > Paimon community. We would also like to thank the Apache Incubator > > > > community as well as Apache Infrastructure team and general ASF > > > > community for your support. > > > > > > > > [1] https://lists.apache.org/thread/012rfy2zvnhqh39foncwvdpvy9fzry1q > > > > [2] > > > > > https://cwiki.apache.org/confluence/display/PAIMON/Apache+Maturity+Model+Assessment+for+Paimon > > > > > > > > --- > > > > > > > > Establish the Apache Paimon Project > > > > > > > > WHEREAS, the Board of Directors deems it to be in the best interests of > > > > the Foundation and consistent with the Foundation's purpose to > > establish > > > > a Project Management Committee charged with the creation and > > maintenance > > > > of open-source software, for distribution at no charge to the public, > > > > related to a unified lake storage to build dynamic tables for both > > > > stream and batch processing with big data compute engines, supporting > > > > high-speed data ingestion and real-time data query. > > > > > > > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee > > > > (PMC), to be known as the "Apache Paimon Project", be and hereby is > > > > established pursuant to Bylaws of the Foundation; and be it further > > > > > > > > RESOLVED, that the Apache Paimon Project be and hereby is responsible > > > > for the creation and maintenance of software related to a unified lake > > > > storage to build dynamic tables for both stream and batch processing > > > > with big data compute engines, supporting high-speed data ingestion and > > > > real-time data query; and be it further > > > > > > > > RESOLVED, that the
Re: [DISCUSS] Incubating Proposal for StormCrawler
A minor comment: > We are planning to build the https://stormcrawler.apache.org website with > Jekyll, maybe based on https://github.com/apache/apache-website-template. This branch is unmaintained for years (although some volunteers show their interests, there is no move so far) and you may encounter many issues. I suggest you use Fury site as a template (PJ is also a mentor of Fury) and adjust to your content. I'm also working on a Docusaurus based website template [1] recently. Best, tison. [1] https://github.com/apache/apache-website-template/tree/docusaurus PJ Fanning 于2024年3月8日周五 02:29写道： > > Thanks Lewis. It would be great if you can act as a menot. I will > update the proposal to add you to the mentor list. > > On Thu, 7 Mar 2024 at 19:09, Lewis John McGibbney wrote: > > > > I think StromCrawler would be an excellent candidate for the Incubator. > > If the podling is looking for an additional mentor, I would be happy to > > chip in. > > lewismc > > > > On 2024/03/03 23:24:38 PJ Fanning wrote: > > > Hi everyone, > > > > > > I would like to propose StormCrawler [1] as a new Apache Incubator > > > project, > > > and you can examine the proposal [2] for more details. > > > > > > StormCrawler is a collection of resources for building low-latency, > > > customisable and scalable web crawlers on Apache Storm. > > > > > > Proposal > > > > > > The aim of StormCrawler is to help build web crawlers that are: > > > > > > * scalable > > > * resilient > > > * low latency > > > * easy to extend > > > * polite yet efficient > > > > > > StormCrawler achieves this partly with Apache Storm, which it is based > > > on. To use an analogy, Apache Storm is to StormCrawler what Apache > > > Hadoop is to Apache Nutch. > > > > > > StormCrawler is mature (26 releases to date) and is used by many > > > organisations world-wide. > > > > > > Initial Committers > > > > > > Julien Nioche [jnio...@apache.org https://github.com/jnioche] > > > Sebastian Nagel [sna...@apache.org https://github.com/sebastian-nagel] > > > Richard Zowalla [r...@apache.org https://github.com/rzo1] > > > Tim Allison [talli...@apache.org https://github.com/tballison] > > > Michael Dinzinger [michael.dinzin...@uni-passau.de > > > https://github.com/michaeldinzinger] > > > > > > Most of the existing StormCrawler contributors are existing ASF > > > committers and are looking to build a vibrant community following the > > > Apache Way. > > > > > > I will help this project as the champion and mentor. We would welcome > > > additional mentors, if anyone has an interest in helping. > > > > > > We are looking forward to your questions and feedback. > > > > > > Thanks, > > > PJ > > > > > > [1] https://github.com/DigitalPebble/storm-crawler > > > [2] > > > https://cwiki.apache.org/confluence/display/INCUBATOR/StormCrawler+Proposal > > > > > > - > > > 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 > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Request for Temporary Exception for LGPL Dependency in Apache KIE Podling
Thanks for reaching out Alex :D I agree with PJ and emphasize that we should highlight the license issue on release. Also, for others in this thread, the thorough solution described above is: > The Hibernate team is in the process of relicensing from LGPL to Apache > License 2.0. To Alex: How much confidence do you have in this direction? Are you involved in this effort? What if the relicensing doesn't happen? Do you have an alternative plan? Best, tison. Alex Porcelli 于2024年3月6日周三 01:25写道： > > Thank you PJ! This is very helpful! > > On Tue, Mar 5, 2024 at 12:23 PM PJ Fanning wrote: > > > > https://incubator.apache.org/policy/incubation.html#disclaimers > > > > Have a look at the Disclaimers doc. If you use the WIP Disclaimer then you > > can do releases that are not fully ASF compliant. It would be good to > > document clearly about this dependency license issue. > > > > > > > > On Tue 5 Mar 2024, 17:53 Alex Porcelli, wrote: > > > > > Dear Members of the Apache Incubator, > > > > > > I hope this email finds you well. My name is Alex Porcelli, and I am > > > part of the Apache KIE podling community [1]. I am reaching out to > > > discuss a matter regarding a dependency we have under LGPL, which > > > falls under Category X according to Apache guidelines. > > > > > > The dependency is Hibernate ORM [2], the only supported JPA provider > > > for Quarkus [3] - the primary runtime provider for Apache KIE podling. > > > > > > However, I'd like to emphasize the urgency of our situation. Our > > > community has dedicated substantial effort over the past six months to > > > prepare for our initial Apache release. Unfortunately, this delay in > > > releasing Apache KIE is unprecedented for this community, and it is > > > critical for us to deliver new releases promptly. Not only does our > > > large user base eagerly anticipate a new release, but older versions > > > may also pose security vulnerabilities (CVEs). Additionally, with our > > > previous release process through Red Hat decommissioned, Apache now > > > stands as our sole means of distribution. > > > > > > Given these circumstances, I kindly ask the Apache Incubator to > > > consider granting us a temporary exception to maintain the LGPL > > > dependency for our initial releases. We understand the importance of > > > adhering to Apache licensing requirements and are willing to make > > > necessary adjustments while ensuring compliance. However, we believe > > > that allowing us to proceed with proper disclaimers in place would > > > enable us to maintain momentum and meet the expectations of our user > > > community. > > > > > > Furthermore, I would like to inform you that the Hibernate team is in > > > the process of relicensing from LGPL to ASLv3, as indicated in their > > > recent blog post [4]. This transition aligns with our long-term goals > > > and demonstrates our commitment to compliance with Apache guidelines. > > > > > > We are open to any guidance or suggestions from the Incubator PMC on > > > how best to proceed. > > > > > > Thank you for considering our request. > > > > > > Best regards, > > > Alex Porcelli > > > Apache KIE Podling Community Member > > > > > > [1] - Apache KIE: https://kie.apache.org/ > > > [2] - Hibernate ORM: https://hibernate.org/orm/ > > > [3] - Quarkus: https://quarkus.io/ > > > [4] - Blog post on relicensing: https://in.relation.to/2023/11/18/license/ > > > > > > - > > > 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: [DISCUSS] Incubating Proposal for GraphAr
Hi Justin, I checked the initial committers group and that is, according to [1][2] Initial Committers * Weibin Zeng (Alibaba, weibin@gmail.com) -> @acezen #1 in the contributor graph * Xue Li (Alibaba, lx_cla...@qq.com) -> @lixueclaire #2 in the contributor graph * Zhe Wang (Southwest Minzu University, thesp...@qq.com) -> @Thespica #3 in the contributor graph * Semyon Sinchenko (Raiffeisen Bank International, ssinche...@protonmail.com) -> @SemyonSinchenko #5 in the contributor graph * He Tao (Alibaba, sighing...@gmail.com) -> @sighingnow in the contributor graph. Starting from #6, commits are <=5. Note that the "main project repo" mentioned here is "alibaba/GraphAr" [1]. It seems you are using alibaba/GraphScope as the source, which is a downstream project of the proposed project; it's not included in the donation proposal. Best, tison. [1] https://github.com/alibaba/GraphAr/graphs/contributors [2] https://cwiki.apache.org/confluence/display/INCUBATOR/GraphArProposal Justin Mclean 于2024年3月4日周一 14:59写道： > > HI, > > I was looking at your initial committer list and noticed, according to > GitHub, that: > - sighingnow is #1 in activity > - acezen is #6 in activity > - lixueclaire is #30 in activity > - Thespica is not a commmiter in the main project. Is the repo elsewhere, and > does that intend to be donated to teh ASF? > - SemyonSinchenko is not a committer in the main project. Is the repo > elsewhere, and does that intend to be donated to the ASF? > > While contributions to a project can be in other forms other than code, I can > count six other people who have made 100+ commits to the main repo. Why are > they not included in the initial committer list? > > Kind Regards, > Justin > - > 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: Re: [VOTE] Have Amoro join the Incubator
+1 binding I knew people running Amoro for a while. Wish you a good journey :D Best, tison. Nicholas 于2024年3月4日周一 08:33写道： > > +1 non-binding > Regards, > Nicholas Jiang > > At 2024-03-04 06:17:39, "Craig Russell" wrote: > >+1 binding > > > >Good luck, > >Craig > > > >> On Mar 2, 2024, at 17:44, Justin Mclean wrote: > >> > >> Hi, > >> > >> Following on from the discussion of the Amoro proposal [1][2], let's vote > >> on having it join the Incubator. > >> > >> Please cast your vote: > >> > >> [ ] +1, have it join the Incubator as an incubating project > >> [ ] +0, I have no strong opinion either way > >> [ ] -1, do not have it join the Incubator because... > >> > >> Kind Regards, > >> Justin > >> > >> 1. https://cwiki.apache.org/confluence/display/INCUBATOR/AmoroProposal > >> 2. https://lists.apache.org/thread/7t2bm6x19zq2d79cn8jj2wqd3f2t3k00 > > > >Craig L Russell > >c...@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: [DISCUSS] Incubating Proposal for GraphAr
Confirm as a mentor. This project looks interesting and is in good shape for starting as a podling. Two questions here: 1. I saw a Google Group channel for this project [1]. What is the plan to maintain or archive this channel? 2. I saw a Slack workspace for this project [2]. What is the plan to maintain or archive this channel? Best, tison. [1] graphar+subscr...@googlegroups.com [2] https://join.slack.com/t/grapharworkspace/shared_invite/zt-1wh5vo828-yxs0MlXYBPBBNvjOGhL4kQ Yu Li 于2024年3月1日周五 20:38写道： > > Hi All, > > I would like to propose GraphAr [1] as a new apache incubator project, > and you can find the proposal [2] for more details. > > GraphAr is an open source and language independent data file format > designed for efficient graph data storage and retrieval. It aims at > supplying a standard format for large-scale graph data storage and > processing that can be used by diverse existing graph systems, such as > Neo4j, Nebula Graph, and Apache HugeGraph, to reduce the overhead when > various systems work together. Specifically, it provides the following > features: > > 1. Efficient format: GraphAr maintains the CSR (Compressed Sparse Row) > and CSC (Compressed Sparse Column) semantics of graph data, partitions > the data into chunks for parallel access, and leverages > high-performance columnar storage formats (Parquet and ORC) for data > file organizing. > 2. Out-of-core queries: GraphAr is designed for out-of-core scenarios, > enabling the storage and querying of large-scale graphs outside of > memory, such as in data lakes. > 3. Cross-language support: GraphAr provides libraries in C++, Java, > Scala with Spark, and Python with PySpark for generating, accessing, > and transforming files in GraphAr format > > GraphAr is currently adopted in the production environment at Alibaba > and used in Fabarta and TuGraph. The community is still in its early > age but with good shape and diversity, with 5 core developers and 14 > contributors from different organizations. Given the extensive need in > the graph community for a standardized file format, we believe the > developer and user communities will continue to grow. > > The proposed initial committers are interested in joining ASF, and > believe they could reinforce extensive collaboration and build a more > vibrant community following the Apache Way. > > I will help this project as the champion and mentor, and many thanks > to our three other mentors: > > * Calvin Kirs (k...@apache.org) > * tison (ti...@apache.org) > * Xiaoqiao He (hexiaoq...@apache.org) > > Look forward to your feedback. Thanks. > > Best Regards, > Yu > > [1] https://github.com/alibaba/GraphAr > [2] https://cwiki.apache.org/confluence/display/INCUBATOR/GraphArProposal - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Graduate Apache SDAP (Incubating) as a Top Level Project
+1 binding Good project. Good luck! Best, tison. Jean-Baptiste Onofré 于2024年3月1日周五 23:49写道： > > +1 (binding) > > I don't see any blocker for graduation. > > Regards > JB > > On Thu, Feb 22, 2024 at 7:01 PM Riley Kuttruff wrote: > > > > Hi all, > > > > Apache SDAP joined Incubator in October 2017. In the time since, we've > > made significant progress towards maturing our community and our > > project and adopting the Apache Way. > > > > After community discussion [1][2][3], the community has voted [4] that we > > would like to proceed with graduation [5]. We now call upon the Incubator > > PMC to review and discuss our progress and would appreciate any and all > > feedback towards graduation. > > > > Below are some facts and project highlights from the incubation phase as > > well as the draft resolution: > > > > - Our community consists of 21 committers, with 2 being mentors and > > the remaining 19 serving as our PPMC > > - Several pending and planned invites to bring on new committers and/or > > PPMC members from additional organizations > > - Completed 2 releases with 2 release managers - with a 3rd release run by > > a 3rd release manager in progress > > - Our software is currently being utilized by organizations such as NASA > > Jet Propulsion Laboratory, NSF National Center for Atmospheric Research, > > Florida State University, and George Mason University in support of projects > > such as the NASA Sea Level Change Portal, Estimating the Circulation and > > Climate of the Ocean (ECCO) project, GRACE/GRACE-FO, Cloud-based > > Data Match-Up Service, Integrated Digital Earth Analysis System (IDEAS), > > and many others. > > - Opened 400+ PRs across 3 main code repositories, 350+ of which are > > merged or closed (some are pending our next release) > > - Maturity model self assessment [6] > > > > We have resolved all branding issues we are aware of: logo, GitHub, > > Website, etc > > > > We’d like to also extend a sincere thank you to our mentors, current and > > former for their invaluable insight and assistance with getting us to this > > point. > > > > Thank you, Julian, Jörn, Trevor, Lewis, Suneel, and Raphael! > > > > --- > > > > Establish the Apache SDAP Project > > > > WHEREAS, the Board of Directors deems it to be in the best interests of > > the Foundation and consistent with the Foundation's purpose to establish > > a Project Management Committee charged with the creation and maintenance > > of open-source software, for distribution at no charge to the public, > > related to an integrated data analytic center for Big Science problems. > > > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee > > (PMC), to be known as the "Apache SDAP Project", be and hereby is > > established pursuant to Bylaws of the Foundation; and be it further > > > > RESOLVED, that the Apache SDAP Project be and hereby is responsible > > for the creation and maintenance of software related to an integrated data > > analytic center for Big Science problems; and be it further > > > > RESOLVED, that the office of "Vice President, Apache SDAP" be and > > hereby is created, the person holding such office to serve at the > > direction of the Board of Directors as the chair of the Apache SDAP > > Project, and to have primary responsibility for management of the > > projects within the scope of responsibility of the Apache SDAP > > Project; and be it further > > > > RESOLVED, that the persons listed immediately below be and hereby are > > appointed to serve as the initial members of the Apache SDAP Project: > > > > - Edward M Armstrong > > - Nga Thien Chung > > - Thomas Cram > > - Frank Greguska > > - Thomas Huang > > - Julian Hyde > > - Joseph C. Jacob > > - Jason Kang > > - Riley Kuttruff > > - Thomas G Loubrieu > > - Kevin Marlis > > - Stepheny Perez > > - Wai Linn Phyo > > > > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Nga Thien Chung > > be appointed to the office of Vice President, Apache SDAP, to serve in > > accordance with and subject to the direction of the Board of Directors > > and the Bylaws of the Foundation until death, resignation, retirement, > > removal or disqualification, or until a successor is appointed; and be it > > further > > > > RESOLVED, that the Apache SDAP Project be and hereby is tasked with > &g
Re: Podling web sites: .incubator. required?
+1 for me. While I don't dig into the details, for the podlings I mentored, although we only ask for the name.apache.org domain, there is a name.incubator.apache.org online redirected to name.apache.org. Best, tison. Justin Mclean 于2024年2月28日周三 10:21写道： > > HI, > > > I would propose that as part of our official policy we recommend the > > podling's url as https://podling.apache.org and get rid of the .incubator. > > in the url. > > > > WDYT? > > > +1 from me. > > Kind Regards, > Justin > - > 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] Graduate Apache Pekko (incubating) as a TLP
+1 (binding) Let's rock. Best, tison. Craig Russell 于2024年2月28日周三 00:37写道： > > +1 for graduation (binding) > > It's a good sign for you to take care of the KEYS and TM so quickly! > Craig > > > On Feb 26, 2024, at 09:41, PJ Fanning wrote: > > > > Thanks Craig. I have created a PR to fix the KEYS link and add 'tm' to > > Apache Pekko on the main page. > > > > https://github.com/apache/incubator-pekko-site/pull/87 > > > > > > On Mon, 26 Feb 2024 at 18:14, Craig Russell wrote: > >> > >> Hi, > >> > >> I noticed a few items that may be problematic if not resolved before the > >> board votes on the resolution: > >> > >> 1. The home page https://pekko.apache.org has Apache Pekko in the first > >> prominent usage but does not use a TM symbol as in Apache Pekko™. > >> 2. The downloads page https://pekko.apache.org/download.html KEYS file for > >> verifying checksums should link to the dist.apache.org file not the source > >> repository. > >> https://dist.apache.org/repos/dist/release/incubator/pekko/KEYS > >> Of course, this should link to the non-incubator file once you have a > >> release as a TLP. > >> > >> Other than that, looks good. > >> > >> Good luck, > >> Craig > >> > >>> On Feb 26, 2024, at 03:24, PJ Fanning wrote: > >>> > >>> Hi everyone, > >>> > >>> We have positive feedback on the Pekko Vote thread [1] (result [2]). > >>> > >>> I'd like to start an official Incubator VOTE thread now. > >>> > >>> Below are some facts and project highlights from the incubation phase > >>> as well as the draft resolution: > >>> > >>> * All modules have at least a v1.0.0 release > >>> * 19 releases (across 12 modules) [3] > >>> * Evidence of good uptake of the Pekko releases and a large number of > >>> ecosystem libs now support Pekko - over 100 non Apache libraries use > >>> Pekko libs under the hood > >>> * well over 1000 PRs merged > >>> * 25+ code contributors > >>> * We've had 3 different release managers to date. > >>> * dozens more users who have been involved in discussions, code > >>> reviews, raising issues, etc. > >>> * We have met all maturity criteria as outlined in [4]. > >>> > >>> > >>> Please vote on the resolution pasted below to graduate Apache Pekko > >>> from the Incubator to the Top Level Project. > >>> > >>> [ ] +1 Graduate Apache Pekko from the Incubator. > >>> [ ] +0 No opinion. > >>> [ ] -1 Don't graduate Apache Pekko from the Incubator because ... > >>> > >>> This vote will open for at least 72 hours. > >>> > >>> I would like to thank everyone who have participated in the Apache > >>> Pekko community. I would also like to thank the Apache Incubator > >>> community as well as Apache Infrastructure team and general ASF > >>> community for your support. > >>> > >>> > >>> [1] https://lists.apache.org/thread/q7jjmp7zpcxko607v5hvj514dyf6o8bx > >>> [2] https://lists.apache.org/thread/tsb7b8bkgfkts1nstmj413qocztj0s5o > >>> [3] https://incubator.apache.org/projects/pekko.html > >>> [4] > >>> https://cwiki.apache.org/confluence/display/PEKKO/Apache+Maturity+Model+Assessment+for+Pekko > >>> > >>> > >>> > >>> --- > >>> > >>> Establish the Apache Pekko Project > >>> > >>> > >>> WHEREAS, the Board of Directors deems it to be in the best interests > >>> of the Foundation and consistent with the Foundation's purpose to > >>> establish a Project Management Committee charged with the creation and > >>> maintenance of open-source software, for distribution at no charge to > >>> the public, related to Pekko: a toolkit and an ecosystem for building > >>> highly concurrent, distributed, reactive and resilient applications > >>> for Java and Scala. > >>> > >>> > >>> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee > >>> (PMC), to be known as the "Apache Pekko Project", be and hereby is > >>> established pursuant to Bylaws of the Foundation; and be it further > >>> > >>> > >>&
Re: [VOTE] Release Apache Pekko(Incubating) HTTP 1.0.3-M1-RC1
+1 binding + Download links valid + LICENSE / NOTICE / DISCLAIMER exist + Signature and checksum match + Can compile from source with: sbt compile nit: the KEYS file link should be https://downloads.apache.org/incubator/pekko/KEYS. It's in sync with https://dist.apache.org/repos/dist/release/incubator/pekko/KEYS but preferred. Best, tison. Suyan 于2024年2月21日周三 01:20写道： > > +1 non-binding > > [x] Download links are valid. > [x] Checksums and signatures. > gpg: Signature made Thu Feb 15 20:44:16 2024 CST > gpg:using EDDSA key FF992B876CA27A76139C4619F8B1B4404F9F0EE2 > gpg:issuer "enge...@apache.org" > gpg: Good signature from "Arnout Engelen " [ultimate] > [x] LICENSE/NOTICE files exist > [x] No unexpected binary files > [x] Source files have ASF headers > [x] Can compile from source on macOS(arm64) > [success] Total time: 555 s (09:15), completed 2024年2月21日 上午1:08:26 > > Sincerely, > Suyan > > Arnout Engelen 于2024年2月20日周二 05:54写道： > > > > Hello Incubator Community, > > > > This is a call for a vote to release Apache Pekko(incubating) version > > 1.0.3-M1-RC1. > > > > The discussion thread: > > > > https://lists.apache.org/thread/4cm4xmqz5t3l5p8qfvm72rzv58jj3rym > > > > The Pekko vote thread: > > > > https://lists.apache.org/thread/lcpdv1w27f8vsqq4cp93dgxvtm8zjcdm > > > > The Pekko vote result: > > > > https://lists.apache.org/thread/0n1d7ohbmrmm0x6nbng9pv7zn6ws1t94 > > > > The release candidate: > > > > https://dist.apache.org/repos/dist/dev/incubator/pekko/1.0.3-M1-RC1/ > > > > This release has been signed with a PGP key, available here: > > > > https://dist.apache.org/repos/dist/release/incubator/pekko/KEYS > > > > Release Notes: > > > > https://github.com/apache/incubator-pekko/blob/v1.0.3-M1-RC1/docs/src/main/paradox/release-notes/index.md#103-m1 > > > > Git tag for the release: > > > > https://github.com/apache/incubator-pekko/tree/v1.0.3-M1-RC1 > > Git commit ID: 7bdd230acc228ba0e99fe027165af1cf5451ffc8 > > > > Please download, verify, and test. > > > > We have also staged jars in the Apache Nexus Repository. These were > > built with the same code as appears in this Source Release Candidate. We > > would appreciate if users could test with these too. > > If anyone finds any serious problems with these jars, please also notify us > > on this thread. > > > > https://repository.apache.org/content/groups/staging/org/apache/pekko/ > > > > In sbt, you can add this resolver. > > > > resolvers += "Apache Pekko Staging" at " > > https://repository.apache.org/content/groups/staging; > > > > The vote will be left open for at least 72 hours. > > > > [ ] +1 approve > > [ ] +0 no opinion > > [ ] -1 disapprove with the reason > > > > To learn more about Apache Pekko, please see https://pekko.apache.org/ > > > > Checklist for reference: > > > > [ ] Download links are valid. > > [ ] Checksums and signatures. > > [ ] LICENSE/NOTICE files exist > > [ ] No unexpected binary files > > [ ] Source files have ASF headers > > [ ] Can compile from source > > > > To compile from the source, please refer to: > > > > https://github.com/apache/incubator-pekko-http/blob/main/README.md#building-from-source > > > > Some notes about verifying downloads can be found at: > > > > https://pekko.apache.org/download.html#verifying-downloads > > > > > > Here is my +1 (non-binding). > > > > Thanks, > > Arnout Engelen (Apache Pekko PPMC member) > > - > 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
[NOTICE] Incubation Report for February 2024
Hi, I'm trying to create an Incubation Report page for February 2024 at [1], including the following podlings according to the report group info that they should report in this month: * answer * fury * horaedb * streampark But it still lacks information that I need some help: 1. What is the desired timeline and shepherd assignments? 2. Missing IPMC level report. Perhaps the only way is going through the mailing list? 3. Missing other projects need a report. I guess we have a script to list out from the podling.xml file, but I don't find it. I may write it when I have some spare time if there is no one. I don't promise :P Best, tison. [1] https://cwiki.apache.org/confluence/display/INCUBATOR/February2024 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: (apache-website-template) branch jekyll created (now f2f8a9e)
It's currently a brand new branch. You can check it in the repo. Best, tison. sebb 于2024年2月22日 周四01:11写道： > On Wed, 21 Feb 2024 at 09:25, tison wrote: > > > > Hi sebb, > > > > Your comments sound like back to the switching default branch solution (a > > new branch with history only adding the README becomes the default). > > I am saying that if the 3 branch solution is adopted the docusaurus > branch should be created as a new branch. > > > Or you prefer other ways to the same repo direction. > > > > Also is it possible we go back to the COMDEV dedicated thread so that > > people can easily follow the context? If we agree, the context here can > be > > brought there. > > > > Best, > > tison. > > > > > > sebb 于2024年2月21日 周三16:27写道： > > > > > On Wed, 21 Feb 2024 at 00:28, tison wrote: > > > > > > > > Hi Dave, > > > > > > > > > One approach is to find good examples of each build technique. If > you > > > look back at older projects you will see various historical waves of > > > technique. > > > > > > > > I agree, and that's why I'd prefer a multi branches solution with a > > > > default branch containing README for redirects. > > > > > > However, if a repo is shared in this way, such disjoint branches > > > should be initially created as empty orphans. > > > Replacing all the files with different ones makes for a confusing > history. > > > > > > > From another perspective, it's still valuable to provide a template > > > > for new podlings to get started _now_, and if someone (in this case, > > > > it's me) volunteers to provide one for help, there is no reason we > > > > reject it by the tech will fade _years later_. > > > > > > > > Best, > > > > tison. > > > > > > > > Dave Fisher 于2024年2月21日周三 08:17写道： > > > > > > > > > > Hi Tison, > > > > > > > > > > I’m following along. Infrastructure has a Pelican template site > that > > > is out of date: https://github.com/apache/template-site/ > > > > > > > > > > One approach is to find good examples of each build technique. If > you > > > look back at older projects you will see various historical waves of > > > technique. > > > > > > > > > > Best, > > > > > Dave > > > > > > > > > > > On Feb 20, 2024, at 3:48 PM, tison wrote: > > > > > > > > > > > > Hi Dave, > > > > > > > > > > > > Thanks for picking up this commit. You may join the discussion at > > > [1]. > > > > > > > > > > > > I have all the permission to follow what I want. But since > > > > > > apache-website-template is technically a foundation-wise repo > and I'm > > > > > > a newcomer here, I'd like to listen to people's opinions before > > > moving > > > > > > forward; especially there can be some arguments. > > > > > > > > > > > > Best, > > > > > > tison. > > > > > > > > > > > > [1] > https://lists.apache.org/thread/tvry49gdclqqdtdcgk0x9hnl18vlxnm8 > > > > > > > > > > > > Dave Fisher 于2024年2月21日周三 02:35写道： > > > > > >> > > > > > >> From the commit email it looks like this repository belongs to > the > > > Incubator. > > > > > >> > > > > > >>> On Feb 14, 2024, at 2:27 AM, ti...@apache.org wrote: > > > > > >>> > > > > > >>> This is an automated email from the ASF dual-hosted git > repository. > > > > > >>> > > > > > >>> tison pushed a change to branch jekyll > > > > > >>> in repository > > > https://gitbox.apache.org/repos/asf/apache-website-template.git > > > > > >>> > > > > > >>> > > > > > >>> at f2f8a9e Update download page template > > > > > >>> > > > > > >>> No new revisions were added by this update. > > > > > >>> > > > > > >>> > > > > > >>> > > > - > > > > > >>> To unsubscribe,
Re: (apache-website-template) branch jekyll created (now f2f8a9e)
Hi sebb, Your comments sound like back to the switching default branch solution (a new branch with history only adding the README becomes the default). Or you prefer other ways to the same repo direction. Also is it possible we go back to the COMDEV dedicated thread so that people can easily follow the context? If we agree, the context here can be brought there. Best, tison. sebb 于2024年2月21日 周三16:27写道： > On Wed, 21 Feb 2024 at 00:28, tison wrote: > > > > Hi Dave, > > > > > One approach is to find good examples of each build technique. If you > look back at older projects you will see various historical waves of > technique. > > > > I agree, and that's why I'd prefer a multi branches solution with a > > default branch containing README for redirects. > > However, if a repo is shared in this way, such disjoint branches > should be initially created as empty orphans. > Replacing all the files with different ones makes for a confusing history. > > > From another perspective, it's still valuable to provide a template > > for new podlings to get started _now_, and if someone (in this case, > > it's me) volunteers to provide one for help, there is no reason we > > reject it by the tech will fade _years later_. > > > > Best, > > tison. > > > > Dave Fisher 于2024年2月21日周三 08:17写道： > > > > > > Hi Tison, > > > > > > I’m following along. Infrastructure has a Pelican template site that > is out of date: https://github.com/apache/template-site/ > > > > > > One approach is to find good examples of each build technique. If you > look back at older projects you will see various historical waves of > technique. > > > > > > Best, > > > Dave > > > > > > > On Feb 20, 2024, at 3:48 PM, tison wrote: > > > > > > > > Hi Dave, > > > > > > > > Thanks for picking up this commit. You may join the discussion at > [1]. > > > > > > > > I have all the permission to follow what I want. But since > > > > apache-website-template is technically a foundation-wise repo and I'm > > > > a newcomer here, I'd like to listen to people's opinions before > moving > > > > forward; especially there can be some arguments. > > > > > > > > Best, > > > > tison. > > > > > > > > [1] https://lists.apache.org/thread/tvry49gdclqqdtdcgk0x9hnl18vlxnm8 > > > > > > > > Dave Fisher 于2024年2月21日周三 02:35写道： > > > >> > > > >> From the commit email it looks like this repository belongs to the > Incubator. > > > >> > > > >>> On Feb 14, 2024, at 2:27 AM, ti...@apache.org wrote: > > > >>> > > > >>> This is an automated email from the ASF dual-hosted git repository. > > > >>> > > > >>> tison pushed a change to branch jekyll > > > >>> in repository > https://gitbox.apache.org/repos/asf/apache-website-template.git > > > >>> > > > >>> > > > >>> at f2f8a9e Update download page template > > > >>> > > > >>> No new revisions were added by this update. > > > >>> > > > >>> > > > >>> > - > > > >>> To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org > > > >>> For additional commands, e-mail: cvs-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: dev-unsubscr...@community.apache.org > > > > For additional commands, e-mail: dev-h...@community.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 > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: (apache-website-template) branch jekyll created (now f2f8a9e)
Hi Dave, > One approach is to find good examples of each build technique. If you look > back at older projects you will see various historical waves of technique. I agree, and that's why I'd prefer a multi branches solution with a default branch containing README for redirects. >From another perspective, it's still valuable to provide a template for new podlings to get started _now_, and if someone (in this case, it's me) volunteers to provide one for help, there is no reason we reject it by the tech will fade _years later_. Best, tison. Dave Fisher 于2024年2月21日周三 08:17写道： > > Hi Tison, > > I’m following along. Infrastructure has a Pelican template site that is out > of date: https://github.com/apache/template-site/ > > One approach is to find good examples of each build technique. If you look > back at older projects you will see various historical waves of technique. > > Best, > Dave > > > On Feb 20, 2024, at 3:48 PM, tison wrote: > > > > Hi Dave, > > > > Thanks for picking up this commit. You may join the discussion at [1]. > > > > I have all the permission to follow what I want. But since > > apache-website-template is technically a foundation-wise repo and I'm > > a newcomer here, I'd like to listen to people's opinions before moving > > forward; especially there can be some arguments. > > > > Best, > > tison. > > > > [1] https://lists.apache.org/thread/tvry49gdclqqdtdcgk0x9hnl18vlxnm8 > > > > Dave Fisher 于2024年2月21日周三 02:35写道： > >> > >> From the commit email it looks like this repository belongs to the > >> Incubator. > >> > >>> On Feb 14, 2024, at 2:27 AM, ti...@apache.org wrote: > >>> > >>> This is an automated email from the ASF dual-hosted git repository. > >>> > >>> tison pushed a change to branch jekyll > >>> in repository > >>> https://gitbox.apache.org/repos/asf/apache-website-template.git > >>> > >>> > >>> at f2f8a9e Update download page template > >>> > >>> No new revisions were added by this update. > >>> > >>> > >>> - > >>> To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org > >>> For additional commands, e-mail: cvs-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: dev-unsubscr...@community.apache.org > > For additional commands, e-mail: dev-h...@community.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: ResilientDB Bootstrap missing Mailing Lists
Hi Mohammad, For this specific issue, you or your mentors should be able to self-serve creating the necessary list on [1]. As in your proposal [2], they are: * resilientdb-private (with moderated subscriptions) -> priv...@resilientdb.apache.org * resilientdb-dev -> dev@@resilientdb.apache.org * resilientdb-commits -> comm...@resilientdb.apache.org * resilientdb-user -> u...@resilientdb.apache.org Generally, you should deal with such questions with your mentors. I recommend you read [3][4] for more details about running a podling. Best, tison. [1] https://selfserve.apache.org/mailinglist-new.html [2] https://cwiki.apache.org/confluence/display/INCUBATOR/ResilientDBProposal [3] https://incubator.apache.org/guides/roles_and_responsibilities.html [4] https://incubator.apache.org/cookbook/ Mohammad Sadoghi 于2024年2月21日周三 08:09写道： > > Dear Dave, > > Hope you are safe and well. > > Thank you for identifying this issue; how can we correct it? > > --- > Best Regards, > Mohammad Sadoghi, PhD > Associate Professor > Exploratory Systems Lab (ExpoLab) > Department of Computer Science > University of California, Davis > > ExpoLab: https://expolab.org/ > ResilientDB: https://resilientdb.com/ > Phone: 914-319-7937 > > > On Mon, Feb 19, 2024 at 3:57 PM Dave Fisher wrote: > > > Hi - > > > > Perhaps the podling status file in svn was not properly updated? > > > > Best, > > Dave > > > > > On Feb 19, 2024, at 3:51 PM, Dave Fisher wrote: > > > > > > Hi - > > > > > > Please have a look at > > https://incubator.apache.org/clutch/resilientdb.html > > > > > > Where are the mailing lists? Where is the website? > > > > > > Best, > > > Dave > > > > > > - > > > 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: (apache-website-template) branch jekyll created (now f2f8a9e)
Hi Dave, Thanks for picking up this commit. You may join the discussion at [1]. I have all the permission to follow what I want. But since apache-website-template is technically a foundation-wise repo and I'm a newcomer here, I'd like to listen to people's opinions before moving forward; especially there can be some arguments. Best, tison. [1] https://lists.apache.org/thread/tvry49gdclqqdtdcgk0x9hnl18vlxnm8 Dave Fisher 于2024年2月21日周三 02:35写道： > > From the commit email it looks like this repository belongs to the Incubator. > > > On Feb 14, 2024, at 2:27 AM, ti...@apache.org wrote: > > > > This is an automated email from the ASF dual-hosted git repository. > > > > tison pushed a change to branch jekyll > > in repository > > https://gitbox.apache.org/repos/asf/apache-website-template.git > > > > > > at f2f8a9e Update download page template > > > > No new revisions were added by this update. > > > > > > - > > To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org > > For additional commands, e-mail: cvs-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: [RESULT][VOTE] Release Apache HoraeDB-Proto(incubating) v2.0.0-RC1 - Incubator Vote Round 1
I've released the Maven artifacts closed and staged. Please remember to pull the trigger the next time :D Best, tison. 谭睿翔(Ruixiang Tan) 于2024年2月8日周四 13:28写道： > > The vote passes with 6 +1s and no negative votes. There were 3 binding +1s. > Vote Thread > https://lists.apache.org/thread/j165o1c02pm9lkc4b13b6vncygz72w7j > Votes > Kumfo Yang > suyan > Xuanwo > tison (binding) ShaoFeng Shi (binding) Li Gang (binding) Thanks to everyone > who participated in the development and review. I will proceed with the > release. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Update Website Template (WAS: Help to get the Wayang project website in shape)
I've pushed the code to 'docusarus' branch on this repo, and file a ticket on INFRA [1] to ask for some privileges actions. Best, tison. [1] https://issues.apache.org/jira/browse/INFRA-25486 tison 于2024年2月10日周六 18:32写道： > > It seems that the repo is foundation-wise that I have the permission to move > forward this effort. > > I'll push the branch and update the README. And then ask for INFRA to make it > the default branch, as well as setting the repo as a repo template. > > I believe comdev and the Incubator are related to these actions so I post > here for visibility, and welcome any feedback if you second this or have > suggestions. > > Best, > tison. > > > tison 于2024年2月4日 周日23:16写道： >> >> Hi, >> >> I finally find some time to prepare a demo for the new website template [1]. >> >> It may still open to be improved including a download page template >> and a community page template, as well as some guides as its docs. But >> I'd like to first collecting feedback and finding which PMC is >> responsible for this repository [2]. >> >> The background is that our current template is quite old and not >> updated for the past six years. Few people understand those techniques >> and have a hard time to build their own site. Also, new policy >> compliance and new techniques benefits can be included in the template >> to help new projects (podlings) build a wonderful site. >> >> I'm glad to maintain this repo but I find myself has no permission >> over this repo. So again, which PMC is responsible for this >> repository? >> >> Best, >> tison. >> >> [1] https://github.com/tisonkun/apache-website-template/tree/docusaurus >> [2] https://github.com/apache/apache-website-template/ >> >> Alex Porcelli 于2024年1月30日周二 04:53写道： >> > >> > Another shout-out for tison and the Apache Fury to provide such a nice >> > starting point for new websites. >> > >> > I managed to put, for now, a simple placeholder website for Apache KIE >> > (incubation). >> > >> > Thank you tison and the Apache Fury community! >> > >> > On Fri, Jan 26, 2024 at 4:10 AM Xuanwo wrote: >> > > >> > > > I managed to move our old website to Docusaurus in one day - using the >> > > > template >> > > > structure from Fury, if you don’t mind. >> > > >> > > Congrats! >> > > >> > > On Fri, Jan 26, 2024, at 17:07, Alexander Alten-Lorenz wrote: >> > > > Hey tison, >> > > > >> > > > Thank you for the head-up. I managed to move our old website to >> > > > Docusaurus in one day - using the template structure from Fury, if you >> > > > don’t mind. Awesome stuff, would love when we’d had a template for the >> > > > podlings to setup a good looking, SEO friendly project page. That’s >> > > > needed to grow the community! >> > > > >> > > > Cheers, thanks again, >> > > > —Alex >> > > > >> > > >> On Jan 25, 2024, at 12:01, tison wrote: >> > > >> >> > > >> Hi Alexander, >> > > >> >> > > >> I use Docusaurus for Kvrocks and Fury. Their configuration should be >> > > >> straightforward to follow already. The most simple one now is >> > > >> https://github.com/apache/incubator-fury-site. >> > > >> >> > > >> Also, Docu is well-documented https://docusaurus.io/docs. >> > > >> >> > > >> I'm thinking of updating the website template [1] with Docu but have >> > > >> not yet had time and understand which PMC manages this project. >> > > >> >> > > >> Best, >> > > >> tison. >> > > >> >> > > >> [1] https://github.com/apache/apache-website-template >> > > >> >> > > >> Alexander Alten-Lorenz 于2024年1月25日周四 >> > > >> 18:20写道： >> > > >>> >> > > >>> Hi Xuanwo, >> > > >>> >> > > >>> Thank you, highly appreciated! Do you have any how-to for setting >> > > >>> Docusaurus up? >> > > >>> >> > > >>> —Alex >> > > >>> >> > > >>>> On Jan 25, 2024, at 11:01, Xuanwo wrote: >> > > >>>> >> > > >>>> Hi, alexander >> > > >>>
Re: Update Website Template (WAS: Help to get the Wayang project website in shape)
It seems that the repo is foundation-wise that I have the permission to move forward this effort. I'll push the branch and update the README. And then ask for INFRA to make it the default branch, as well as setting the repo as a repo template. I believe comdev and the Incubator are related to these actions so I post here for visibility, and welcome any feedback if you second this or have suggestions. Best, tison. tison 于2024年2月4日 周日23:16写道： > Hi, > > I finally find some time to prepare a demo for the new website template > [1]. > > It may still open to be improved including a download page template > and a community page template, as well as some guides as its docs. But > I'd like to first collecting feedback and finding which PMC is > responsible for this repository [2]. > > The background is that our current template is quite old and not > updated for the past six years. Few people understand those techniques > and have a hard time to build their own site. Also, new policy > compliance and new techniques benefits can be included in the template > to help new projects (podlings) build a wonderful site. > > I'm glad to maintain this repo but I find myself has no permission > over this repo. So again, which PMC is responsible for this > repository? > > Best, > tison. > > [1] https://github.com/tisonkun/apache-website-template/tree/docusaurus > [2] https://github.com/apache/apache-website-template/ > > Alex Porcelli 于2024年1月30日周二 04:53写道： > > > > Another shout-out for tison and the Apache Fury to provide such a nice > > starting point for new websites. > > > > I managed to put, for now, a simple placeholder website for Apache KIE > > (incubation). > > > > Thank you tison and the Apache Fury community! > > > > On Fri, Jan 26, 2024 at 4:10 AM Xuanwo wrote: > > > > > > > I managed to move our old website to Docusaurus in one day - using > the template > > > > structure from Fury, if you don’t mind. > > > > > > Congrats! > > > > > > On Fri, Jan 26, 2024, at 17:07, Alexander Alten-Lorenz wrote: > > > > Hey tison, > > > > > > > > Thank you for the head-up. I managed to move our old website to > > > > Docusaurus in one day - using the template structure from Fury, if > you > > > > don’t mind. Awesome stuff, would love when we’d had a template for > the > > > > podlings to setup a good looking, SEO friendly project page. That’s > > > > needed to grow the community! > > > > > > > > Cheers, thanks again, > > > > —Alex > > > > > > > >> On Jan 25, 2024, at 12:01, tison wrote: > > > >> > > > >> Hi Alexander, > > > >> > > > >> I use Docusaurus for Kvrocks and Fury. Their configuration should be > > > >> straightforward to follow already. The most simple one now is > > > >> https://github.com/apache/incubator-fury-site. > > > >> > > > >> Also, Docu is well-documented https://docusaurus.io/docs. > > > >> > > > >> I'm thinking of updating the website template [1] with Docu but have > > > >> not yet had time and understand which PMC manages this project. > > > >> > > > >> Best, > > > >> tison. > > > >> > > > >> [1] https://github.com/apache/apache-website-template > > > >> > > > >> Alexander Alten-Lorenz 于2024年1月25日周四 > 18:20写道： > > > >>> > > > >>> Hi Xuanwo, > > > >>> > > > >>> Thank you, highly appreciated! Do you have any how-to for setting > Docusaurus up? > > > >>> > > > >>> —Alex > > > >>> > > > >>>> On Jan 25, 2024, at 11:01, Xuanwo wrote: > > > >>>> > > > >>>> Hi, alexander > > > >>>> > > > >>>>> We aren't web designers and we would love to find helping hands > to get > > > >>>>> the page in order, including re-organizing and rewriting. > > > >>>> > > > >>>> I'm with the OpenDAL Community, and we also lack web designers. > Our community > > > >>>> opted for Docusaurus[1], which we found easy to start with and > set up. It > > > >>>> offers a decent theme suitable for open-source projects. For > reference, you > > > >>>> can check out OpenDAL's homepage[2]. We hope our experience > proves useful. > > > >>>> > > > >>>> [1] https://docusaurus.io/ > > > >>>> [2] https://opendal.apache.org/ > > > >>>> > > > >>>> On Thu, Jan 25, 2024, at 16:26, Alexander Alten wrote: > > > >>>>> Hi incubator community, > > > >>>>> > > > >>>>> Would anyone be willing to help the Wayang project with our > website? > > > >>>>> We aren't web designers and we would love to find helping hands > to get > > > >>>>> the page in order, including re-organizing and rewriting. > > > >>>>> > > > >>>>> thank you, cheers, > > > >>>>> --alexander > > > >>>> > > > >>>> -- > > > >>>> Xuanwo > > > -- > > > Xuanwo >
Re: [VOTE] Release Apache Pekko(Incubating) HTTP 1.0.1-RC2
+1 binding * Verified Checksums * Verified Signatures * NOTICE / LICENSE / DISCLAIMER exist * Verified Incubating in name * Built from source with 'sbt compile' Best, tison. Ayush Saxena 于2024年2月7日周三 19:59写道： > > +1 (Binding) > > * Verified Checksums > * Verified Signatures > * DISCLAIMER file exists > * Verified NOTICE & LICENSE files. > * Verified Incubating in name. > * Validated no code diff b/w git tag and src tar > * Built from source > > Thanx PJ Fanning for driving the release. Good Luck!!! > > -Ayush > > On Wed, 7 Feb 2024 at 16:27, PJ Fanning wrote: > > > Hi everyone, > > > > We are still short on binding votes to release this. Would any of the > > Pekko mentors or any other IPMC member have time to review this? > > > > This release contains a security hardening option related to the HTTP/2 > > Rapid Reset issue. > > > > Thanks, > > PJ > > > > On 2024/01/31 17:45:16 Xuanwo wrote: > > > Hi, PJ Fanning > > > > > > Thanks for the explaination. > > > > > > > I will post something on the Pekko Dec > > > > mailing list seeking volunteers. We have 2 more releases under > > discussion > > > > and some more that we could be looking at. > > > > > > Thanks for the effort! > > > > > > > The release guide is at > > > > https://github.com/apache/incubator-pekko-site/wiki/Pekko-HTTP-Release > > > > > > I created a PR[1] for adding links to "How to Contribute". I hope it can > > be > > > helpful for future reference. > > > > > > [1] https://github.com/apache/incubator-pekko-site/pull/83 > > > > > > On Wed, Jan 31, 2024, at 23:19, PJ Fanning wrote: > > > > Thanks Xuanwo for the review and comments. I agree that we need to get > > more > > > > people involved in the releases. I will post something on the Pekko Dec > > > > mailing list seeking volunteers. We have 2 more releases under > > discussion > > > > and some more that we could be looking at. > > > > > > > > The release guide is at > > > > https://github.com/apache/incubator-pekko-site/wiki/Pekko-HTTP-Release > > > > > > > > This page is a few comments that highlight diffs from the main release > > > > guide linked on that page. > > > > > > > > > > > > On Wed 31 Jan 2024, 15:35 Xuanwo, wrote: > > > > > > > >> Hi, PJ Fanning > > > >> > > > >> Before starting my check, I noticed that almost all releases are > > handled > > > >> by you > > > >> (please correct me if I'm mistaken). Additionally, I observed that > > > >> pekko.apache.org > > > >> does not currently have a release guide. I would like to inquire > > whether > > > >> it is > > > >> possible to involve other PPMC members in the release process. I > > believe > > > >> it is > > > >> important to have multiple release managers. > > > >> > > > >> Here is my checks and vote. > > > >> > > > >> +1 non-binding > > > >> > > > >> [x] Download links are valid. > > > >> [x] Checksums and signatures. > > > >> > > > >> apache-pekko-http-1.0.1-incubating-src-20240128.tgz > > > >> gpg: Signature made Sun 28 Jan 2024 08:45:20 PM CST > > > >> gpg:using RSA key > > 6BA4DA8B1C88A49428A29C3D0C69C1EF41181E13 > > > >> gpg: Good signature from "PJ Fanning (GitHub noreply address) < > > > >> pjfann...@users.noreply.github.com>" [ultimate] > > > >> gpg: aka "PJ Fanning " > > [ultimate] > > > >> gpg: aka "PJ Fanning (http://www.apache.org/) < > > > >> fannin...@apache.org>" [ultimate] > > > >> > > > >> [x] LICENSE/NOTICE files exist > > > >> [x] No unexpected binary files > > > >> [x] Source files have ASF headers > > > >> [x] Can compile from source > > > >> > > > >> Build passed on archlinux x86_64 > > > >> > > > >> [info] compiling 14 Scala sources to > > > >> > > /tmp/HTTP-1.0.1-RC2/apache-pekko-http-1.0.1-incubating-src-20240128/http-bench-jmh/target/scala-2.13/classes > > > >> ... > > > >> [success] Total
Re: [VOTE] Release Apache Answer(Incubating) v1.2.5-RC2
Carry my +1 binding from dev@ vote. Best, tison. Xuanwo 于2024年2月6日 周二11:25写道： > +1 non-binding > > [x] Download links are valid. > [x] Checksums and PGP signatures are valid. > > gpg: Signature made Tue 30 Jan 2024 06:43:07 PM CST > gpg:using RSA key 5684B6E344546A5F3CE9850D380DCBD5C34934CC > gpg: Good signature from "LinkinStar (for apache release create at > 20231220) " [ultimate] > apache-answer-1.2.5-incubating-bin-darwin-amd64.tar.gz: OK > gpg: Signature made Tue 30 Jan 2024 06:43:11 PM CST > gpg:using RSA key 5684B6E344546A5F3CE9850D380DCBD5C34934CC > gpg: Good signature from "LinkinStar (for apache release create at > 20231220) " [ultimate] > apache-answer-1.2.5-incubating-bin-darwin-arm64.tar.gz: OK > gpg: Signature made Tue 30 Jan 2024 06:43:11 PM CST > gpg:using RSA key 5684B6E344546A5F3CE9850D380DCBD5C34934CC > gpg: Good signature from "LinkinStar (for apache release create at > 20231220) " [ultimate] > apache-answer-1.2.5-incubating-bin-linux-amd64.tar.gz: OK > gpg: Signature made Tue 30 Jan 2024 06:43:11 PM CST > gpg:using RSA key 5684B6E344546A5F3CE9850D380DCBD5C34934CC > gpg: Good signature from "LinkinStar (for apache release create at > 20231220) " [ultimate] > apache-answer-1.2.5-incubating-bin-linux-arm64.tar.gz: OK > gpg: Signature made Tue 30 Jan 2024 06:43:11 PM CST > gpg:using RSA key 5684B6E344546A5F3CE9850D380DCBD5C34934CC > gpg: Good signature from "LinkinStar (for apache release create at > 20231220) " [ultimate] > apache-answer-1.2.5-incubating-bin-windows-amd64.tar.gz: OK > gpg: Signature made Tue 30 Jan 2024 06:43:12 PM CST > gpg:using RSA key 5684B6E344546A5F3CE9850D380DCBD5C34934CC > gpg: Good signature from "LinkinStar (for apache release create at > 20231220) " [ultimate] > apache-answer-1.2.5-incubating-src.tar.gz: OK > > [x] Source code distributions have correct names matching the current > release. > [x] LICENSE and NOTICE files are correct for each Answer repo. > > nit: the licenserc.toml files seems specify a wrong copyright owner. > > ```toml > [properties] > inceptionYear = 2023 > copyrightOwner = "tison " > ``` > > [x] All files have license headers if necessary. > [x] No unlicensed compiled archives bundled in source archive. > [x] build passed on archlinux x86_64 > > make build 136.16s user 16.38s system 235% cpu 1:04.67 total > > On Tue, Feb 6, 2024, at 11:11, LinkinStar wrote: > > Hello, > > > > This is a call for vote to release Apache Answer(Incubating) version > > v1.2.5-RC2. > > > > The vote thread: > > https://lists.apache.org/thread/qjsmh7y4fb946pso5nwrbfjntfydhslh > > > > Vote Result: > > https://lists.apache.org/thread/89jgwznxn69296nxl5fn5jtd9ywcndog > > > > The release candidates: > > > > > https://dist.apache.org/repos/dist/dev/incubator/answer/1.2.5-incubating-RC2/ > > > > Release notes: > > > https://github.com/apache/incubator-answer/releases/tag/v1.2.5-RC2 > > > > Git tag for the release: > > > https://github.com/apache/incubator-answer/releases/tag/v1.2.5-RC2 > > > > Git commit id for the release: > > > > > https://github.com/apache/incubator-answer/commit/5132cb391238cf26d3d206403b5b737451fd189a > > > > Keys to verify the Release Candidate: > > The artifacts signed with PGP key [C34934CC], corresponding to [ > > linkins...@apache.org], that can be found in keys file: > > https://dist.apache.org/repos/dist/release/incubator/answer/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 > > > > Checklist for reference: > > > > [ ] Download links are valid. > > [ ] Checksums and PGP signatures are valid. > > [ ] Source code distributions have correct names matching the current > > release. > > [ ] LICENSE and NOTICE files are correct for each Answer repo. > > [ ] All files have license headers if necessary. > > [ ] No unlicensed compiled archives bundled in source archive. > > > > To compile from the source, please refer to: > > > > https://github.com/apache/incubator-answer#building-from-source > > > > Thanks, > > LinkinStar > > -- > Xuanwo > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Update Website Template (WAS: Help to get the Wayang project website in shape)
Hi, I finally find some time to prepare a demo for the new website template [1]. It may still open to be improved including a download page template and a community page template, as well as some guides as its docs. But I'd like to first collecting feedback and finding which PMC is responsible for this repository [2]. The background is that our current template is quite old and not updated for the past six years. Few people understand those techniques and have a hard time to build their own site. Also, new policy compliance and new techniques benefits can be included in the template to help new projects (podlings) build a wonderful site. I'm glad to maintain this repo but I find myself has no permission over this repo. So again, which PMC is responsible for this repository? Best, tison. [1] https://github.com/tisonkun/apache-website-template/tree/docusaurus [2] https://github.com/apache/apache-website-template/ Alex Porcelli 于2024年1月30日周二 04:53写道： > > Another shout-out for tison and the Apache Fury to provide such a nice > starting point for new websites. > > I managed to put, for now, a simple placeholder website for Apache KIE > (incubation). > > Thank you tison and the Apache Fury community! > > On Fri, Jan 26, 2024 at 4:10 AM Xuanwo wrote: > > > > > I managed to move our old website to Docusaurus in one day - using the > > > template > > > structure from Fury, if you don’t mind. > > > > Congrats! > > > > On Fri, Jan 26, 2024, at 17:07, Alexander Alten-Lorenz wrote: > > > Hey tison, > > > > > > Thank you for the head-up. I managed to move our old website to > > > Docusaurus in one day - using the template structure from Fury, if you > > > don’t mind. Awesome stuff, would love when we’d had a template for the > > > podlings to setup a good looking, SEO friendly project page. That’s > > > needed to grow the community! > > > > > > Cheers, thanks again, > > > —Alex > > > > > >> On Jan 25, 2024, at 12:01, tison wrote: > > >> > > >> Hi Alexander, > > >> > > >> I use Docusaurus for Kvrocks and Fury. Their configuration should be > > >> straightforward to follow already. The most simple one now is > > >> https://github.com/apache/incubator-fury-site. > > >> > > >> Also, Docu is well-documented https://docusaurus.io/docs. > > >> > > >> I'm thinking of updating the website template [1] with Docu but have > > >> not yet had time and understand which PMC manages this project. > > >> > > >> Best, > > >> tison. > > >> > > >> [1] https://github.com/apache/apache-website-template > > >> > > >> Alexander Alten-Lorenz 于2024年1月25日周四 18:20写道： > > >>> > > >>> Hi Xuanwo, > > >>> > > >>> Thank you, highly appreciated! Do you have any how-to for setting > > >>> Docusaurus up? > > >>> > > >>> —Alex > > >>> > > >>>> On Jan 25, 2024, at 11:01, Xuanwo wrote: > > >>>> > > >>>> Hi, alexander > > >>>> > > >>>>> We aren't web designers and we would love to find helping hands to get > > >>>>> the page in order, including re-organizing and rewriting. > > >>>> > > >>>> I'm with the OpenDAL Community, and we also lack web designers. Our > > >>>> community > > >>>> opted for Docusaurus[1], which we found easy to start with and set up. > > >>>> It > > >>>> offers a decent theme suitable for open-source projects. For > > >>>> reference, you > > >>>> can check out OpenDAL's homepage[2]. We hope our experience proves > > >>>> useful. > > >>>> > > >>>> [1] https://docusaurus.io/ > > >>>> [2] https://opendal.apache.org/ > > >>>> > > >>>> On Thu, Jan 25, 2024, at 16:26, Alexander Alten wrote: > > >>>>> Hi incubator community, > > >>>>> > > >>>>> Would anyone be willing to help the Wayang project with our website? > > >>>>> We aren't web designers and we would love to find helping hands to get > > >>>>> the page in order, including re-organizing and rewriting. > > >>>>> > > >>>>> thank you, cheers, > > >>>>> --alexander > > >>>> > > >>>> -- > > >>>> Xuanwo > > -- > > Xuanwo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache HoraeDB-Proto(incubating) v2.0.0-RC1 - Incubator Vote Round 1
Hi, This voting thread should be able to close now. Best, tison. Xuanwo 于2024年1月30日周二 18:50写道： > > Oh, I have read the message in wrong that mixed li gang and Ruixiang Tan. > > The vote is correct. > > Sorry for the mistake. > > On Tue, Jan 30, 2024, at 18:48, Xuanwo wrote: > > Hi, Ruixiang Tan > > > > Thank you for participating in the verification and voting process! > > However, the > > declaration of binding is incorrect as only the votes of IPMC members > > will be considered > > binding. > > > > On Tue, Jan 30, 2024, at 17:43, li gang wrote: > >> +1 (binding) > >> I checked > >> - Download links are valid. > >> - Files have the word incubating in their name. > >> - DISCLAIMER,LICENSE and NOTICE files exist. > >> - Checksums and signatures are valid. > >> - No unexpected Binary Files. > >> > >> 谭睿翔(Ruixiang Tan) 于2024年1月29日周一 16:02写道： > >> > >>> Hello, Incubator Community, > >>> > >>> This is a call for a vote to release Apache HoraeDB-Proto(incubating) > >>> version v2.0.0-RC1 > >>> > >>> HoraeDB PPMC Vote Thread > >>> https://lists.apache.org/thread/8vcshqr96nl2mjgw0sppn2grnyvz639n > >>> > >>> HoraeDB PPMC Vote Result > >>> https://lists.apache.org/thread/zrowgg1gvpcsx62rkps66sqblowtm50k > >>> > >>> The release candidate: > >>> > >>> https://dist.apache.org/repos/dist/dev/incubator/horaedb/horaedb-proto/v2.0.0-RC1/ > >>> > >>> This release has been signed with a PGP available here: > >>> https://downloads.apache.org/incubator/horaedb/KEYS > >>> > >>> Git tag for the release: > >>> > >>> https://github.com/apache/incubator-horaedb-proto/releases/tag/release-v2.0.0-rc.1 > >>> > >>> Maven staging repo: > >>> https://repository.apache.org/content/repositories/orgapachehoraedb-1054/ > >>> > >>> Please download, verify, and test. > >>> > >>> The VOTE will pass after got 3 binding approve. > >>> > >>> [ ] +1 approve > >>> [ ] +0 no opinion > >>> [ ] -1 disapprove with the reason > >>> > >>> To learn more about Apache HoraeDB, please see https://horaedb.apache.org/ > >>> > >>> Checklist for reference: > >>> > >>> [ ] Download links are valid. > >>> [ ] Checksums and signatures. > >>> [ ] LICENSE/NOTICE files exist > >>> [ ] No unexpected binary files > >>> [ ] All source files have ASF headers > >>> [ ] Can compile from source > >>> > >>> Thanks > >>> > >> > >> > >> -- > >> > >> > >> -- > >> Best Regards > >> Gang Li 李岗 > >> > >> lgcar...@apache.org > > > > -- > > Xuanwo > > -- > Xuanwo > > - > 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 HoraeDB-Proto(incubating) v2.0.0-RC1 - Incubator Vote Round 1
Thanks for your verification! One comment as many verifier compile via `cargo`: This pacakge provides proto generated for Rust, Java and Golang, running `make` can test all the targets. Of course you can test only the Rust part, just FYI. Best, tison. Xuanwo 于2024年1月30日周二 13:16写道： > > +1 non-binding > > [x] Download links are valid. > [x] Checksums and signatures. > > gpg: Signature made Thu 25 Jan 2024 11:10:58 AM CST > gpg:using RSA key 2CBF6E50D296A228B920F6E8CCEBDB0C26E030F5 > gpg: checking the trustdb > gpg: marginals needed: 3 completes needed: 1 trust model: pgp > gpg: depth: 0 valid: 19 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 19u > gpg: next trustdb check due at 2024-05-25 > gpg: Good signature from "tanruixiang " [ultimate] > > [x] LICENSE/NOTICE files exist > [x] No unexpected binary files > [x] All source files have ASF headers > [x] Can compile from source > > cargo build passed on archlinux x86_64 > > Finished dev [unoptimized + debuginfo] target(s) in 15.08s > cargo build 48.83s user 5.94s system 362% cpu 15.115 total > > On Mon, Jan 29, 2024, at 16:01, 谭睿翔(Ruixiang Tan) wrote: > > Hello, Incubator Community, > > > > This is a call for a vote to release Apache HoraeDB-Proto(incubating) > > version v2.0.0-RC1 > > > > HoraeDB PPMC Vote Thread > > https://lists.apache.org/thread/8vcshqr96nl2mjgw0sppn2grnyvz639n > > > > HoraeDB PPMC Vote Result > > https://lists.apache.org/thread/zrowgg1gvpcsx62rkps66sqblowtm50k > > > > The release candidate: > > https://dist.apache.org/repos/dist/dev/incubator/horaedb/horaedb-proto/v2.0.0-RC1/ > > > > This release has been signed with a PGP available here: > > https://downloads.apache.org/incubator/horaedb/KEYS > > > > Git tag for the release: > > https://github.com/apache/incubator-horaedb-proto/releases/tag/release-v2.0.0-rc.1 > > > > Maven staging repo: > > https://repository.apache.org/content/repositories/orgapachehoraedb-1054/ > > > > Please download, verify, and test. > > > > The VOTE will pass after got 3 binding approve. > > > > [ ] +1 approve > > [ ] +0 no opinion > > [ ] -1 disapprove with the reason > > > > To learn more about Apache HoraeDB, please see https://horaedb.apache.org/ > > > > Checklist for reference: > > > > [ ] Download links are valid. > > [ ] Checksums and signatures. > > [ ] LICENSE/NOTICE files exist > > [ ] No unexpected binary files > > [ ] All source files have ASF headers > > [ ] Can compile from source > > > > Thanks > > -- > Xuanwo > > - > 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: podling reports for January 2024
It seems yet to be updated. I'm glad to update it but I don't know the way to generate the projects that should report in this month. Best, tison. Justin Mclean 于2024年1月28日周日 21:23写道： > > Hi, > > I’ll sort this out in the next 24 hours. > > Kind Regards, > Justin > - > 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 HoraeDB-Proto(incubating) v2.0.0-RC1 - Incubator Vote Round 1
Carry my +1 binding from the dev list. Best, tison. Kumfo Yang 于2024年1月29日周一 16:31写道： > > +1 approve > > 谭睿翔(Ruixiang Tan) 于2024年1月29日周一 16:02写道： > > > Hello, Incubator Community, > > > > This is a call for a vote to release Apache HoraeDB-Proto(incubating) > > version v2.0.0-RC1 > > > > HoraeDB PPMC Vote Thread > > https://lists.apache.org/thread/8vcshqr96nl2mjgw0sppn2grnyvz639n > > > > HoraeDB PPMC Vote Result > > https://lists.apache.org/thread/zrowgg1gvpcsx62rkps66sqblowtm50k > > > > The release candidate: > > > > https://dist.apache.org/repos/dist/dev/incubator/horaedb/horaedb-proto/v2.0.0-RC1/ > > > > This release has been signed with a PGP available here: > > https://downloads.apache.org/incubator/horaedb/KEYS > > > > Git tag for the release: > > > > https://github.com/apache/incubator-horaedb-proto/releases/tag/release-v2.0.0-rc.1 > > > > Maven staging repo: > > https://repository.apache.org/content/repositories/orgapachehoraedb-1054/ > > > > Please download, verify, and test. > > > > The VOTE will pass after got 3 binding approve. > > > > [ ] +1 approve > > [ ] +0 no opinion > > [ ] -1 disapprove with the reason > > > > To learn more about Apache HoraeDB, please see https://horaedb.apache.org/ > > > > Checklist for reference: > > > > [ ] Download links are valid. > > [ ] Checksums and signatures. > > [ ] LICENSE/NOTICE files exist > > [ ] No unexpected binary files > > [ ] All source files have ASF headers > > [ ] Can compile from source > > > > Thanks > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: podling reports for January 2024
I found the report page - https://cwiki.apache.org/confluence/display/INCUBATOR/January2024 But it seems yet to have a proper format or include projects that need to give a report. Do you know how we can generate the project list like other months? Also it's close to the end of January so I'm afraid that most podlings may miss this month's report :( Best, tison. Jason Porter 于2024年1月10日周三 00:42写道： > > Thanks, PJ. I was just looking at this myself. > > On 2024/01/09 13:16:03 PJ Fanning wrote: > > Hi, > > > > There doesn't appear to be a setup to provide podling reports for January > > 2024. > > > > I'm going to be away for a few days so I have put together a report > > for Apache Pekko. > > > > https://cwiki.apache.org/confluence/display/PEKKO/Pekko+Podling+Report+-+January+2024 > > > > Feel free to modify this or to replace it with a completely different > > report. > > > > Regards, > > PJ > > > > - > > 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: Help to get the Wayang project website in shape
Hi Alexander, I use Docusaurus for Kvrocks and Fury. Their configuration should be straightforward to follow already. The most simple one now is https://github.com/apache/incubator-fury-site. Also, Docu is well-documented https://docusaurus.io/docs. I'm thinking of updating the website template [1] with Docu but have not yet had time and understand which PMC manages this project. Best, tison. [1] https://github.com/apache/apache-website-template Alexander Alten-Lorenz 于2024年1月25日周四 18:20写道： > > Hi Xuanwo, > > Thank you, highly appreciated! Do you have any how-to for setting Docusaurus > up? > > —Alex > > > On Jan 25, 2024, at 11:01, Xuanwo wrote: > > > > Hi, alexander > > > >> We aren't web designers and we would love to find helping hands to get > >> the page in order, including re-organizing and rewriting. > > > > I'm with the OpenDAL Community, and we also lack web designers. Our > > community > > opted for Docusaurus[1], which we found easy to start with and set up. It > > offers a decent theme suitable for open-source projects. For reference, you > > can check out OpenDAL's homepage[2]. We hope our experience proves useful. > > > > [1] https://docusaurus.io/ > > [2] https://opendal.apache.org/ > > > > On Thu, Jan 25, 2024, at 16:26, Alexander Alten wrote: > >> Hi incubator community, > >> > >> Would anyone be willing to help the Wayang project with our website? > >> We aren't web designers and we would love to find helping hands to get > >> the page in order, including re-organizing and rewriting. > >> > >> thank you, cheers, > >> --alexander > >> > >> - > >> 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 > > > > > - > 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 Pekko(incubating) Connectors 1.0.2-RC1 Inbox
+1 binding + Download link valid + Checksum and signature match + LICENSE, NOTICE and DISCLAIMER exist + Can build from source with: sbt compile Find some binary files for testing in the release. While I don't think it's a release blocker, you may try to generate it on the fly: ./s3/src/test/resources/keystore.jks ./google-cloud-pub-sub-grpc/src/main/resources/GSR2.crt ./file/src/test/resources/nested-sample.tar Also, I find the license header is something the ASF "standard" one, but otherwise: > Licensed to the Apache Software Foundation (ASF) under one or more > license agreements; and to You under the Apache License, version 2.0: > > https://www.apache.org/licenses/LICENSE-2.0 > > This file is part of the Apache Pekko project, which was derived from Akka. Is there any reason for different styles? How do you check that the license headers are properly included? Best, tison. PJ Fanning 于2024年1月25日周四 17:05写道： > > Hi everyone, > > We still need 1 more binding vote on this vote before we can proceed with a > release. > > Would anyone have time to review this RC? It includes a few bug fixes that > would be good to get released. > > Thanks, > PJ > > On 2024/01/21 12:01:08 PJ Fanning wrote: > > Thanks Xuanwo. I have created PRs to update our NOTICE files. > > > > On 2024/01/21 08:53:47 Xuanwo wrote: > > > +1 non-binding > > > > > > [x] Download links are valid. > > > [x] Checksums and signatures. > > > > > > apache-pekko-connectors-1.0.2-incubating-src-20240109.tgz > > > gpg: Signature made Tue 09 Jan 2024 08:45:04 PM CST > > > gpg:using RSA key 6BA4DA8B1C88A49428A29C3D0C69C1EF41181E13 > > > gpg: checking the trustdb > > > gpg: marginals needed: 3 completes needed: 1 trust model: pgp > > > gpg: depth: 0 valid: 16 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 16u > > > gpg: next trustdb check due at 2024-05-25 > > > gpg: Good signature from "PJ Fanning (GitHub noreply address) > > > " [ultimate] > > > gpg: aka "PJ Fanning " [ultimate] > > > gpg: aka "PJ Fanning (http://www.apache.org/) > > > " [ultimate] > > > > > > [x] LICENSE/NOTICE/DISCLAIMER files exist > > > > > > nit: The NOTICE file seems not mention that Pekko is an incubating > > > project. > > > > > > [x] No unexpected binary files > > > [x] Source files have ASF headers > > > [x] Can compile from source > > > > > > [success] Total time: 239 s (03:59), completed Jan 21, 2024, 4:53:04 PM > > > sbt compile 459.14s user 14.09s system 154% cpu 5:05.48 total > > > > > > Build success on archlinux x86_64 > > > > > > BTW, sbt is much faster than mvn! > > > > > > On Sat, Jan 13, 2024, at 03:20, PJ Fanning wrote: > > > > Hello Incubator Community, > > > > > > > > This is a call for a vote to release Apache Pekko(incubating) > > > > Connectors version 1.0.2-RC1. > > > > > > > > The discussion thread: > > > > https://lists.apache.org/thread/31tvbff0j880v3kvpmdq3st32dkynvnb > > > > > > > > Pekko PPMC Vote Thread > > > > https://lists.apache.org/thread/nosrvwphtwmcg7dw9pz6y1qbtm3zhgpn > > > > > > > > Pekko PPMC Vote Result > > > > https://lists.apache.org/thread/n27jqcy4160981lhdr01ljqs0c31nshh > > > > > > > > The release candidate: > > > > > > > > https://dist.apache.org/repos/dist/dev/incubator/pekko/CONNECTORS-1.0.2-RC1/ > > > > > > > > This release has been signed with a PGP key, available here: > > > > > > > > https://dist.apache.org/repos/dist/release/incubator/pekko/KEYS > > > > > > > > Release Notes: > > > > > > > > https://github.com/apache/incubator-pekko-connectors/pull/310/files > > > > > > > > Git branch for the release: > > > > > > > > https://github.com/apache/incubator-pekko-connectors/tree/v1.0.2-RC1 > > > > Git commit ID: 8b4d6f7db0d1c8e1482f8fcd913022ef7fe357ab > > > > > > > > Please download, verify, and test. > > > > > > > > We have also staged jars in the Apache Nexus Repository. These were > > > > built with the same code > > > > as appears in this Source Release Candidate. We would appreciate if > > > > users could test with these too. > > > > If anyone finds any serious problems with these jars, please
Re: [DISCUSS] Maven staging repository mandatory in VOTE
But yes. Over the years we declared "We release sources ...". So it may be still under-determined. However, improving the release/incubator docs at the ASF level to include a guideline for both what (nice) to do and how to do it should help. The real world relies heavily on binary distributions and most are "endorsed" by the (P)PMC. Best, tison. tison 于2024年1月24日周三 18:27写道： > > > if the presence of a staging repo should be mandatory in the VOTE thread. > > From a technical view, since the RM anyway stages and releases Maven > artifacts, it's not difficult to include a link in the vote thread. > > Best, > tison. > > tison 于2024年1月24日周三 18:25写道： > > > > > if a maven release (or more general a release of convenience binaries) > > > requires a PMC vote or not? > > > > If it's an Apache release (endorsed by the ASF, a.k.a. the (P)PMC), it > > requires. > > > > You may search "Maven" on this page [1] to see how OpenDAL stages and > > releases Maven artifacts. You can also check Curator's release process > > [2] which I'd regard as a good example of pure java libs in the ASF. > > > > Best, > > tison. > > > > [1] https://opendal.apache.org/community/committers/release > > [2] https://curator.apache.org/community/releasing-curator > > > > Stamatis Zampetakis 于2024年1月24日周三 18:16写道： > > > > > > Hey everyone, > > > > > > There are many ASF projects publishing artifacts to Maven repositories > > > and there are certain rules and guidelines [1, 2] in place for those > > > distributions. I assume that the PMC should ensure that the artifacts > > > there conform to the rules before releasing them officially thus I was > > > wondering if the presence of a staging repo should be mandatory in the > > > VOTE thread. > > > > > > Maybe a different way to ask the question is if a maven release (or > > > more general a release of convenience binaries) requires a PMC vote or > > > not? > > > > > > Best, > > > Stamatis > > > > > > [1] https://incubator.apache.org/guides/distribution.html > > > [2] https://infra.apache.org/publishing-maven-artifacts.html > > > > > > - > > > 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: [DISCUSS] Maven staging repository mandatory in VOTE
> if the presence of a staging repo should be mandatory in the VOTE thread. >From a technical view, since the RM anyway stages and releases Maven artifacts, it's not difficult to include a link in the vote thread. Best, tison. tison 于2024年1月24日周三 18:25写道： > > > if a maven release (or more general a release of convenience binaries) > > requires a PMC vote or not? > > If it's an Apache release (endorsed by the ASF, a.k.a. the (P)PMC), it > requires. > > You may search "Maven" on this page [1] to see how OpenDAL stages and > releases Maven artifacts. You can also check Curator's release process > [2] which I'd regard as a good example of pure java libs in the ASF. > > Best, > tison. > > [1] https://opendal.apache.org/community/committers/release > [2] https://curator.apache.org/community/releasing-curator > > Stamatis Zampetakis 于2024年1月24日周三 18:16写道： > > > > Hey everyone, > > > > There are many ASF projects publishing artifacts to Maven repositories > > and there are certain rules and guidelines [1, 2] in place for those > > distributions. I assume that the PMC should ensure that the artifacts > > there conform to the rules before releasing them officially thus I was > > wondering if the presence of a staging repo should be mandatory in the > > VOTE thread. > > > > Maybe a different way to ask the question is if a maven release (or > > more general a release of convenience binaries) requires a PMC vote or > > not? > > > > Best, > > Stamatis > > > > [1] https://incubator.apache.org/guides/distribution.html > > [2] https://infra.apache.org/publishing-maven-artifacts.html > > > > - > > 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: [DISCUSS] Maven staging repository mandatory in VOTE
> if a maven release (or more general a release of convenience binaries) > requires a PMC vote or not? If it's an Apache release (endorsed by the ASF, a.k.a. the (P)PMC), it requires. You may search "Maven" on this page [1] to see how OpenDAL stages and releases Maven artifacts. You can also check Curator's release process [2] which I'd regard as a good example of pure java libs in the ASF. Best, tison. [1] https://opendal.apache.org/community/committers/release [2] https://curator.apache.org/community/releasing-curator Stamatis Zampetakis 于2024年1月24日周三 18:16写道： > > Hey everyone, > > There are many ASF projects publishing artifacts to Maven repositories > and there are certain rules and guidelines [1, 2] in place for those > distributions. I assume that the PMC should ensure that the artifacts > there conform to the rules before releasing them officially thus I was > wondering if the presence of a staging repo should be mandatory in the > VOTE thread. > > Maybe a different way to ask the question is if a maven release (or > more general a release of convenience binaries) requires a PMC vote or > not? > > Best, > Stamatis > > [1] https://incubator.apache.org/guides/distribution.html > [2] https://infra.apache.org/publishing-maven-artifacts.html > > - > 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: [RESULT] [VOTE] Release Apache Pekko(incubating) gRPC 1.0.2-RC1
FYI - I prepared a patch "Mention that there is no implicit +1 in votes" [1] to include this information. Feel free to give it a review and improve the expression. Best, tison. [1] https://github.com/apache/www-site/pull/338 Ayush Saxena 于2024年1月9日周二 20:56写道： > > > I may prepare a patch on > https://www.apache.org/foundation/voting.html to mention this > explicitly. > > Still doing this would be helpful & maybe an explicit line in the > package release section as well [1], that a RM "can" vote as well, I > have seen couple of folks with this confusion that since you can't > approve your own code, so as a RM you can not vote for the release, > since you prepared the artifacts. > > -Ayush > > [1] https://www.apache.org/foundation/voting.html#ReleaseVotes > > On Mon, 8 Jan 2024 at 15:55, tison wrote: > > > > Aha. I saw "Here is my +1 (binding)." at the bottom of the first mail now > > >_< > > > > Best, > > tison. > > > > PJ Fanning 于2024年1月8日周一 18:15写道： > > > > > > Thanks Tison for checking. I did vote on the initial email. > > > > > > https://lists.apache.org/thread/og2mtjv4nsgrh1mc96cfxbqzz8poysp8 > > > > > > On Mon, 8 Jan 2024 at 11:10, tison wrote: > > > > > > > > Hi PJ, > > > > > > > > Congrats. > > > > > > > > I was told that the RM who drives the release doesn't implicitly vote > > > > a +1. So you'd better cast your own +1 the next time when running a > > > > release. > > > > > > > > But I don't find a policy sentence to mention it. While I think the > > > > argument is valid, I may prepare a patch on > > > > https://www.apache.org/foundation/voting.html to mention this > > > > explicitly. > > > > > > > > Best, > > > > tison. > > > > > > > > PJ Fanning 于2024年1月8日周一 17:48写道： > > > > > > > > > > The vote passes with 3 +1s and no negative votes. All votes were > > > > > binding. > > > > > > > > > > Vote Thread > > > > > https://lists.apache.org/thread/og2mtjv4nsgrh1mc96cfxbqzz8poysp8 > > > > > > > > > > Votes > > > > > Zili Chen (tison) > > > > > Matthew de Detrich > > > > > PJ Fanning > > > > > > > > > > I will proceed with the release and make the announcements. > > > > > > > > > > Thanks to everyone who participated in the development and review of > > > > > this release. > > > > > > > > > > - > > > > > 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 > > > > > > > - > > 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: [RESULT][VOTE] Graduate Apache OpenDAL (incubating) as a TLP
Here is the thread on dev@opendal.a.o [1]. > only Xuanwo and I fix We're in the final PMC anyway and I'm on vacation to spend my time and energy handling issues I spotted. So this topic is discussed and spread within dev@opendal.a.o. It's no longer about whether it's "pointed out" or "proactively managed", but I try to deliver the understanding among the PMC and the community, as well as demonstrate how we can improve it and what the common misunderstanding is. I believe this is how to equip the PMC to handle branding issues. Best, tison. [1] https://lists.apache.org/thread/3qq763vr0k7pg3qmvp2dbvg2pomfnh2j tison 于2024年1月15日周一 21:19写道： > > > the PMC is clear that they're responsible to fix them > > ... and they do fix them. All the fixes above are produced by PMC members. > > > this can be an evidence that the PMC understands their responsibility > > Somewhat I send the email so it's not totally active. But I believe > that the PMC members are willing to manage the project and I just put > the button. > > Best, > tison. > > tison 于2024年1月15日周一 21:12写道： > > > > > Datastax has had recent issues regarding trademarks; please follow the > > > policy, not what other 3rd party companies do. > > > > Of course we should follow the policy primarily. The reference is > > demonstrate what "adding trademark attributions" mean. > > > > > However, they don’t seem to understand that they are responsible for > > > managing their brand and protecting the ASF trademarks > > > > I get your points now. > > > > The PMC prioritizes the issues you spotted and fixed them firstly. > > They may ask questions and seek helps for trademarks to get a best > > practices to comply with the policy. While you may regard it as > > "outsource", the PMC is clear that they're responsible to fix them but > > cross check the understanding. > > > > I can understand now that it can give an imagine only Xuanwo and I fix > > the issues and beyond what you point out, most of the branding > > improvement is started by my comments [1][2][3][4][5]. I may be too > > proactive here to hide others understanding. > > > > The trademark guide [6] clearly declares where we should use the full > > form of the project name. And for other content the PMC generates, > > there can be other potential issues to fix. > > > > I'll send an email in dev@opendal.a.o for conveying this information > > and let other members to review the content they produced or saw. Hope > > this can be an evidence that the PMC understands their responsibility. > > Of course, this is not a one-time action but should be continued as > > the PMC exists :D > > > > Best, > > tison. > > > > [1] https://lists.apache.org/thread/vg5mor8m4twy3578rzdqop0y9t961x6y > > [2] https://issues.apache.org/jira/browse/INFRA-25325 > > [3] https://github.com/apache/incubator-opendal/pull/3984 > > [4] https://github.com/apache/incubator-opendal/pull/3983 > > [5] https://github.com/apache/incubator-opendal/pull/3978 > > [6] https://www.apache.org/foundation/marks/guide > > > > Justin Mclean 于2024年1月15日周一 20:45写道： > > > > > > > > Hi, > > > > > > > Also, for trademark attribution, I understand the databend.rs, if it > > > > refers to OpenDAL, it should contain a Footer like Datastax does[2]. > > > > > > Datastax has had recent issues regarding trademarks; please follow the > > > policy, not what other 3rd party companies do. > > > > > > I can see the project, from what you have provided, has fixed a number of > > > issues pointed out to them. However, they don’t seem to understand that > > > they are responsible for managing their brand and protecting the ASF > > > trademarks. > > > > > > Kind Regards, > > > Justin > > > > > > > > > - > > > 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: [RESULT][VOTE] Graduate Apache OpenDAL (incubating) as a TLP
> the PMC is clear that they're responsible to fix them ... and they do fix them. All the fixes above are produced by PMC members. > this can be an evidence that the PMC understands their responsibility Somewhat I send the email so it's not totally active. But I believe that the PMC members are willing to manage the project and I just put the button. Best, tison. tison 于2024年1月15日周一 21:12写道： > > > Datastax has had recent issues regarding trademarks; please follow the > > policy, not what other 3rd party companies do. > > Of course we should follow the policy primarily. The reference is > demonstrate what "adding trademark attributions" mean. > > > However, they don’t seem to understand that they are responsible for > > managing their brand and protecting the ASF trademarks > > I get your points now. > > The PMC prioritizes the issues you spotted and fixed them firstly. > They may ask questions and seek helps for trademarks to get a best > practices to comply with the policy. While you may regard it as > "outsource", the PMC is clear that they're responsible to fix them but > cross check the understanding. > > I can understand now that it can give an imagine only Xuanwo and I fix > the issues and beyond what you point out, most of the branding > improvement is started by my comments [1][2][3][4][5]. I may be too > proactive here to hide others understanding. > > The trademark guide [6] clearly declares where we should use the full > form of the project name. And for other content the PMC generates, > there can be other potential issues to fix. > > I'll send an email in dev@opendal.a.o for conveying this information > and let other members to review the content they produced or saw. Hope > this can be an evidence that the PMC understands their responsibility. > Of course, this is not a one-time action but should be continued as > the PMC exists :D > > Best, > tison. > > [1] https://lists.apache.org/thread/vg5mor8m4twy3578rzdqop0y9t961x6y > [2] https://issues.apache.org/jira/browse/INFRA-25325 > [3] https://github.com/apache/incubator-opendal/pull/3984 > [4] https://github.com/apache/incubator-opendal/pull/3983 > [5] https://github.com/apache/incubator-opendal/pull/3978 > [6] https://www.apache.org/foundation/marks/guide > > Justin Mclean 于2024年1月15日周一 20:45写道： > > > > > Hi, > > > > > Also, for trademark attribution, I understand the databend.rs, if it > > > refers to OpenDAL, it should contain a Footer like Datastax does[2]. > > > > Datastax has had recent issues regarding trademarks; please follow the > > policy, not what other 3rd party companies do. > > > > I can see the project, from what you have provided, has fixed a number of > > issues pointed out to them. However, they don’t seem to understand that > > they are responsible for managing their brand and protecting the ASF > > trademarks. > > > > Kind Regards, > > Justin > > > > > > - > > 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: [RESULT][VOTE] Graduate Apache OpenDAL (incubating) as a TLP
> Datastax has had recent issues regarding trademarks; please follow the > policy, not what other 3rd party companies do. Of course we should follow the policy primarily. The reference is demonstrate what "adding trademark attributions" mean. > However, they don’t seem to understand that they are responsible for managing > their brand and protecting the ASF trademarks I get your points now. The PMC prioritizes the issues you spotted and fixed them firstly. They may ask questions and seek helps for trademarks to get a best practices to comply with the policy. While you may regard it as "outsource", the PMC is clear that they're responsible to fix them but cross check the understanding. I can understand now that it can give an imagine only Xuanwo and I fix the issues and beyond what you point out, most of the branding improvement is started by my comments [1][2][3][4][5]. I may be too proactive here to hide others understanding. The trademark guide [6] clearly declares where we should use the full form of the project name. And for other content the PMC generates, there can be other potential issues to fix. I'll send an email in dev@opendal.a.o for conveying this information and let other members to review the content they produced or saw. Hope this can be an evidence that the PMC understands their responsibility. Of course, this is not a one-time action but should be continued as the PMC exists :D Best, tison. [1] https://lists.apache.org/thread/vg5mor8m4twy3578rzdqop0y9t961x6y [2] https://issues.apache.org/jira/browse/INFRA-25325 [3] https://github.com/apache/incubator-opendal/pull/3984 [4] https://github.com/apache/incubator-opendal/pull/3983 [5] https://github.com/apache/incubator-opendal/pull/3978 [6] https://www.apache.org/foundation/marks/guide Justin Mclean 于2024年1月15日周一 20:45写道： > > Hi, > > > Also, for trademark attribution, I understand the databend.rs, if it > > refers to OpenDAL, it should contain a Footer like Datastax does[2]. > > Datastax has had recent issues regarding trademarks; please follow the > policy, not what other 3rd party companies do. > > I can see the project, from what you have provided, has fixed a number of > issues pointed out to them. However, they don’t seem to understand that they > are responsible for managing their brand and protecting the ASF trademarks. > > Kind Regards, > Justin > > > - > 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: [RESULT][VOTE] Graduate Apache OpenDAL (incubating) as a TLP
> independently Hello Justin, After reading the trademark guide[1], I agree that the (P)PMC can review the occurrence again since it clearly wrote: > The first and most prominent mentions must use the full form: "Apache > Hadoop®" of the name for any individual usage and it gives a certain list about what occurrences are counted. So we should use "Apache OpenDAL™" in every such occurrence: > * Titles or subtitles, including web page title or description metadata. > * The first and most prominent header elements within any major document > section. > * The first and most prominent callout, sidebar, or other types of > highlighted blocks of content displayed to the user. > * The first and most prominent uses in running or body text within the > document. > * For graphics headers or diagrams, the full form of the name must be clear > in the graphic itself where practical; if not, the full form of the name must > be used in a prominent caption header, or accompanying explanation of the > graphic. > * For video content, in the title and first uses, as well as the last use or > any use in credits, must be the full form of the name. All of the distribution pages and API docs should already follow this policy, but several website pages can be still improved. Also, for trademark attribution, I understand the databend.rs, if it refers to OpenDAL, it should contain a Footer like Datastax does[2]. However, the (P)PMC is continuously proactively resolving this issue already, instead of negatively responding. Before the graduation discussion, when I noticed GreptimeDB doesn't use OpenDAL is the Apache form, I submitted a PR[3]. Of course, it's still not follow strictly Apache Foo™ so I'll submit a new PR to improve it. Moreover, when you firstly spot the issues about using "Apache Foo" in the name in some certain pages, beyond the pages you referref to, the OpenDAL PPMC checks all the bindings pages and updates them accordingly to this policy. Moreover, when we notice that using a logo containing Apache and the trademark symbol can help convey the Apache brand, we start a discussion to improve it [4]. Moreover, when we are aware that trademarks@ holds an NPM account that can help convey the Apache brand, we file a ticket to integrate the release process with it [5]. Moreover, we don't negatively barely "fixing" the issue, but think of the policy and what is the best way we follow it effectively. So instead of dropping the Python API docs to cancel the branding wart, we developed a common solution that can be used in all the ASF Python projects [6]. Moreover, we're actively checking other pages you didn't refer to [7][8], while I noticed that it should use the TM symbol to follow the policy strictly now. Your feedback is as common as a general issue report so we want to ask for the details page and paragraph referred, just like when trademarks@ asks PMCs to fix issues it will identify the pages and concrete issues. Besides, I noticed that @TheASF which should be controlled by marketing or press or trademarks doesn't use trademark symbol [9] when announcing. Of course, this is not a reason that the policy can be workaround but something that the account manager should fix. However, we should understand the challenges we're facing when fixing these issues. The OpenDAL PMC is proactively understanding the policy and fixing issues as much as they can. Remember that we're volunteers, so spotting issues and collaborating to resolve the issue are welcome. Best, tison. [1] https://www.apache.org/foundation/marks/guide [2] https://www.datastax.com/ [3] https://github.com/GreptimeTeam/greptimedb/pull/2653 [4] https://lists.apache.org/thread/vg5mor8m4twy3578rzdqop0y9t961x6y [5] https://issues.apache.org/jira/browse/INFRA-25325 [6] https://github.com/apache/incubator-opendal/pull/3850 [7] https://github.com/apache/incubator-opendal/pull/3978 [8] https://github.com/apache/incubator-opendal/pull/3831 [9] https://twitter.com/TheASF Justin Mclean 于2024年1月15日周一 13:40写道： > > Hi, > > The (P)PMC must be able to do this independently. Just look at each of the > resources you listed and ask yourself: > - Is Apache Foo being used in the most prominent place? > - Are we using the trademark symbol? > - Does the page include trademark attribution for any Apache trademarks used? > > Our full trademark policy covers a lot more than this, but that’s a good > start. > > Kind Regards, > Justin > - > 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: [RESULT][VOTE] Graduate Apache OpenDAL (incubating) as a TLP - Incubator
Please check carefully for the content. There are a few typos: > no +0 and 1 -1 votes. No. There is 1 -1 binding vote. > Thanks to the Incubator, the Kvrocks community This vote has nothing to do with the Kvrocks community. Best, tison. Xuanwo 于2024年1月10日周三 09:45写道： > > Hi all, > > The vote for graduating Apache OpenDAL(incubating)[1] to a TLP has passed. > > There are 10 binding +1 votes, 14 non-binding +1 votes, no +0 and 1 -1 > votes. > > *+10 Binding* > - Sheng Wu > - tison > - Shaofeng Shi > - Ted Liu > - Craig L Russell > - He Xiaoqiao > - PJ Fanning > - 张铎(Duo Zhang) > - Enrico Olivelli > - Willem Jiang > > *+14 Non-binding* > - Suyan > - hulk > - PsiACE > - Forward Xu > - vin jake > - Pragma Twice > - Mingzhuo Yin > - Jun Ouyang > - Liuqing Yue > - Chunshao Ren > - Morris Tai > - Shawn Yang > - Huajie Wang > - Eason Chen > > *-1 Binding* > - Justin Mclean (note: the branding and trademark issues have been resolved > and addressed) > > Thanks all for participating in the vote. Thanks to the Incubator, the > Kvrocks community, our mentors, and everyone who helped trough out the > journey. > > We will proceed and submit the graduation proposal to the ASF board. > > [1] https://lists.apache.org/thread/l2wgvwjnm6okkjxvrxp37zc06tfdrolk > > - > 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
