Re: [IP CLEARANCE] Apache DataFusion sqlparser-rs
+1 (binding) Good luck :D Best, tison. Andy Grove 于2024年9月24日周二 01:33写道: > > Apache DataFusion is receiving a donation of sqlparser-rs [1], a SQL parser > implemented in Rust. > > Please vote to approve this contribution. > > This is a lazy consensus majority vote, per the IP clearance process > [2], open for at least 72 hours. > > Thanks, > > Andy. > > [1] https://incubator.apache.org/ip-clearance/datafusion-sqlparser > [2] https://incubator.apache.org/ip-clearance/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Proposal: Recording votes in podlings
+1 I remember a similar suggestion sent to OpenDAL [1] and later @suyanhanx always include his Apache ID when voting or even every mail [2]. [1] https://lists.apache.org/thread/0hcnjq16xtbxqtxg28yboxthsg32y71b [2] https://lists.apache.org/thread/sfzdfko11x45bh2xk5wwt1xrt2kvt16o I always use "tison" as my ID which is the same as my Apache ID so I hope it makes things clear. Best, tison. Christofer Dutz 于2024年9月7日周六 21:30写道: > > Hehe, > > Pro-tip from a freshly former board member: Many TLPs would consider that > interfering with their freedom to do wtftw ... Been there, done that ;-) > > I did bring this up for some TLPs and that was often not appreciated. > > I'd say establishing this for new projects based on reasoning during > incubation is going to be a lot less conflict loaded. > > Chris > > Gesendet von Outlook für Android<https://aka.ms/AAb9ysg> > > From: PJ Fanning > Sent: Saturday, September 7, 2024 2:20:19 PM > To: general@incubator.apache.org > Subject: Re: Proposal: Recording votes in podlings > > Sounds like a good idea to me and may be useful if other PMCs adopted > it. Many users have Apache user IDs that don't match their personal > names - and some even have personal email addresses with different > names again. > > On Sat, 7 Sept 2024 at 11:51, Kevin Ratnasekera > wrote: > > > > +1 djkevincr (IPMC) > > > > On Sat 7. Sep 2024 at 09:00, Christofer Dutz > > wrote: > > > > > Absolutely > > > +1 cdutz (IPMC) > > > from my side :-) > > > > > > Gesendet von Outlook für Android<https://aka.ms/AAb9ysg> > > > > > > From: Xin Wang > > > Sent: Saturday, September 7, 2024 3:40:39 AM > > > To: general@incubator.apache.org > > > Subject: Re: Proposal: Recording votes in podlings > > > > > > +1 Sounds like a good idea to me. > > > > > > Thanks, > > > Xin > > > > > > > > > Nathan Hartman 于2024年9月7日 周六09:15写道: > > > > > > > On Fri, Sep 6, 2024 at 5:30 PM Craig Russell > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > I'd like to discuss (again) how to register podling votes for new > > > > > committers, PPMC members, and releases. > > > > > > > > > > People often have many names, most of which do not matter for > > > governance > > > > > purposes: > > > > > their actual name > > > > > their email from address > > > > > their nickname > > > > > their github id > > > > > their ASF id > > > > > > > > > > It can be difficult for folks to review votes if the ASF id is not > > > > > included in the vote. So I'm proposing that for votes, that a standard > > > > form > > > > > be used for registering and tallying votes. > > > > > > > > > > For registering votes, include the ASF id in the vote line, e.g. > > > > > > > > > > +1 clr (IPMC) > > > > > > > > > > For tallying votes (in the [RESULT][VOTE] thread): > > > > > > > > > > Vote passes: > > > > > +1 clr (IPMC) > > > > > +1 sammy (PPMC) > > > > > +1 jules > > > > > +1 jmclean (IPMC) > > > > > +1 cdutz (IPMC) > > > > > > > > > > no -1 or +-0 votes > > > > > ... > > > > > > > > > > Using this scheme will make it easier for the person calling the vote > > > to > > > > > quickly know whether the voter is a community member or PPMC member or > > > > IPMC > > > > > member. And it will be easier after a PPMC vote for the IPMC votes to > > > be > > > > > carried over. > > > > > > > > > > WDYT? > > > > > > > > > > Craig L Russell > > > > > c...@apache.org > > > > > > > > > > > > > > > > Sounds like a good idea to me. I'm +1 to that, or, putting it into > > > practice > > > > already: > > > > > > > > +1 hartmannathan (IPMC) > > > > > > > > Cheers > > > > Nathan > > > > > > > > > - > 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 Fury(incubating) v0.6.0-rc1
+1 binding * Download link valid * Checksum and signature matches * LICENSE and NOTICE exist * DISCLAIMER exists * Build Rust lib successfully (cargo build) * Build Java lib successfully (mvn clean install) Best, tison. Ayush Saxena 于2024年7月23日周二 14:07写道: > +1 (Binding) > > * Built java module from source > * Validated Checksums > * Validated Signatures > * Validated incubating in name > * NOTICE & DISCLAIMER file exists > * Validated license header on source files > * Validated diff b/w the git tag & src tar (java/benchmark only in git > tag, looks intentional) > * No unexpected binary files > > Good Luck!!! > > -Ayush > > On Mon, 22 Jul 2024 at 17:33, Xin Wang wrote: > > > > +1 binding > > > > [x] Download links are valid. > > [x] Checksums and signatures. > > [x] LICENSE/NOTICE files exist > > [x] No unexpected binary files > > [x] All source files have ASF headers > > [x] Can compile from source for Java > > > > > > Shawn Yang 于2024年7月21日周日 13:38写道: > > > > > Thanks for pointing this out, let's discuss it in this github issue. > > > > > > On Sat, Jul 20, 2024 at 11:45 PM PJ Fanning > wrote: > > > > > > > > +1 binding > > > > > > > > * download ok > > > > * asc and sha512 files ok > > > > * file names ok > > > > * LICENSE/NOTICE/DISCLAIMER ok > > > > * license headers on source files > > > > * no unexpected binary files > > > > > > > > I raised an issue about the license file in the jars but I don't > think > > > > it is a release blocker. > > > > https://github.com/apache/fury/issues/1745 > > > > > > > > > > > > On Sat, 20 Jul 2024 at 15:19, Shawn Yang > > > wrote: > > > > > > > > > > Hi PJ, > > > > > > > > > > Seems it's a network issue on my computer. I've reuploaded the > jars in > > > > > > https://repository.apache.org/content/repositories/orgapachefury-1043/ > > > > > > > > > > The pom.xml and jars are fine, could you help check it again? > > > > > > > > > > > > > > > On Sat, Jul 20, 2024 at 7:32 PM PJ Fanning > > > wrote: > > > > > > > > > > > The RC looks mainly correct but I see one set of issues so I will > > > > > > temporarily vote -1 binding (which I will withdraw if the issues > are > > > > > > fixed). > > > > > > > > > > > > The main jar and pom are missing in > > > > > > > > > > > > > > > > https://repository.apache.org/content/repositories/orgapachefury-1014/org/apache/fury/fury-core/0.6.0/ > > > > > > > > > > > > I would suggest that the jars are 'staged' in future by > 'closing' the > > > > > > repository. There is a further 'release' stage but this should > only > > > be > > > > > > done after the vote happens. Closing the repository will perform > > > > > > checks on the repository and these would likely have found the > issue > > > > > > with missing jar and pom. > > > > > > > > > > > > > > > > > > On Sat, 20 Jul 2024 at 06:15, Shawn Yang < > shawn.ck.y...@gmail.com> > > > wrote: > > > > > > > > > > > > > > Hello everyone, > > > > > > > > > > > > > > This is a call for the vote to release Apache Fury(Incubating) > > > > > > v0.6.0-rc1. > > > > > > > > > > > > > > The Apache Fury community has voted and approved the release of > > > Apache > > > > > > > Fury(incubating) v0.6.0-rc1. 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/ktz73l7bzyhj7f4dpvqtf4nbq8od57ps > > > > > > > > > > > > > > Vote result thread: > > > > > > >
Re: [VOTE] Retire Apache Liminal podling
+1 binding Best, tison. Jean-Baptiste Onofré 于2024年7月17日周三 22:48写道: > +1 (binding) > > Regards > JB > > On Thu, Jul 11, 2024 at 2:48 PM Jean-Baptiste Onofré > wrote: > > > > Hi folks, > > > > Based on the discussion/vote on the podling dev mailing list > > (https://lists.apache.org/thread/yo1xgqvwsl28ylsgmhjpz3obczhnhbll), I > > would like to call for a vote to retire Apache Liminal podling. > > > > The voting will last for at least one week to ensure that everyone has > > time to express their opinions. > > > > Please vote accordingly: > > > > [ ] +1 Approve > > [ ] +0 No opinion > > [ ] -1 Disapprove with a reason > > > > Thanks, > > Regards > > JB > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: PMC is a committee
Agree. We should bring the discussion there, not barely notifying the result. Best, tison. Justin Mclean 于2024年7月8日周一 17:06写道: > Hi, > > I’m not sure the incubator’s remit is to make changes that affect all > TLPs. The discussion about MPMC vs. PMC should probably be on the member's > list. Making the change and then notifying them may come across the wrong > way. > > Kind Regards, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: PMC is a committee
Now that no objection to using MPMC as an abbreviation, I file this draft [1] so that we can improve the wording and start to spread the word. [1] https://github.com/apache/www-site/pull/388 Interestingly, I noticed that the glossary already has a section: > Avoid referring to a member of a PMC as "a PMC", as it can cause confusion about > whether you are talking about the group or an individual. I'd send this notice to members@ later today to call for attentions; does it sound right? Best, tison. Jon Malkin 于2024年7月8日周一 16:21写道: > I was initially thinking I liked the M suffix more in that it gives info on > the relevant body first, but the MP example swayed me. > > jon > > > On Mon, Jul 8, 2024, 2:45 PM sebb wrote: > > > On Mon, 8 Jul 2024 at 18:21, Craig Russell wrote: > > > > > > So, I agree with Greg (! I know) that there is real potential for > > confusion and we should try to fix it. > > > > > > Now what we need to do is to bikeshed the name. Either MPMC or PMCM > > captures the spirit. None of these conflict with any commonly used > > acronyms. Which of these works best with PPMC and IPMC? > > > > > > I personally prefer MPMC, MIPMC, and MPPMC. Because we want people to > > think of member first when writing the acronym. And anyone familiar with > > governing bodies knows MP for Member of Parliament, MEP for Member of > > European Parliament. > > > > +1 > > > > > Once we decide on the acronym, we need to socialize it by updating all > > of our "how it works" pages to mention and explain it. Then, when people > > misuse PMC, we can include a link to the explanation. > > > > Should also be mentioned in the Glossary [1], which should also have > > PPMC and IPMC added. > > > > However, we should remember that people outside the ASF also read > > mailing lists, so ideally use 'member' wherever possible, at least for > > the first mention. > > Yes, it's a bit more work for the author, but less effort for the > > readers (and there are generally multiple readers versus 1 author). > > > > Sebb > > [1] https://apache.org/foundation/glossary.html > > > Craig > > > > > > > > > > On Jul 8, 2024, at 03:37, Greg Stein wrote: > > > > > > > > On Sun, Jul 7, 2024 at 10:47 PM Joe Witt wrote: > > > > > > > >> Greg > > > >> > > > >> It isnt wrong to correct improper usage particularly when there is a > > > >> specific case that caused actual confusion. > > > >> > > > > > > > > I appreciate the concept of "correct the usage when you see it", and > I > > > > *have* been doing that for several years now. Probably once a month > or > > two, > > > > over and over for years. The improper usage isn't stopping, so I'm > > raising > > > > the concern here. The wider community simply needs to understand the > > > > acronym means a committee, and stop using it for individuals. It is a > > > > simple definitional solution to this longstanding problem that I feel > > has > > > > not improved since my first whack-a-mole message to correct the > > improper > > > > usage. > > > > > > > > Cheers,. > > > > -g > > > > > > 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: PMC is a committee
> I personally prefer MPMC, MIPMC, and MPPMC. Because we want people to think of member first when writing the acronym. And anyone familiar with governing bodies knows MP for Member of Parliament, MEP for Member of European Parliament. Second this. So where shall we form a formal discussion or maybe a vote/lazy consensus? I'm very happy to volunteer for the work, but discussing in general@incubator.a.o can miss other members' attention. Best, tison. Greg Stein 于2024年7月8日周一 10:34写道: > On Mon, Jul 8, 2024 at 12:22 PM Craig Russell > wrote: > >... > > > Once we decide on the acronym, we need to socialize it by updating all of > > our "how it works" pages to mention and explain it. Then, when people > > misuse PMC, we can include a link to the explanation. > > > > ^^ this >
Re: PMC is a committee
> What’s wrong with “PMCM” for an individual? I'd second the proposal to simply encourage PMCM to be the abbr for PMC members and spread it among the community. Or MPMC/MPPMC reads better to me (XD) Best, tison. David Jencks 于2024年7月7日周日 21:47写道: > Well, every time I see “PMC” and it appears from the context that one > person is meant, I’m confused, and I have doubts about whether the author > knows what they mean. I applaud Greg for complaining. > What’s wrong with “PMCM” for an individual? > > David Jencks > Sent from my iPhone > > > On Jul 7, 2024, at 8:47 PM, Joe Witt wrote: > > > > Greg > > > > It isnt wrong to correct improper usage particularly when there is a > > specific case that caused actual confusion. > > > > That should be done by the person that was confused and with the person > > that caused confusion. > > > > Joe > > > > > >> On Sun, Jul 7, 2024 at 10:31 PM Greg Stein wrote: > >> > >> I have witnessed actual confusion, approximately of the form "a PMC > >> approved this request". Digging in, it turned out that it was a single > >> person on a PMC, not the committee approving the request. > >> > >> So, no ... it isn't just being a pedant. And even if it was: why is it > >> wrong to correct the use of terminology? Why is it okay to misuse the > >> acronym "PMC"? > >> > >> I do not believe that this is cultural. The acronym "PMC" is not a word > in > >> *any* language. So we're talking about how people are *taught* what the > >> acronym means. My point is to teach people it means "committee" and it > >> never means "member". That is a simple fact that has zero cultural > >> implications. > >> > >> Cheers, > >> -g > >> > >> > >>> On Wed, Jul 3, 2024 at 10:02 AM larry mccay wrote: > >>> > >>> I'd be interested to know whether there is any real semantic danger > here > >> or > >>> whether it is a flavor of Misophonia. > >>> I've personally never misunderstood someone in the context of their > >>> conversation. > >>> > >>> If there is a real danger like a decision being made for a whole > >> community > >>> based on someone calling themselves a PMC and it is misunderstood to > mean > >>> they are speaking as the entire PMC then perhaps we should rename it > and > >>> make it more explicit. Of course, no one will stop using PMC either > >>> correctly or incorrectly - at least for a very long time. > >>> > >>> I'd also note that if a lot of folks are referring to themselves as an > >>> inappropriate acronym that perhaps there is a missing acronym for what > >> they > >>> mean. > >>> It seems folks are looking for something more precise and important > >>> sounding. > >>> > >>> "Member" may be too generic and overloaded (even within Apache itself) > to > >>> express what they are trying to say. > >>> ICM - Individual Committee Member? > >>> PCM - Project Committee Member? Too close... > >>> > >>> Anyway, my opinion is that we either accept it and move on or add > >> something > >>> else. Trying to shove some semantic minutiae down everyone's throats > >> isn't > >>> likely worth the effort. > >>> > >>> > >>>> On Wed, Jul 3, 2024 at 10:19 AM Dave Fisher wrote: > >>> > >>>> > >>>> > >>>>> On Jul 2, 2024, at 11:52 PM, Christofer Dutz < > >>> christofer.d...@c-ware.de> > >>>> wrote: > >>>>> > >>>>> I mean … I think I have never really been confused if someone used > >>> “PMC” > >>>> or “PMC member” as from the context it was clear. > >>>>> What however I really hate to see in emails is people using short > >> forms > >>>> LMAA, WTF, IANAL, STFU, … this list is long and obviously I listed the > >>> ones > >>>> I knew. > >>>>> Quite often when people use these short forms, I feel a bit excluded > >>> and > >>>> have to search or ask what they mean, so if we freak out about people > >>> using > >>>> the short form PMC, then I would also argue to freak out on using > other > >>&
Re: [VOTE] Release Apache HoraeDB(Incubating) rust client v2.0.0-rc.1
+1 binding * Download link valid. * Signature and checksum matches apache-horaedb-incubating-rust-client-v2.0.0-src.tar.gz gpg: Signature made 二 6/11 20:05:04 2024 PDT gpg:using RSA key 6F734AE4297C7F62B6054F91D3026E5C08A0BAB4 gpg: Good signature from "jiacai2...@apache.org" [unknown] gpg: aka "Jiacai Liu " [unknown] gpg: aka "Jiacai Liu " [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: 6F73 4AE4 297C 7F62 B605 4F91 D302 6E5C 08A0 BAB4 * LICENSE / NOTICE / DISCLAIMER exists * License header properly set. * Build works with: cargo build To @PJ: > maturin build failed on my Macbook You may misread the build instructions of Python client, this is the Rust client. But I suggest the PPMC try add a default target of Makefile to let `make` build the library which is intuitive since you have the Makefile. Best, tison. PJ Fanning 于2024年7月7日周日 16:20写道: > +1 binding > * Downloads ok > * checksums and signatures are valid > * no binaries > * LICENSE/NOTICE/DISCLAIMER ok > * Source headers ok > * maturin build failed on my Macbook > > Caused by: Couldn't detect the binding type; Please specify them with > --bindings/-b > > I'm no Rust expert but the build made some progress and everything > else seems ok. > > On Tue, 2 Jul 2024 at 13:42, hulk wrote: > > > > +1 binding > > > > I checked: > > > > [x] Download links are valid. > > [x] Checksums and PGP signatures are valid. > > [x] [No unexpected binary files bundled in the source archive. > > [x] LICENSE/NOTICE/DISCLAIMER files exist. > > [x] Can compile from source. > > > >Compiling horaedb-client v2.0.0 > > (/Users/hulk/Downloads/apache-horaedb-incubating-rust-client-v2.0.0-src) > > Finished dev [unoptimized + debuginfo] target(s) in 54.31s > > > > On Tue, 2 Jul 2024 at 16:46, Jiacai Liu wrote: > > > > > Hello, > > > > > > This is a call for a vote to release Apache HoraeDB(incubating) > > > rust client version v2.0.0. > > > > > > The tag to be voted on is v2.0.0-rc.1 > > > > > > The vote thread: > > > https://lists.apache.org/thread/yr6plq4176d5xyh1v0h2pjtgt61rkrb6 > > > > > > Vote Result: > > > https://lists.apache.org/thread/nvnpxnbf96b7dj05lwdp9knv2d3wklws > > > > > > The release candidate: > > > > > > > > > > https://dist.apache.org/repos/dist/dev/incubator/horaedb/horaedb-rust-client/v2.0.0-rc.1/ > > > > > > Keys to verify the release candidate: > > > > > > https://downloads.apache.org/incubator/horaedb/KEYS > > > > > > Git tag for the release: > > > > > > https://github.com/apache/horaedb-client-rs/releases/tag/v2.0.0-rc.1 > > > > > > Git commit id for the release: > > > > > > > https://github.com/apache/horaedb-client-rs/commit/c011a7ef4726272fe73026a96583d0271fce6f3d > > > > > > 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 distribution has correct names matching the > > > current release. > > > [ ] LICENSE/NOTICE files exist and are correct. > > > [ ] No unexpected binary files bundled in the source archive. > > > [ ] All source files have ASF headers. > > > [ ] Can compile from source. > > > > > > Tips to verify the release, please refer to: > > > > > > https://github.com/apache/horaedb/wiki/ASF-review-guide > > > > > > How to Build HoraeDB Rust client, please refer to: > > > > > > https://horaedb.apache.org/dev/sdk_develop.html#rust > > > > > > Best, > > > Jiacai Liu > > > > > > - > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > -- > > Best Regards, > > - *Hulk Lin* > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: PMC is a committee
Another case for stating oneself as PMC [1] [1] https://www.linkedin.com/in/dannycranmer/ Although it may be interpreted as "I'm part of the PMC". I refer it here to show how widely it's used "exchangeable" .. Best, tison. Dave Fisher 于2024年7月3日周三 12:39写道: > > > > On Jul 3, 2024, at 10:36 AM, John Gemignani > wrote: > > > > I do believe that you spelled it incorrectly, it is bikeshedding, one > word. > > > > And, shouldn't it be, PMCM or PMCm? That makes more sense. > > That’s what I’m thinking too. Which makes the incubator versions PPMCM or > PPMCm. > > Or, horrible joke follows: if you want to go all Roman numeral / Dewey > decimal system - PP.1900 for PPMC members and PP.100 for PPMC - let’s etch > that in stone :-D and/or put it on the shelf. > > > > > john > > > > On Wed, Jul 3, 2024 at 10:32 AM Craig Russell > wrote: > > > >> As long as we are bike shedding: > >> > >> We have PMC: Project Management Committee > >> PPMC: Podling Project Management Committee > >> MPMC: Member, Project Management Committee > >> > >> Craig > >> > >>> On Jul 2, 2024, at 23:52, Christofer Dutz > >> wrote: > >>> > >>> I mean … I think I have never really been confused if someone used > “PMC” > >> or “PMC member” as from the context it was clear. > >>> What however I really hate to see in emails is people using short forms > >> LMAA, WTF, IANAL, STFU, … this list is long and obviously I listed the > ones > >> I knew. > >>> Quite often when people use these short forms, I feel a bit excluded > and > >> have to search or ask what they mean, so if we freak out about people > using > >> the short form PMC, then I would also argue to freak out on using other > >> short forms ;-) > >>> > >>> Chris > >>> > >>> Von: Yuanbo Liu > >>> Datum: Mittwoch, 3. Juli 2024 um 05:24 > >>> An: general@incubator.apache.org > >>> Betreff: Re: PMC is a committee > >>> Also it's driving me crazy to see native speakers saying "...not...no > >>> more". Teachers tell me it is supposed to be "any more".. > >>> > >>> On Wed, Jul 3, 2024 at 11:03 AM tison wrote: > >>> > >>>> ... and yes. For non-native speakers, it's possible to feel less > >>>> uncomfortable to use "PMC" as an abbr. to PMC members. Just .. as an > >>>> opaque term. > >>>> > >>>> Best, > >>>> tison. > >>>> > >>>> Xuanwo 于2024年7月2日周二 19:56写道: > >>>>> > >>>>> This thread reminds me of tison's proposal that use "Maintainer" > >> instead > >>>> of "PMC Member". > >>>>> > >>>>> https://lists.apache.org/thread/xsjojmksqtnsdjcg0yf4vz0xy82llhmw > >>>>> > >>>>> On Wed, Jul 3, 2024, at 10:04, Jiacai Liu wrote: > >>>>>>> And, we can all be tired, overworked, or lazy and say the wrong > >>>>>>> thing *or* > >>>>>>> get into bad habits. > >>>>>> > >>>>>> Thank John for your kindly understanding. > >>>>>> > >>>>>> Also as a non-native English speaker, when I see abbreviation like > >>>>>> PMC, > >>>>>> my first insight is this word could be used on its own, `PMC > >>>>>> member` looks a little redundancy for me... > >>>>>> > >>>>>> on Wed, Jul 03, 2024 at 08:50:45 AM +0800, John Gemignani wrote: > >>>>>> > >>>>>>> My 2 cents as being a PMC member and once part of incubation,... > >>>>>>> > >>>>>>> To be honest, I've never really paid much attention when someone > >>>>>>> stated > >>>>>>> they're a PMC. I knew what was meant and just auto corrected it > >>>>>>> in my head. > >>>>>>> I have used, without fully thinking about it, PMC as, "I am a > >>>>>>> PMC" as well. > >>>>>>> When I meant, or should have meant, "I am a PMC member", and I'm > >>>>>>> a native > >>>>>>> English speaker. > >>>&g
Re: [VOTE] Release Apache Seata (Incubating) v2.1.0-RC4
> According to the timeline of above links, the _helpers.tpl in hzero-starter-parent is copied from Seata. And the repo does not belong to Seata community or any maintainer of Seata community, the repo is owned by a third-party, we have no control of their behavior. And the copyright of the file should belong to Seata community, not open-hand. So is there any misunderstanding on this issue? I suggest you can add a license header to the file and this clarification is enough. Of course, you're encourage to out reach hzero-start-parent project maintainers (by creating an issue or so) and ask them to add the corresponding license header. Best, tison. Jianbin Chen 于2024年7月7日周日 00:32写道: > Hi,Paul > Thank you for your suggestion, and I agree. We should wait for 72 hours. > Even if the final outcome does not result in a successful release, it will > help us identify more issues so that our next vote can proceed more > smoothly and in compliance with the regulations. > > On 2024/07/07 00:49:56 Paul King wrote: > > Others have commented on the release. Just a quick comment on the > > following wording: "The vote will be open for at least 72 hours or > > until necessary number of votes are reached." > > In general, you cannot close the vote early. Some -1 votes may come in > > after some +1 votes. The idea of the 72 hours is to allow your > > community members (and incubator members) from all timezones and with > > differing schedules to all have a chance to comment on the vote. > > > > I look forward to your release. > > > > Cheers, Paul. > > > > On Sat, Jul 6, 2024 at 3:02 AM Min Ji wrote: > > > > > > Hello, > > > > > > This is a call for vote on releasing Apache Seata(incubating) > v2.1.0-RC4. > > > > > > The vote thread: > > > https://lists.apache.org/thread/s0gxv49802kk8y3dnxr8ytxy6ghkkjr6 > > > > > > Vote Result: > > > https://lists.apache.org/thread/km5dzmhw2j7ow86pk3g81f1z50sojomz > > > > > > The release candidates: > > > > https://dist.apache.org/repos/dist/dev/incubator/seata/incubator-seata/2.1.0/ > > > > > > The staging repo: > > > > https://repository.apache.org/content/repositories/orgapacheseata-1030/ > > > > > > Git tag for the release: > > > https://github.com/apache/incubator-seata/releases/tag/v2.1.0 > > > > > > Git commit id for the release: > > > > https://github.com/apache/incubator-seata/commit/38e9cea8bd611eca1e837e766b41a1334473c5f4 > > > > > > Release Notes: > > > https://github.com/apache/incubator-seata/releases/tag/v2.1.0 > > > > > > The artifacts have been signed with Key : > > > B51F1A5056BC5D6FBF2D82871E90338E9FA7635C, which can be found in the > > > keys file: > > > https://dist.apache.org/repos/dist/dev/incubator/seata/KEYS > > > > > > Build Environment: JDK 8+, Apache Maven 3.6.0+. > > > Build Command: ./mvnw clean package -DskipTests=true, If you are > > > building on an ARM64 architecture, please add the profile -Parrch64. > > > > > > CI Test Workflow: > > > > https://github.com/apache/incubator-seata/actions/runs/9527005533/job/26263693001 > > > > > > The vote will be open for at least 72 hours or until 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. > > > > > > > > > > > > Warm regards, > > > > > > Ji Min > > > > > > - > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > < > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > > Virus-free.www.avast.com > > < > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > > > - > > 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 Seata (Incubating) v2.1.0-RC4
> * seata-server/templates/_helpers.tpl [5] is a copy of a file in > github.com/open-hand/hzero-starter-parent/ - this should be mentioned > in your LICENSE unless the file in > github.com/open-hand/hzero-starter-parent/ is a copy of your file I found that the seata's file comes from 5 years ago while the hzero-starter-parent's one comes from 4 years ago. So it's possible that the seats one is the origin, or both copy from other starter sources. Anyway, it's necessary for the PPMC to identify its origin. Best, tison. tison 于2024年7月6日周六 12:23写道: > > * as an example, with 'CDDL-1.0 and GPL-2.0' [4], you should state > > that you choose CDDL-1.0 because GPL-2.0 is not allowed > > This is an interesting point. I suppose those NOTICE / LICENSE of binary > are generated by some maven plugins, or at least there are a few of ASF > projects doing so. Then it conveys the license info as is, while select > those dual licenses one by one can be hard without plugin's help. > > So we'd either: > (1) customized those plugins/automations to allow a mapping of license > chooser > (2) convey the license as is since the receiver can actually use those > code/artifacts under a Category A/B license. > > We may consider if (2) is acceptable and it would reduce lots of work. > > Best, > tison. > > > PJ Fanning 于2024年7月6日周六 12:13写道: > >> There are a number of other MIT licensed files in your >> console/src/main/resources/static folder and subfolders. CSS and >> Javascript files. >> >> All need to be mentioned in your LICENSE file. >> >> On Sat, 6 Jul 2024 at 20:00, PJ Fanning wrote: >> > >> > -1 (binding) from me >> > >> > * You have MIT Licensed code but no mention of it in your LICENSE [1]. >> > One example [2] but there is another g4 file with the same header. >> > * The LICENSE mentions BSD LIcense for Antlr and maybe this relates to >> > these MIT Licensed files but this isn't clear >> > * there is another MIT licensed source file with no mention in your >> LICENSE [3] >> > * seata-server/templates/_helpers.tpl [5] is a copy of a file in >> > github.com/open-hand/hzero-starter-parent/ - this should be mentioned >> > in your LICENSE unless the file in >> > github.com/open-hand/hzero-starter-parent/ is a copy of your file >> > * The LICENSE in your binary file could really be made easier to use >> > by explicitly including the names of the licenses instead of including >> > links to the license files many of which are not browser friendly. The >> > Abego one has an expired HTTPS cert. >> > * The LICENSE in your binary file should state which license you want >> > to use when the dependency has more than 1 license >> > * as an example, with 'CDDL-1.0 and GPL-2.0' [4], you should state >> > that you choose CDDL-1.0 because GPL-2.0 is not allowed >> > * more of a nit but I think you should use tar.gz for both the src and >> > bin artifacts - it seems odd to use zip for src and tar.gz for bin >> > >> > >> > >> > [1] https://github.com/apache/incubator-seata/blob/2.x/LICENSE >> > [2] >> https://github.com/apache/incubator-seata/blob/238cf3ab8e0c6f781e52f8efec19d54bab40cef0/sqlparser/seata-sqlparser-antlr/src/main/java/org/apache/seata/sqlparser/antlr/mysql/antlr/MySqlLexer.g4 >> > [3] >> https://github.com/apache/incubator-seata/blob/238cf3ab8e0c6f781e52f8efec19d54bab40cef0/console/src/main/resources/static/saga-statemachine-designer/bundle.js.LICENSE.txt >> > [4] >> https://github.com/apache/incubator-seata/blob/238cf3ab8e0c6f781e52f8efec19d54bab40cef0/distribution/LICENSE#L610 >> > [5] >> https://github.com/open-hand/hzero-starter-parent/blob/af7589bc0041f687b143e77f2171b1fd79ba0a9d/hzero-starter-seata/src/main/resources/script/server/helm/seata-server/templates/_helpers.tpl >> > >> > On Sat, 6 Jul 2024 at 19:17, PJ Fanning wrote: >> > > >> > > I think it would be better to put RC4 in the directory name of the >> release dir. >> > > >> > > >> https://dist.apache.org/repos/dist/dev/incubator/seata/incubator-seata/2.1.0/ >> > > should be >> > > >> https://dist.apache.org/repos/dist/dev/incubator/seata/incubator-seata/2.1.0-RC4/ >> > > or even >> > > https://dist.apache.org/repos/dist/dev/incubator/seata/2.1.0-RC4/ >> > > >> > > Don't put the RC4 in the name of the tar.gz files or the directory >> > > names inside the tar.gz. >> > > >> > > Again,
Re: [VOTE] Release Apache Seata (Incubating) v2.1.0-RC4
> * as an example, with 'CDDL-1.0 and GPL-2.0' [4], you should state > that you choose CDDL-1.0 because GPL-2.0 is not allowed This is an interesting point. I suppose those NOTICE / LICENSE of binary are generated by some maven plugins, or at least there are a few of ASF projects doing so. Then it conveys the license info as is, while select those dual licenses one by one can be hard without plugin's help. So we'd either: (1) customized those plugins/automations to allow a mapping of license chooser (2) convey the license as is since the receiver can actually use those code/artifacts under a Category A/B license. We may consider if (2) is acceptable and it would reduce lots of work. Best, tison. PJ Fanning 于2024年7月6日周六 12:13写道: > There are a number of other MIT licensed files in your > console/src/main/resources/static folder and subfolders. CSS and > Javascript files. > > All need to be mentioned in your LICENSE file. > > On Sat, 6 Jul 2024 at 20:00, PJ Fanning wrote: > > > > -1 (binding) from me > > > > * You have MIT Licensed code but no mention of it in your LICENSE [1]. > > One example [2] but there is another g4 file with the same header. > > * The LICENSE mentions BSD LIcense for Antlr and maybe this relates to > > these MIT Licensed files but this isn't clear > > * there is another MIT licensed source file with no mention in your > LICENSE [3] > > * seata-server/templates/_helpers.tpl [5] is a copy of a file in > > github.com/open-hand/hzero-starter-parent/ - this should be mentioned > > in your LICENSE unless the file in > > github.com/open-hand/hzero-starter-parent/ is a copy of your file > > * The LICENSE in your binary file could really be made easier to use > > by explicitly including the names of the licenses instead of including > > links to the license files many of which are not browser friendly. The > > Abego one has an expired HTTPS cert. > > * The LICENSE in your binary file should state which license you want > > to use when the dependency has more than 1 license > > * as an example, with 'CDDL-1.0 and GPL-2.0' [4], you should state > > that you choose CDDL-1.0 because GPL-2.0 is not allowed > > * more of a nit but I think you should use tar.gz for both the src and > > bin artifacts - it seems odd to use zip for src and tar.gz for bin > > > > > > > > [1] https://github.com/apache/incubator-seata/blob/2.x/LICENSE > > [2] > https://github.com/apache/incubator-seata/blob/238cf3ab8e0c6f781e52f8efec19d54bab40cef0/sqlparser/seata-sqlparser-antlr/src/main/java/org/apache/seata/sqlparser/antlr/mysql/antlr/MySqlLexer.g4 > > [3] > https://github.com/apache/incubator-seata/blob/238cf3ab8e0c6f781e52f8efec19d54bab40cef0/console/src/main/resources/static/saga-statemachine-designer/bundle.js.LICENSE.txt > > [4] > https://github.com/apache/incubator-seata/blob/238cf3ab8e0c6f781e52f8efec19d54bab40cef0/distribution/LICENSE#L610 > > [5] > https://github.com/open-hand/hzero-starter-parent/blob/af7589bc0041f687b143e77f2171b1fd79ba0a9d/hzero-starter-seata/src/main/resources/script/server/helm/seata-server/templates/_helpers.tpl > > > > On Sat, 6 Jul 2024 at 19:17, PJ Fanning wrote: > > > > > > I think it would be better to put RC4 in the directory name of the > release dir. > > > > > > > https://dist.apache.org/repos/dist/dev/incubator/seata/incubator-seata/2.1.0/ > > > should be > > > > https://dist.apache.org/repos/dist/dev/incubator/seata/incubator-seata/2.1.0-RC4/ > > > or even > > > https://dist.apache.org/repos/dist/dev/incubator/seata/2.1.0-RC4/ > > > > > > Don't put the RC4 in the name of the tar.gz files or the directory > > > names inside the tar.gz. > > > > > > Again, not a reason to restart the release process - but a suggestion > > > for the next RC whenever that is. > > > > > > On Fri, 5 Jul 2024 at 18:14, tison wrote: > > > > > > > > BTW, the unpacked folders name: > > > > > > > > apache-seata-2.1.0-incubating-src.zip -> incubator-seata-2.1.0 > > > > apache-seata-2.1.0-incubating-bin.tar.gz -> apache-seata > > > > > > > > looks unaligned. I suppose you try to name them: > > > > > > > > apache-seata-2.1.0-incubating-src.zip -> > apache-seata-2.1.0-incubating-src > > > > apache-seata-2.1.0-incubating-bin.tar.gz -> > > > > apache-seata-2.1.0-incubating-bin > > > > > > > > while this is a suggestion rather than some guidelines or policies. > > > > > > > > Best, > &g
Re: [VOTE] Release Apache Seata (Incubating) v2.1.0-RC4
No. I think it's fine to improve in the following release. But if you'd like to make a new RC, it's of course OK. Best, tison. Min Ji 于2024年7月6日周六 09:49写道: > Hi tison, > > Thank you very much for your suggestion. I have learned a lot from > your suggestion. Does changing the compressed directory name mean I > need to initiate a new round of voting? If so, I hope we can make the > correction in the next RC release. > > > Warm regards, > > Ji Min > > tison 于2024年7月6日周六 01:14写道: > > > > BTW, the unpacked folders name: > > > > apache-seata-2.1.0-incubating-src.zip -> incubator-seata-2.1.0 > > apache-seata-2.1.0-incubating-bin.tar.gz -> apache-seata > > > > looks unaligned. I suppose you try to name them: > > > > apache-seata-2.1.0-incubating-src.zip -> > apache-seata-2.1.0-incubating-src > > apache-seata-2.1.0-incubating-bin.tar.gz -> > > apache-seata-2.1.0-incubating-bin > > > > while this is a suggestion rather than some guidelines or policies. > > > > Best, > > tison. > > > > > > tison 于2024年7月5日周五 10:11写道: > > > > > +1 (binding) > > > > > > I checked: > > > > > > * Download links work > > > * Signature and checksum matches > > > > > > gpg: Signature made 六 6/15 06:08:36 2024 PDT > > > gpg:using RSA key > B51F1A5056BC5D6FBF2D82871E90338E9FA7635C > > > gpg: Good signature from "jimin (CODE SIGN) " > [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: B51F 1A50 56BC 5D6F BF2D 8287 1E90 338E 9FA7 > 635C > > > > > > * LICENSE / NOTICE / DISCLAIMER exist > > > * Files have ASF license header > > > > > > I cannot build from source on osx_aarch64 due to: > > > > > > [ERROR] Failed to execute goal > > > org.xolstice.maven.plugins:protobuf-maven-plugin:0.6.1:compile > (default) on > > > project seata-serializer-protobuf: Unable to resolve artifact: Missing: > > > [ERROR] -- > > > [ERROR] 1) com.google.protobuf:protoc:exe:osx-aarch_64:3.11.0 > > > [ERROR] > > > [ERROR] Try downloading the file manually from the project website. > > > [ERROR] > > > [ERROR] Then, install it using the command: > > > [ERROR] mvn install:install-file -DgroupId=com.google.protobuf > > > -DartifactId=protoc -Dversion=3.11.0 -Dclassifier=osx-aarch_64 > > > -Dpackaging=exe -Dfile=/path/to/file > > > [ERROR] > > > [ERROR] Alternatively, if you host your own repository you can deploy > > > the file there: > > > [ERROR] mvn deploy:deploy-file -DgroupId=com.google.protobuf > > > -DartifactId=protoc -Dversion=3.11.0 -Dclassifier=osx-aarch_64 > > > -Dpackaging=exe -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] > > > [ERROR] > > > [ERROR] Path to dependency: > > > [ERROR]1) org.apache.seata:seata-serializer-protobuf:jar:2.1.0 > > > [ERROR]2) com.google.protobuf:protoc:exe:osx-aarch_64:3.11.0 > > > [ERROR] > > > [ERROR] -- > > > [ERROR] 1 required artifact is missing. > > > [ERROR] > > > [ERROR] for artifact: > > > [ERROR] org.apache.seata:seata-serializer-protobuf:jar:2.1.0 > > > [ERROR] > > > [ERROR] from the specified remote repositories: > > > [ERROR] apache.snapshots (https://repository.apache.org/snapshots, > > > releases=false, snapshots=true), > > > [ERROR] central (https://repo.maven.apache.org/maven2, > releases=true, > > > snapshots=false) > > > > > > But I think it's fair enough to upgrade the related dependencies in a > > > following commit. > > > > > > The link to KEYS file should be updated as stated above, but it's not a > > > release blocker anyway. > > > > > > Best, > > > tison. > > > > > > Best, > > > tison. > > > > > > > > > tison 于2024年7月5日周五 10:09写道: > > > > > >> You should use https://downloads.apache.org/incubator/seata/KEYS > > >> instead of dist dev. > > >> > > >> You can upload the KEYS file to > > >> https://dist.apache.org/repos/dist/release/incubator/seata/KEYS and > > >> the downloads link would work. > > >> > > >> Best, > > >> tison. > >
Re: [VOTE] Release Apache Seata (Incubating) v2.1.0-RC4
BTW, the unpacked folders name: apache-seata-2.1.0-incubating-src.zip -> incubator-seata-2.1.0 apache-seata-2.1.0-incubating-bin.tar.gz -> apache-seata looks unaligned. I suppose you try to name them: apache-seata-2.1.0-incubating-src.zip -> apache-seata-2.1.0-incubating-src apache-seata-2.1.0-incubating-bin.tar.gz -> apache-seata-2.1.0-incubating-bin while this is a suggestion rather than some guidelines or policies. Best, tison. tison 于2024年7月5日周五 10:11写道: > +1 (binding) > > I checked: > > * Download links work > * Signature and checksum matches > > gpg: Signature made 六 6/15 06:08:36 2024 PDT > gpg:using RSA key B51F1A5056BC5D6FBF2D82871E90338E9FA7635C > gpg: Good signature from "jimin (CODE SIGN) " [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: B51F 1A50 56BC 5D6F BF2D 8287 1E90 338E 9FA7 635C > > * LICENSE / NOTICE / DISCLAIMER exist > * Files have ASF license header > > I cannot build from source on osx_aarch64 due to: > > [ERROR] Failed to execute goal > org.xolstice.maven.plugins:protobuf-maven-plugin:0.6.1:compile (default) on > project seata-serializer-protobuf: Unable to resolve artifact: Missing: > [ERROR] -- > [ERROR] 1) com.google.protobuf:protoc:exe:osx-aarch_64:3.11.0 > [ERROR] > [ERROR] Try downloading the file manually from the project website. > [ERROR] > [ERROR] Then, install it using the command: > [ERROR] mvn install:install-file -DgroupId=com.google.protobuf > -DartifactId=protoc -Dversion=3.11.0 -Dclassifier=osx-aarch_64 > -Dpackaging=exe -Dfile=/path/to/file > [ERROR] > [ERROR] Alternatively, if you host your own repository you can deploy > the file there: > [ERROR] mvn deploy:deploy-file -DgroupId=com.google.protobuf > -DartifactId=protoc -Dversion=3.11.0 -Dclassifier=osx-aarch_64 > -Dpackaging=exe -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] > [ERROR] > [ERROR] Path to dependency: > [ERROR]1) org.apache.seata:seata-serializer-protobuf:jar:2.1.0 > [ERROR]2) com.google.protobuf:protoc:exe:osx-aarch_64:3.11.0 > [ERROR] > [ERROR] -- > [ERROR] 1 required artifact is missing. > [ERROR] > [ERROR] for artifact: > [ERROR] org.apache.seata:seata-serializer-protobuf:jar:2.1.0 > [ERROR] > [ERROR] from the specified remote repositories: > [ERROR] apache.snapshots (https://repository.apache.org/snapshots, > releases=false, snapshots=true), > [ERROR] central (https://repo.maven.apache.org/maven2, releases=true, > snapshots=false) > > But I think it's fair enough to upgrade the related dependencies in a > following commit. > > The link to KEYS file should be updated as stated above, but it's not a > release blocker anyway. > > Best, > tison. > > Best, > tison. > > > tison 于2024年7月5日周五 10:09写道: > >> You should use https://downloads.apache.org/incubator/seata/KEYS >> instead of dist dev. >> >> You can upload the KEYS file to >> https://dist.apache.org/repos/dist/release/incubator/seata/KEYS and >> the downloads link would work. >> >> Best, >> tison. >> >> Min Ji 于2024年7月5日周五 10:03写道: >> > >> > Hello, >> > >> > This is a call for vote on releasing Apache Seata(incubating) >> v2.1.0-RC4. >> > >> > The vote thread: >> > https://lists.apache.org/thread/s0gxv49802kk8y3dnxr8ytxy6ghkkjr6 >> > >> > Vote Result: >> > https://lists.apache.org/thread/km5dzmhw2j7ow86pk3g81f1z50sojomz >> > >> > The release candidates: >> > >> https://dist.apache.org/repos/dist/dev/incubator/seata/incubator-seata/2.1.0/ >> > >> > The staging repo: >> > https://repository.apache.org/content/repositories/orgapacheseata-1030/ >> > >> > Git tag for the release: >> > https://github.com/apache/incubator-seata/releases/tag/v2.1.0 >> > >> > Git commit id for the release: >> > >> https://github.com/apache/incubator-seata/commit/38e9cea8bd611eca1e837e766b41a1334473c5f4 >> > >> > Release Notes: >> > https://github.com/apache/incubator-seata/releases/tag/v2.1.0 >> > >> > The artifacts have been signed with Key : >> > B51F1A5056BC5D6FBF2D82871E90338E9FA7635C, which can be found in the >> > keys file: >> > https://dist.apache.org/repos/dist/dev/incubator/seata/KEYS >> > >> > Build Environment: JDK 8+, Apache Maven 3.6.0+. >> > Build Command: ./mvnw clean package -DskipTests=true, If you are >
Re: [VOTE] Release Apache Seata (Incubating) v2.1.0-RC4
+1 (binding) I checked: * Download links work * Signature and checksum matches gpg: Signature made 六 6/15 06:08:36 2024 PDT gpg:using RSA key B51F1A5056BC5D6FBF2D82871E90338E9FA7635C gpg: Good signature from "jimin (CODE SIGN) " [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: B51F 1A50 56BC 5D6F BF2D 8287 1E90 338E 9FA7 635C * LICENSE / NOTICE / DISCLAIMER exist * Files have ASF license header I cannot build from source on osx_aarch64 due to: [ERROR] Failed to execute goal org.xolstice.maven.plugins:protobuf-maven-plugin:0.6.1:compile (default) on project seata-serializer-protobuf: Unable to resolve artifact: Missing: [ERROR] -- [ERROR] 1) com.google.protobuf:protoc:exe:osx-aarch_64:3.11.0 [ERROR] [ERROR] Try downloading the file manually from the project website. [ERROR] [ERROR] Then, install it using the command: [ERROR] mvn install:install-file -DgroupId=com.google.protobuf -DartifactId=protoc -Dversion=3.11.0 -Dclassifier=osx-aarch_64 -Dpackaging=exe -Dfile=/path/to/file [ERROR] [ERROR] Alternatively, if you host your own repository you can deploy the file there: [ERROR] mvn deploy:deploy-file -DgroupId=com.google.protobuf -DartifactId=protoc -Dversion=3.11.0 -Dclassifier=osx-aarch_64 -Dpackaging=exe -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] [ERROR] [ERROR] Path to dependency: [ERROR]1) org.apache.seata:seata-serializer-protobuf:jar:2.1.0 [ERROR]2) com.google.protobuf:protoc:exe:osx-aarch_64:3.11.0 [ERROR] [ERROR] -- [ERROR] 1 required artifact is missing. [ERROR] [ERROR] for artifact: [ERROR] org.apache.seata:seata-serializer-protobuf:jar:2.1.0 [ERROR] [ERROR] from the specified remote repositories: [ERROR] apache.snapshots (https://repository.apache.org/snapshots, releases=false, snapshots=true), [ERROR] central (https://repo.maven.apache.org/maven2, releases=true, snapshots=false) But I think it's fair enough to upgrade the related dependencies in a following commit. The link to KEYS file should be updated as stated above, but it's not a release blocker anyway. Best, tison. Best, tison. tison 于2024年7月5日周五 10:09写道: > You should use https://downloads.apache.org/incubator/seata/KEYS > instead of dist dev. > > You can upload the KEYS file to > https://dist.apache.org/repos/dist/release/incubator/seata/KEYS and > the downloads link would work. > > Best, > tison. > > Min Ji 于2024年7月5日周五 10:03写道: > > > > Hello, > > > > This is a call for vote on releasing Apache Seata(incubating) v2.1.0-RC4. > > > > The vote thread: > > https://lists.apache.org/thread/s0gxv49802kk8y3dnxr8ytxy6ghkkjr6 > > > > Vote Result: > > https://lists.apache.org/thread/km5dzmhw2j7ow86pk3g81f1z50sojomz > > > > The release candidates: > > > https://dist.apache.org/repos/dist/dev/incubator/seata/incubator-seata/2.1.0/ > > > > The staging repo: > > https://repository.apache.org/content/repositories/orgapacheseata-1030/ > > > > Git tag for the release: > > https://github.com/apache/incubator-seata/releases/tag/v2.1.0 > > > > Git commit id for the release: > > > https://github.com/apache/incubator-seata/commit/38e9cea8bd611eca1e837e766b41a1334473c5f4 > > > > Release Notes: > > https://github.com/apache/incubator-seata/releases/tag/v2.1.0 > > > > The artifacts have been signed with Key : > > B51F1A5056BC5D6FBF2D82871E90338E9FA7635C, which can be found in the > > keys file: > > https://dist.apache.org/repos/dist/dev/incubator/seata/KEYS > > > > Build Environment: JDK 8+, Apache Maven 3.6.0+. > > Build Command: ./mvnw clean package -DskipTests=true, If you are > > building on an ARM64 architecture, please add the profile -Parrch64. > > > > CI Test Workflow: > > > https://github.com/apache/incubator-seata/actions/runs/9527005533/job/26263693001 > > > > The vote will be open for at least 72 hours or until 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. > > > > > > > > Warm regards, > > > > Ji Min > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > >
Re: [VOTE] Release Apache Seata (Incubating) v2.1.0-RC4
You should use https://downloads.apache.org/incubator/seata/KEYS instead of dist dev. You can upload the KEYS file to https://dist.apache.org/repos/dist/release/incubator/seata/KEYS and the downloads link would work. Best, tison. Min Ji 于2024年7月5日周五 10:03写道: > > Hello, > > This is a call for vote on releasing Apache Seata(incubating) v2.1.0-RC4. > > The vote thread: > https://lists.apache.org/thread/s0gxv49802kk8y3dnxr8ytxy6ghkkjr6 > > Vote Result: > https://lists.apache.org/thread/km5dzmhw2j7ow86pk3g81f1z50sojomz > > The release candidates: > https://dist.apache.org/repos/dist/dev/incubator/seata/incubator-seata/2.1.0/ > > The staging repo: > https://repository.apache.org/content/repositories/orgapacheseata-1030/ > > Git tag for the release: > https://github.com/apache/incubator-seata/releases/tag/v2.1.0 > > Git commit id for the release: > https://github.com/apache/incubator-seata/commit/38e9cea8bd611eca1e837e766b41a1334473c5f4 > > Release Notes: > https://github.com/apache/incubator-seata/releases/tag/v2.1.0 > > The artifacts have been signed with Key : > B51F1A5056BC5D6FBF2D82871E90338E9FA7635C, which can be found in the > keys file: > https://dist.apache.org/repos/dist/dev/incubator/seata/KEYS > > Build Environment: JDK 8+, Apache Maven 3.6.0+. > Build Command: ./mvnw clean package -DskipTests=true, If you are > building on an ARM64 architecture, please add the profile -Parrch64. > > CI Test Workflow: > https://github.com/apache/incubator-seata/actions/runs/9527005533/job/26263693001 > > The vote will be open for at least 72 hours or until 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. > > > > Warm regards, > > Ji Min > > - > 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: [QUESTION] Can we use an AGPL components [minio] in OpenServerless?
> an optional dependency I second Justin's opinion, while "an opt dep" generally means: if you use it only for test, it should be fine; if you support user to self deploy or get a provision by themselves, and use your ALv2 licensed SDK to connect to it, it should be fine. But if you'd like to bundle the source form or object form of minio (AGPLv3 licensed work), then the situation would be complex. Best, tison. Justin Mclean 于2024年7月5日周五 07:06写道: > > Hi, > > I would ask legal-disc...@apache.org, but it would not be allowed unless it > is an optional dependency. However, it depends on the exact details. > > Kind Regards, > Justin > > > On 5 Jul 2024, at 6:45 pm, Michele Sciabarra > > wrote: > > > > If this is not the right place to ask this question please ignore it and > > let me know where I should ask. > > > > We are starting the OpenServerless project and checking licenses. > > > > We have one component in our project, Minio, which is AGPL Licensed. > > > > We know AGPL is not to be used in Apache Code but here we really do not > > link nor change it, we just use it and access through their API as a > > generic S3 storage. > > > > We do not even use their library to access it, we use the AWS SDK for > > generic S3. > > > > My understanding of the AGPL is: we have to provide the code of it and any > > modification EVEN if it is accessed through the network. This is fine, we > > are complying with the license providing a downloadable tarball of the > > exact version we are using. > > > > Aside from that, can we use it in OpenServerless? It just deploys a minio > > component, it does not modify it in any way. > > > > Please advise... > > > > -- > > Michele Sciabarrà - msciaba...@apache.org - linkedin.com/in/msciab > > Apache OpenServerless Founder - reddit.com/r/openserverless > > Apache OpenWhisk PMC member - Author Learning Apache OpenWhisk > > <https://www.oreilly.com/library/view/learning-apache-openwhisk/9781492046158/> > > > - > 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: PMC is a committee
... and yes. For non-native speakers, it's possible to feel less uncomfortable to use "PMC" as an abbr. to PMC members. Just .. as an opaque term. Best, tison. Xuanwo 于2024年7月2日周二 19:56写道: > > This thread reminds me of tison's proposal that use "Maintainer" instead of > "PMC Member". > > https://lists.apache.org/thread/xsjojmksqtnsdjcg0yf4vz0xy82llhmw > > On Wed, Jul 3, 2024, at 10:04, Jiacai Liu wrote: > >> And, we can all be tired, overworked, or lazy and say the wrong > >> thing *or* > >> get into bad habits. > > > > Thank John for your kindly understanding. > > > > Also as a non-native English speaker, when I see abbreviation like > > PMC, > > my first insight is this word could be used on its own, `PMC > > member` looks a little redundancy for me... > > > > on Wed, Jul 03, 2024 at 08:50:45 AM +0800, John Gemignani wrote: > > > >> My 2 cents as being a PMC member and once part of incubation,... > >> > >> To be honest, I've never really paid much attention when someone > >> stated > >> they're a PMC. I knew what was meant and just auto corrected it > >> in my head. > >> I have used, without fully thinking about it, PMC as, "I am a > >> PMC" as well. > >> When I meant, or should have meant, "I am a PMC member", and I'm > >> a native > >> English speaker. > >> > >> As was mentioned, people from different cultures might have > >> different ways > >> of using a term like PMC. I just don't feel that getting upset > >> over, > >> arguably an innocuous misuse, engenders community. > >> > >> And, we can all be tired, overworked, or lazy and say the wrong > >> thing *or* > >> get into bad habits. > >> > >> Again, my 2 cents. > >> > >> john > >> > >> On Tue, Jul 2, 2024 at 5:33 PM Dave Fisher > >> wrote: > >> > >>> Hi Tison, > >>> > >>> I’m sympathetic as well. > >>> > >>> > On Jul 2, 2024, at 5:11 PM, tison > >>> > wrote: > >>> > > >>> > Hi Greg, > >>> > > >>> > I saw this kind of thread many times, and I also corrected it > >>> > dozens > >>> > of times. Actually, this is part of the reason for [1] > >>> > ("Maintainer" > >>> > as an alias of PMC Member?). > >>> > > >>> > [1] > >>> > https://lists.apache.org/thread/xsjojmksqtnsdjcg0yf4vz0xy82llhmw > >>> > >>> That quickly turned into a not very sympathetic response from > >>> most. An > >>> easy what to name the Bikeshed. I think that most of our group > >>> are people > >>> whose second language is python, java, or fortran and their > >>> first language > >>> is some version of English. > >>> > >>> > > >>> > Somehow, I share the sympathy for non-native speakers to make > >>> > an > >>> > analogy between committer and "PMC" since they're all > >>> > one-word > >>> > phrases. > >>> > >>> Maybe explain it from your perspective as a speaker of Mandarin > >>> (or > >>> Cantonese?). How does the phrase Committee Member translate > >>> compared to > >>> Committee. > >>> > >>> Best, > >>> Dave > >>> > > >>> > Best, > >>> > tison. > >>> > > >>> > Greg Stein 于2024年7月2日周二 17:05写道: > >>> >> > >>> >> Hello all, > >>> >> > >>> >> I am getting really tired of seeing people refer to > >>> >> *MEMBERS* of a PMC > >>> as > >>> >> "PMCs". > >>> >> > >>> >> PMC stands for Project Management Committee. > >>> >> > >>> >> You have MEMBERS of that PMC. > >>> >> > >>> >> People are never to be called a PMC, nor a group of them as > >>> >> PMCs. People > >>> >> are not committees. The acronym "PMC" is short for a > >>> >> committee, not a > >>> >> person. > >>> >> > >>> >> Please stop the confusion. Teach the community how to use > >>> >> the proper > >>> terms. > >>> >> > >>> >> Thanks, > >>> >> Greg > >>> > > >>> > - > >>> > 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 > > -- > Xuanwo > > https://xuanwo.io/ > > - > 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: PMC is a committee
> Maybe explain it from your perspective as a speaker of Mandarin Hi Dave, I have two answers for why this misuse is so wide. 1. Some important connection points in the local Apache community give the wrong practice. Let me name some of them, and please do not interpret it as a blame. I saw blog posts from Apache Flink WeChat Account, channels managed by Dromara org (who donates ShenYu and more) often use the term "PMC" to refer "PMC Members", like "Congrats to sb. to become a PMC". It's so common to use and their influence let newcomers just interpret PMC as an opaque term as an alias to "maintainer" or "a title that in a higher level than committer" (while such hierarchical community understand is another common misunderstanding). 2. So, I believe when people actually know that PMC stands for "Project Management Committee" and know what a "Committee" is (it's not a common word, I have to say), they can use it properly. But basically, they don't know what "PMC" means, as stated above. Best, tison. Jiacai Liu 于2024年7月2日周二 19:50写道: > > > > And, we can all be tired, overworked, or lazy and say the wrong > > thing *or* > > get into bad habits. > > Thank John for your kindly understanding. > > Also as a non-native English speaker, when I see abbreviation like > PMC, > my first insight is this word could be used on its own, `PMC > member` looks a little redundancy for me... > > on Wed, Jul 03, 2024 at 08:50:45 AM +0800, John Gemignani wrote: > > > My 2 cents as being a PMC member and once part of incubation,... > > > > To be honest, I've never really paid much attention when someone > > stated > > they're a PMC. I knew what was meant and just auto corrected it > > in my head. > > I have used, without fully thinking about it, PMC as, "I am a > > PMC" as well. > > When I meant, or should have meant, "I am a PMC member", and I'm > > a native > > English speaker. > > > > As was mentioned, people from different cultures might have > > different ways > > of using a term like PMC. I just don't feel that getting upset > > over, > > arguably an innocuous misuse, engenders community. > > > > And, we can all be tired, overworked, or lazy and say the wrong > > thing *or* > > get into bad habits. > > > > Again, my 2 cents. > > > > john > > > > On Tue, Jul 2, 2024 at 5:33 PM Dave Fisher > > wrote: > > > >> Hi Tison, > >> > >> I’m sympathetic as well. > >> > >> > On Jul 2, 2024, at 5:11 PM, tison > >> > wrote: > >> > > >> > Hi Greg, > >> > > >> > I saw this kind of thread many times, and I also corrected it > >> > dozens > >> > of times. Actually, this is part of the reason for [1] > >> > ("Maintainer" > >> > as an alias of PMC Member?). > >> > > >> > [1] > >> > https://lists.apache.org/thread/xsjojmksqtnsdjcg0yf4vz0xy82llhmw > >> > >> That quickly turned into a not very sympathetic response from > >> most. An > >> easy what to name the Bikeshed. I think that most of our group > >> are people > >> whose second language is python, java, or fortran and their > >> first language > >> is some version of English. > >> > >> > > >> > Somehow, I share the sympathy for non-native speakers to make > >> > an > >> > analogy between committer and "PMC" since they're all > >> > one-word > >> > phrases. > >> > >> Maybe explain it from your perspective as a speaker of Mandarin > >> (or > >> Cantonese?). How does the phrase Committee Member translate > >> compared to > >> Committee. > >> > >> Best, > >> Dave > >> > > >> > Best, > >> > tison. > >> > > >> > Greg Stein 于2024年7月2日周二 17:05写道: > >> >> > >> >> Hello all, > >> >> > >> >> I am getting really tired of seeing people refer to > >> >> *MEMBERS* of a PMC > >> as > >> >> "PMCs". > >> >> > >> >> PMC stands for Project Management Committee. > >> >> > >> >> You have MEMBERS of that PMC. > >> >> > >> >> People are never to be called a PMC, nor a group of them as > >> >> PMCs. People > >> >> are not
Re: PMC is a committee
Hi Greg, I saw this kind of thread many times, and I also corrected it dozens of times. Actually, this is part of the reason for [1] ("Maintainer" as an alias of PMC Member?). [1] https://lists.apache.org/thread/xsjojmksqtnsdjcg0yf4vz0xy82llhmw Somehow, I share the sympathy for non-native speakers to make an analogy between committer and "PMC" since they're all one-word phrases. Best, tison. Greg Stein 于2024年7月2日周二 17:05写道: > > Hello all, > > I am getting really tired of seeing people refer to *MEMBERS* of a PMC as > "PMCs". > > PMC stands for Project Management Committee. > > You have MEMBERS of that PMC. > > People are never to be called a PMC, nor a group of them as PMCs. People > are not committees. The acronym "PMC" is short for a committee, not a > person. > > Please stop the confusion. Teach the community how to use the proper terms. > > Thanks, > Greg - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Answer(Incubating) v1.3.5-RC1
+1 (binding) I checked the source release: - incubating in the name - signatures and hashes match: gpg: Signature made 二 6/18 03:12:31 2024 PDT gpg:using RSA key ACD15F4B84493A8C365B5F75113981764C21E346 gpg:issuer "sh...@apache.org" gpg: Good signature from "Shuailing Li (for apache release) " [unknown] gpg: WARNING: The key's User ID is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: ACD1 5F4B 8449 3A8C 365B 5F75 1139 8176 4C21 E346 - LICENSE, NOTICE, and DISCLAIMER exists - No unexpected binary files - Can build from source with: $ cd ./apache-answer-1.3.5-incubating-src/ $ make $ ./answer -v answer version 1.3.5 revision: build time: 1719808165 Best, tison. Guangfu Yang 于2024年6月26日周三 23:44写道: > > Sorry, I shouldn't vote on the general mailing list. > > Carry my no-binding +1 from dev list. > > On 2024/06/27 04:26:49 Guangfu Yang wrote: > > +1 approve > > > > Best Regards, > > Kumfo > > > > - > > 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] Accept Gravitino into the ASF Incubator
+1 binding Best, tison. Roman Shaposhnik 于2024年5月30日周四 07:38写道: > +1 (binding) > > On Wed, May 29, 2024 at 4:21 PM larry mccay wrote: > > > > +1 (binding) > > > > On Wed, May 29, 2024 at 1:33 PM Weiwei Yang wrote: > > > > > +1 > > > > > > On Wed, May 29, 2024 at 8:59 AM Jean-Baptiste Onofré > > > wrote: > > > > > > > Sorry, the links have not been pasted correctly: > > > > > > > > Here's the discussion: > > > > https://lists.apache.org/thread/5bp5t0hgq2c419m62m2zt71jkv8bhhho > > > > > > > > And the proposal: > > > > > https://cwiki.apache.org/confluence/display/INCUBATOR/GravitinoProposal > > > > > > > > Regards > > > > JB > > > > > > > > On Wed, May 29, 2024 at 5:31 PM Jean-Baptiste Onofré < > j...@nanthrax.net> > > > > wrote: > > > > > > > > > > Hi folks, > > > > > > > > > > Following the discussion about Gravitino [1], I would like to start > > > > > the formal vote to accept Gravitino into the ASF Incubator. > > > > > > > > > > As reminder, this is the Gravitino Proposal: > > > > > > > > > > Please cast your vote: > > > > > > > > > > [ ] +1, accept Gravitino into the ASF Incubator > > > > > [ ] 0, I don't care either way > > > > > [ ] -1, do not accept Gravitino into the ASF Incubator, because ... > > > > > > > > > > The vote will run for one week starting from today. > > > > > > > > > > Thanks ! > > > > > > > > > > Regards > > > > > JB > > > > > > > > - > > > > 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: [SUGGESTION] Allow Xuanwo to join Fury as a mentor.
Thanks for your feedback :D I've invited Xuanwo as a mentor. All the LDAP changes should happen automatically, or you can reach out to the INFRA for help. You may help in updating the project status page [1] and follow this guide [2] for any other entries that need to be updated. [1] https://incubator.apache.org/projects/fury.html [2] https://github.com/alc-beijing/alc-site/wiki/IPMC%E5%BB%BA%E8%AE%BE%E6%96%B0%E9%A1%B9%E7%9B%AE%E5%9F%BA%E7%A1%80%E5%AE%9E%E6%96%BD%E9%85%8D%E7%BD%AE%E6%8C%87%E5%8D%97 Welcome! Best, tison.
Re: [VOTE] Release Apache Fury(incubating) v0.5.1-rc2
+1 binding [x] Download links are valid. [x] Checksums and signatures. [x] LICENSE, NOTICE, and DISCLAIMER files exist [x] Can compile from source for Java and Rust Best, tison. Xin Wang 于2024年5月27日周一 23:03写道: > +1 binding > > [x] Download links are valid. > [x] Checksums and signatures. > [x] LICENSE/NOTICE files exist > [x] No unexpected binary files > [x] All source files have ASF headers > [x] Can compile from source > > Shawn Yang 于2024年5月27日周一 22:50写道: > > > Hi Xuanwo, > > > > Thanks for helping review Fury release and the help with previous > > releases of Fury. > > Looking forward to you joining Fury as a mentor to help Fury > continuously. > > > > Best regards, > > Chaokun Yang > > > > > > > > On Mon, May 27, 2024 at 9:25 PM Xuanwo wrote: > > > > > > +1 binding from Xuanwo. > > > > > > Feel free to add me to the mentor list if you need help with > > rust-related tasks and releases. I'm happy to assist. > > > > > > [x] Download links are valid. > > > [x] Checksums and signatures. > > > > > > gpg: Signature made Mon 20 May 2024 05:49:27 PM CST > > > gpg:using RSA key > > 1E2CDAE4C08AD7D694D1CB139D7BE8E45E580BA4 > > > gpg: checking the trustdb > > > gpg: marginals needed: 3 completes needed: 1 trust model: pgp > > > gpg: depth: 0 valid: 28 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 28u > > > gpg: next trustdb check due at 2024-08-23 > > > gpg: Good signature from "chaokunyang (CODE SIGNING KEY) < > > chaokuny...@apache.org>" [ultimate] > > > apache-fury-0.5.1-incubating-src.tar.gz: OK > > > > > > [x] LICENSE/NOTICE files exist > > > [x] No unexpected binary files > > > [x] All source files have ASF headers > > > [x] Can compile from source on archlinux x86-64 > > > > > > I have checked rust build: > > > > > > Finished `dev` profile [unoptimized + debuginfo] target(s) in 4.83s > > > > > > On Mon, May 27, 2024, at 21:03, Suyan wrote: > > > > +1 binding from suyanhanx > > > > > > > > I checked: > > > > [x] Download links are valid. > > > > [x] Checksums and signatures. > > > > [x] LICENSE/NOTICE files exist > > > > [x] No unexpected binary files > > > > [x] All source files have ASF headers > > > > [x] Can compile from source on macOS(arm64) > > > > I tried compiling the Java, JavaScript, and Rust packages, and they > > > > all built successfully. > > > > > > > > > > > > Sincerely, > > > > Suyan > > > > > > > > Shawn Yang 于2024年5月23日周四 22:23写道: > > > >> > > > >> Hello everyone, > > > >> > > > >> This is a call for the vote to release Apache Fury(Incubating) > > v0.5.1-rc2. > > > >> > > > >> The Apache Fury community has voted and approved the release of > Apache > > > >> Fury(incubating) v0.5.1-rc2. 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/kof226qkft02jcj62kt6wnppdnm2jgzx > > > >> > > > >> Vote result thread: > > > >> https://lists.apache.org/thread/z7cvvw1omdpg76gpbcv2m5crk0mdwc8k > > > >> > > > >> The release candidate: > > > >> https://dist.apache.org/repos/dist/dev/incubator/fury/0.5.1-rc2/ > > > >> > > > >> 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.1-rc2 > > > >> > > > >> Git commit for the release: > > > >> > > > https://github.com/apache/incubator-fury/commit/0455ff732b9217785193f8e45f3a013eb5539e46 > > > >> > > > >> Maven staging repo: > > > >> > https://repository.apache.org/content/repositories/orgapachefury-1010 > > > >> > > > >> How to Build and Test, please refer to: > > > >> > > > htt
Re: [DISCUSS] OpenServerless Proposal to the incubator
Generally we have one champion and this person drives your entering incubator. Later, there's no champion but all mentors. Thus, I don't think you need to make two champions. Best, tison. Michele Sciabarra 于2024年5月27日 周一22:57写道: > Hello, I do not know if it is possible to have 2 champions, but if it is, I > will happily accept both Enrico and Jean-Baptise as Champions, and also > Francois as a mentor. > > I updated the serverless proposal accordingly. > > I would ask: how can we check if the OpenServerless project name is > suitable? Looks like the Serverless word is a trademark of Serverless Inc, > the makers of the Serverless Framework. > > What are the next steps? > > Thanks! > > > > Michele Sciabarra | CEO > > m: +44 747 984 8388 > e: mich...@nuvolaris.io > l: https://linkedin.com/in/msciab > Nuvolaris Inc | 1209 Orange Street , Wilmington DE > <https://www.google.com/maps/search/1209+Orange+Street+,+Wilmington+DE?entry=gmail&source=g> > www.nuvolaris.io [image: linkedin icon] > <https://www.linkedin.com/company/nuvolaris-io> [image: youtube icon] > <http://bit.ly/nuvtube> [image: twitter icon] > <https://twitter.com/NuvolarisIo> > > > On Mon, 27 May 2024 at 13:10, Enrico Olivelli wrote: > > > Thanks for the proposal. > > I confirm that I will be happy to help as mentor and champion > > > > Enrico > > > > Il Lun 27 Mag 2024, 11:45 Michele Sciabarra ha > > scritto: > > > > > Thanks, I fixed it. Also since the code is spread among many > > repositories I > > > added more contribution graphs. > > > Also I thought it worth to mention the project "Fantacalcio" built on > top > > > of Nuvolaris with many contributors. > > > > > > > > > Michele Sciabarra | CEO > > > > > > m: +44 747 984 8388 > > > e: mich...@nuvolaris.io > > > l: https://linkedin.com/in/msciab > > > Nuvolaris Inc | 1209 Orange Street , Wilmington DE > > > www.nuvolaris.io [image: linkedin icon] > > > <https://www.linkedin.com/company/nuvolaris-io> [image: youtube icon] > > > <http://bit.ly/nuvtube> [image: twitter icon] > > > <https://twitter.com/NuvolarisIo> > > > > > > > > > On Mon, 27 May 2024 at 10:36, tison wrote: > > > > > > > The contributor graph link seems incorrectly link to Apache > Openwhisk. > > > > > > > > > Contribution Graphs: > > > > https://github.com/openwhisk/openwhisk/graphs/contributors > > > > > > > > Best, > > > > tison. > > > > > > > > > > > > Michele Sciabarra 于2024年5月27日周一 17:28写道: > > > > > > > > > Hi Jean-Baptiste, > > > > > > > > > > Yes, we are looking for a champion, and our mentor Enrico Olivelli > > > > > suggested we just ask on the channel. > > > > > > > > > > If you are available I will rea > <https://www.google.com/maps/search/%3E+If+you+are+available+I+will+rea?entry=gmail&source=g>dily > accept. > > > > > > > > > > > > > > > Michele Sciabarra | CEO > > > > > > > > > > m: +44 747 984 8388 > > > > > e: mich...@nuvolaris.io > > > > > l: https://linkedin.com/in/msciab > > > > > Nuvolaris Inc | 1209 Orange Street , Wilmington DE > > > > > www.nuvolaris.io [image: linkedin icon] > > > > > <https://www.linkedin.com/company/nuvolaris-io> [image: youtube > > icon] > > > > > <http://bit.ly/nuvtube> [image: twitter icon] > > > > > <https://twitter.com/NuvolarisIo> > > > > > > > > > > > > > > > On Mon, 27 May 2024 at 09:33, Jean-Baptiste Onofré < > j...@nanthrax.net> > > > > > wrote: > > > > > > > > > > > Hi Michele > > > > > > > > > > > > I like the proposal, especially by the relationship with several > > > other > > > > > > Apache projects. > > > > > > > > > > > > If you look for a champion, please let me know if I can help. > > > > > > > > > > > > Thanks ! > > > > > > Regards > > > > > > JB > > > > > > > > > > > > On Sun, May 26, 2024 at 9:50 PM Michele Sciabarra < > > > > mich...@nuvolaris.io> > > > > > >
Re: [SUGGESTION] Allow Xuanwo to join Fury as a mentor.
Cool! I can add you as a mentor on whimsy later. Let's also cc dev@fury.a.o for any feedback. Best, tison. Shawn Yang 于2024年5月27日 周一22:46写道: > Looks great to me, > > Xuanwo has been continuously active in the incubator and helped the > release of many podlings including Fury . > > His experience in rust and opendal incubation would be a great help to > Fury. > > Looking forward to collaborating with Xuanwo. > > Best regards, > Chaokun Yang > > > On Mon, May 27, 2024 at 9:40 PM Xuanwo wrote: > > > > Hi, > > > > I am willing to join Fury as a mentor, assisting with rust-related > projects and release management to help build the community. > > > > Please consider my suggestion. Thank you! > > > > 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: [DISCUSS] OpenServerless Proposal to the incubator
The contributor graph link seems incorrectly link to Apache Openwhisk. > Contribution Graphs: https://github.com/openwhisk/openwhisk/graphs/contributors Best, tison. Michele Sciabarra 于2024年5月27日周一 17:28写道: > Hi Jean-Baptiste, > > Yes, we are looking for a champion, and our mentor Enrico Olivelli > suggested we just ask on the channel. > > If you are available I will readily accept. > > > Michele Sciabarra | CEO > > m: +44 747 984 8388 > e: mich...@nuvolaris.io > l: https://linkedin.com/in/msciab > Nuvolaris Inc | 1209 Orange Street , Wilmington DE > www.nuvolaris.io [image: linkedin icon] > <https://www.linkedin.com/company/nuvolaris-io> [image: youtube icon] > <http://bit.ly/nuvtube> [image: twitter icon] > <https://twitter.com/NuvolarisIo> > > > On Mon, 27 May 2024 at 09:33, Jean-Baptiste Onofré > wrote: > > > Hi Michele > > > > I like the proposal, especially by the relationship with several other > > Apache projects. > > > > If you look for a champion, please let me know if I can help. > > > > Thanks ! > > Regards > > JB > > > > On Sun, May 26, 2024 at 9:50 PM Michele Sciabarra > > wrote: > > > > > > Hi Apache Incubator members, > > > > > > I would like to propose a new project to the ASF incubator - > > OpenServerless. > > > > > > OpenServerless (currently Nuvolaris Community) is a complete Serverless > > > platform for Kubernetes built on top of Apache OpenWhisk, Redis, > > PosgreSQL, > > > FerredDB, Minio, APISIX and Ollama, providing support for back-end and > > > front-end, with a rich CLI, including development tools and IDE > support, > > > tested on all the leading cloud kubernetes (EKS,AKS,GKE) and Linux > > > distributions (OpenShift, MicroK8S, K3S). > > > > > > Here is the proposal: > > > > > > https://cwiki.apache.org/confluence/display/INCUBATOR/OpenServerlessProposal > > > > > > I would be the Champion of the project. I will mentor and help the > > project > > > through the incubator with Bertrand Delacratez [bdelacra...@apache.org > ] > > and > > > Enrico Olivelli [eolive...@apache.org] > > > > > > We are open to hearing the feedback from the incubator. > > > > > > [1] https://nuvolaris.github.io > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > >
Re: What is sufficient Incubation notification for Git repos?
OK. My major intention is to sync the discussion to the list. If "lazy consensus" is too eager to use, I'm OK to make it clear that it's still encouraged for everyone on the list to give more inputs :D Best, tison. sebb 于2024年5月25日周六 16:26写道: > On Sat, 25 May 2024 at 09:10, tison wrote: > > > > A lazy consensus is met at [1]. > > Sorry, but I don't think it is correct to to use that designation here. > > I don't think the discussion has been open long enough to say that > consensus has been achieved, nor was there an explicit call for > opinions. > All one can say is that no objections have yet been raised so far. > > > I support Justin's opinion that "we were > > not too prescriptive on the exact wording". But this patch can be used > as a > > reference for a good starting point for other podlings. > > I agree it is a good starting point. But given how many places would > have to be updated if there are any subsequent objections, I think it > would be good to get some more opinions. > > > [1] > > > https://github.com/apache/incubator-horaedb/pull/1535#issuecomment-2130634831 > > > > Best, > > tison. > > > > > > tison 于2024年5月24日周五 13:16写道: > > > > > A concrete proposal for the HoraeDB situation: > > > https://github.com/apache/incubator-horaedb/pull/1535 > > > > > > Best, > > > tison. > > > > > > > > > tison 于2024年5月24日周五 08:03写道: > > > > > >> 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 > > >>> > > >>> > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: What is sufficient Incubation notification for Git repos?
A lazy consensus is met at [1]. I support Justin's opinion that "we were not too prescriptive on the exact wording". But this patch can be used as a reference for a good starting point for other podlings. [1] https://github.com/apache/incubator-horaedb/pull/1535#issuecomment-2130634831 Best, tison. tison 于2024年5月24日周五 13:16写道: > A concrete proposal for the HoraeDB situation: > https://github.com/apache/incubator-horaedb/pull/1535 > > Best, > tison. > > > tison 于2024年5月24日周五 08:03写道: > >> 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: [VOTE] Release Apache Answer(Incubating) v1.3.1-RC2 (Round2)
Carry my +1 binding vote from dev list. Best, tison. Suyan 于2024年5月24日周五 22:20写道: > +1 binding from suyanhanx > > I checked: > [x] Download links are valid. > [x] Checksums and PGP signatures are valid. > [x] Source code distributions have correct names matching the current > release. > [x] All files have license headers if necessary. > [x] Can build on macOS(arm64) > > nit: You guys didn't add anything about how to build in the vote > email. I checked your documentation and there is no mention of this > either. > There is a small section in the README, but it isn't friendly enough > for newcomers to the community. > It would be better to make some improvements to this part, not only > for verification but also for the community. > > Sincerely, > Suyan > > Shuailing LI 于2024年5月20日周一 09:41写道: > > > > Hello, > > > > This is a call for vote to release Apache Answer(Incubating) version > > v1.3.1-RC2. > > > > The vote thread: > > https://lists.apache.org/thread/z8k2h7320cz1slx2qt4bfxtf2xj6w39s > > > > Vote Result: > > https://lists.apache.org/thread/w9bgvpowxf30h4w1p3w2h2qyqfw089s8 > > > > The release candidates: > > > https://dist.apache.org/repos/dist/dev/incubator/answer/1.3.1-incubating-RC2/ > > > > Release notes: > > https://github.com/apache/incubator-answer/releases/tag/v1.3.1-RC2 > > > > Git tag for the release: > > https://github.com/apache/incubator-answer/releases/tag/v1.3.1-RC2 > > > > Git commit id for the release: > > > https://github.com/apache/incubator-answer/commit/3a375881b845a529e89dab31da48c822b524d261 > > > > Keys to verify the Release Candidate: > > The artifacts signed with PGP key [4C21E346], corresponding to [ > > sh...@apache.org], that can be found in keys file: > > https://downloads.apache.org/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. > > > > > > Thanks, > > shuai > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: What is sufficient Incubation notification for Git repos?
A concrete proposal for the HoraeDB situation: https://github.com/apache/incubator-horaedb/pull/1535 Best, tison. tison 于2024年5月24日周五 08:03写道: > 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: 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. > > > > &
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=&q=incubator-&sort=&type=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 > &g
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=&q=incubator-&sort=&type=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 a
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&type=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 >
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&type=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&type=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). > &
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 i
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
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=&q=incubator-&sort=&type=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: > > > > > > > > > > &
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&type=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. >> > > > > > >> > > &
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/d
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=&q=incubator-&sort=&type=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 m
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 &g
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. Podli
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
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 > > > > > > > > R
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