Re: [DISCUSS] Proposal to Start Development of a New Java Library in Apache Incubator
Thanks for the detailed proposal. Generally, the Apache Incubator takes existing projects with a pre-existing community. We emphasise community over code so it may be feasible to start a new project if you have a community. Do you have a list of people who would be willing to collaborate on this? The existing Incubator contributor pool, generally, doesn't act as a pool of people who jump onto new projects. There is the concept of a mentor who helps new projects to get up and running - more from an admin and setup perspective. On 2025/03/14 06:26:50 Imre Tabur wrote: > Dear Apache Incubator Community, > > I would like to start a discussion about an idea to start the > development of a new Java library, designed to simplify > the implementation and setup of custom communication protocols, > particularly for networked environments and device > interactions (e.g., serial ports, proprietary network protocols). > > A library for building and setting up I/O (read/write, send/receive) > protocols. Custom, non-standard, > proprietary, domain-, and vendor-specific protocol implementations, > while remaining loosely coupled from the data > structures (message data structures) being transferred. > > ## Background: Why is this Needed? > > In many projects, developers must work with proprietary or > vendor-specific communication I/O protocols that are not > based on widely supported implementations like HTTP (REST, GraphQL, > etc.) for which libraries exist. And the protocol > needs to be implemented by developers themselves. Shortly: no libraries > to take. > > ### Use cases > > * Integrating with (legacy) serial port devices in industrial systems. > * Implementing vendor-specific communication for IoT gateways or edge > devices. > * Interacting with specialized network or hardware devices in > telecommunications or data centers. > * Developing custom communication protocols for specific use cases, > between devices and systems. > > Such protocols often require developers to implement custom solutions > from scratch, following detailed technical > documentation or specifications provided by the (protocol) vendor. > > The problem is that doing it yourself is labor-intensive, requires > precision, and is tedious work. The larger the > specification, the greater the struggle with implementation. It is also > quite difficult to recall and follow what was > done later on. Additionally, there is little reusable code, and > identifying parts of the code that can be reused is also > difficult. > > This project aims to address these issues by providing a reusable > library that simplifies working with such > vendor-specific protocols, reducing development time and ensuring > consistency across implementations. > > # Proposed Solution: A Graph-Based Approach to Protocols > > The proposed library simplifies the development of custom client-server > (sender-receiver and vice versa) communication > protocols by representing them as execution graphs. > > In this model: > > * Nodes in the graph represent protocol steps - reading or writing data > (receive or send). > * Edges define the flow of execution between steps, governed by > configurable rules and conditions. > > The library provides functionality to build and execute graphs, handle > basic I/O operations (and potentially more), > bind data structures to steps (or with the whole defined graph) to carry > over protocol, handle events, and manage a > callback system. > > **I assume that a graph, even when implemented in (fluent) code, is more > readable (repairable/improvable) than a fully > custom implementation.** > > By abstracting protocol logic into an execution graph, the library > minimizes the complexity of handling vendor-specific > communication requirements and promotes easier maintenance. > > The MVP implementation of the library will focus exclusively on Java to > validate the concept and gather community > feedback before considering broader adoption or porting to other > languages like C++ or other. > > # Summary > > To summarize, this project aims to simplify the implementation of > non-standard protocols by providing a graph-based > framework that can handle basic I/O operations on its own through a > defined graph. Most of the basic I/O functions are > handled within the library, compared to a custom-made solution where > everything is cross-referenced and tightly coupled. > > The initial focus will be on Java, with the potential for future > expansion based on community input. > > The initial base structure, skeleton, and proof of concept (PoC) will be > independently developed by me and my team as a > preliminary effort in our own repository, serving as an example for > further development and eventual transition into the > Apache Incubator. > > # Feedback Request > > The idea is still quite abstract, but I would greatly appreciate your > feedback: > > - Do you see value in such a project? > - Do
Re: [VOTE] Release Apache Seata (Incubating) 2.1.0-RC5
Agreed - can you cancel this vote and start a new one with the correct subject and KEYS link? On 2025/03/06 16:34:07 Min Ji wrote: > Hi, > > The email subject looks a bit off – it doesn't match what's written in the > body. > > Warm regards, > > Ji Min > > luky116 于2025年3月7日周五 00:05写道： > > > > > > > > Hello, > > > > This is the first release of Apache Seata-go(incubating) SDK. > > > > > > The vote thread: > > https://lists.apache.org/thread/6yym26plkrf4ld6s0bf9zts5wwwg0gtq > > > > > > Vote Result: > > https://lists.apache.org/thread/ko9hf9t9wp14wzgoxcks5cyglg68jrpb > > > > > > The release candidates: > > https://dist.apache.org/repos/dist/dev/incubator/seata/incubator-seata-go/2.0.0-RC1/ > > > > > > Git tag for the release: > > https://github.com/apache/incubator-seata-go/tree/v2.0.0 > > > > > > Git commit id for the release: > > https://github.com/apache/incubator-seata-go/commit/cf2212a41550649b5b32dc029a608d3746f5de3a > > > > > > Release Notes: > > https://github.com/apache/incubator-seata-go/releases/tag/v2.0.0 > > > > > > The artifacts have been signed with Key [ A2EF5873 ], corresponding to > > [ luky...@apache.org ] > > which can be found in the keys file: > > https://downloads.apache.org/incubator/seata/KEYS > > > > > > Build Environment: Golang 1.20+. > > Build Command: make build. > > > > > > CI Test Workflow: > > https://github.com/apache/incubator-seata-go/actions/runs/12517972078/job/34919641932 > > https://github.com/apache/incubator-seata-go/actions/runs/12517972075/job/34919641931 > > > > > > The vote will be open for at least 72 hours. > > > > > > Please vote accordingly: > > [ ] +1 approve > > [ ] +0 no opinion > > [ ] -1 disapprove with the reason > > > > > > 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 > > > > > > To learn more about Apache Seata , please see https://seata.apache.org/ > > Warm regards, > > Yuecai Liu > > - > > 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: podling security issues
Related, should we ask the podling if all PPMC members (and only PPMC members or invited outsiders) are subscribed to the private mail list? Craig > On Mar 6, 2025, at 07:02, PJ Fanning wrote: > > As a concrete proposal, can I suggest adding a question to the podling report. > > Something like: > Is the podling PPMC being responsive to email threads on the private mailing > list (don't discuss specific instances here because the threads are private)? > > I know this is a long winded question that really only expects a yes/no > answer or something like: > The PPMC has become less responsive recently. I will reach out to PPMC > members to see if they can devote some more time to the private threads. > > The idea of the question is to act as a reminder of the importance of the > private email threads. > > It would also be good if the shepherds also check the private threads when > reviewing podling reports and report if they think there is a responsiveness > issue. > > > On 2025/01/26 07:42:16 Jean-Baptiste Onofré wrote: >> Hi >> >> This is a good proposal. As part of the new reporting tool for >> project, it's a security section is part of the report. >> >> So, it makes sense to have it for podlings. >> >> Regards >> JB >> >> On Fri, Jan 24, 2025 at 2:35 PM PJ Fanning wrote: >>> >>> Hi everyone, >>> >>> I didn't follow up on this when I raised it in December 2023. I'd like >>> to propose it again. >>> Basically, the idea is that the podling reports, that we do every 3 >>> months, would have a question about whether the podling believes that >>> they are being sufficiently responsive to issues raised on their >>> private mailing list (particularly security issues). There would maybe >>> also be a reminder about the ASF policies related to dealing with >>> disclosures about vulnerabilities [1]. >>> I would also like to see a section about this in the Graduation Report >>> - having podlings declare that they have been and intend to continue >>> to be responsive to disclosures about vulnerabilities. This is covered >>> by QU30 in the Project Maturity Model [2] but I wonder if the text >>> could be adjusted to also mention the need to be responsive to >>> vulnerability reports. >>> With efforts like the CRA [3] and other regulatory requirements around >>> the world, this area is becoming even more important. >>> >>> What do people think? >>> >>> Thanks, >>> PJ >>> >>> [1] https://www.apache.org/security/ >>> [2] >>> https://community.apache.org/apache-way/apache-project-maturity-model.html#quality >>> [3] https://en.wikipedia.org/wiki/Cyber_Resilience_Act >>> >>> On Wed, 13 Dec 2023 at 16:21, Craig Russell wrote: Hi PJ, I agree that there should be a section in podlings' reports that highlights security issues. Regards, Craig > On Dec 13, 2023, at 05:22, PJ Fanning wrote: > > Hi everyone, > > I'm wondering if podlings should include some details about their > security issues [1] in their 3 podling reports. We won't want to > release information about any security issues that are still under > investigation or where the fix is not yet released. I still think > there is little harm in podlings giving high level numbers and maybe > some indication of how quickly security issues are being dealt with. > > I've seen evidence that some TLPs are unaware of the importance of > dealing quickly with security reports and I think the Incubator team > could help with ensuring that podlings are aware of the requirements. > > I will certainly be having a close look at a podling's record of > handling security reports when it comes to discussions about > graduation. > > I'm wondering if we could have some consensus on what is expected of > podlings. > > Regards, > PJ > > [1] https://www.apache.org/security/ > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > 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 >>> >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> > > - > To unsubsc
Re: [VOTE] Release Apache OzHera (incubating) 2.2.5-incubating-rc5
First of all, thank you for your review and reply. Yes, as you mentioned, some of the dependent jar packages come from Xiaomi's run.mone library. These jars from run.mone are all licensed under Apache 2.0, so there is no problem with the license. Some of the github URLs in the license do not work because the directory of the code has been adjusted, but the jar package still uses the directory before the adjustment, so the URL still points to the previous directory. All the codes can be found under https://github.com/XiaoMi/mone. We will revise this issue before the new version is released. In addition, we have noticed the problem of outdated dependencies during the release process, and we have started the process of dealing with it (https://lists.apache.org/thread/rol5kmf3ks03wm978tz39xz48bg0zlnc). Because there are many modifications involved, we plan to upgrade and correct the relevant content after this version is released and before the next version is released. As for the version inconsistency problem, we currently use version management to force the use of specified versions. Currently, all dependencies will only have one version, and there will be no version conflict. We will also correct the version consistency problem of the pom file before the next version is released. Thanks Best Regards, Xihui Gao On 2025/03/07 00:45:28 PJ Fanning wrote: > +0 binding > > Source release seems ok. > > I still have issues with the binary artifact > (apache-ozhera-2.2.5-incubating-bin.tar.gz). > > Its license lists lots of run.mone libs that appear to be from Xiaomi but the > github URLs in the license don't work. > > I want to report issues on these libs because some of they use dangerously > out of date dependencies and there are some issues in their pom files with > inconsistent versions. > > I think I have tracked down some of the code in > https://github.com/XiaoMi/mone. > > > On 2025/03/05 11:13:21 石榴树 wrote: > > Hello Incubator Community, > > > > > > We are calling for votes to release Apache OzHera (Incubating) version > > 2.2.5-incubating release candidate rc5. > > > > > > Apache OzHera(Incubating) is an Application Performance Monitoring (APM) > > platform designed for the cloud-native era. It revolves around applications > > and integrates capabilities such as metric monitoring, distributed tracing, > > logging, and alerting. > > > > > > The Apache OzHera(Incubating) community has voted and approved the > > release of Apache OzHera (Incubating) 2.2.5-incubating-rc5. > > > > > > We cordially invite Incubator PMC members to review and vote for this > > release. > > > > > > Apache OzHera(Incubating) community voting thread: > > https://lists.apache.org/thread/tjmg9cfpxxng7odlb6vsp2sl7zb8jtjr > > > > > > Voting results thread: > > https://lists.apache.org/thread/bhf8vtqzgyxs6ytrs9zy0h3f2jyj7pb4 > > > > > > The release candidates: > > https://dist.apache.org/repos/dist/dev/incubator/ozhera/2.2.5-incubating-rc5/ > > > > > > Git tag for the release: > > https://github.com/apache/ozhera/releases/tag/v2.2.5-incubating-rc5 > > > > > > > > > > gpg KEYS file here: > > https://downloads.apache.org/incubator/ozhera/KEYS > > gpg uid please select:gaoxihui > > > > > > > > > Please download, verify, and test. > > > > > > Friendly reminder: When you build the project, please ignore the tests, > > like this: > > mvn clean install -Papache-release -Dmaven.test.skip=true > > > > > > Voting will be open for at least 72 hours or until the required number of > > votes is reached. Please vote as follows: > > [ ] +1 for approval > > [ ] +0 for no opinion > > [ ] -1 for objection with reason > > > > Thanks, > > On behalf of Apache OzHera (Incubating) community > > - > 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] Texera proposal
Hi everyone, The Texera proposal document is ready for review. https://cwiki.apache.org/confluence/display/INCUBATOR/TexeraProposal It would be useful if we could get another 1 or 2 mentors, if anyone has the time to help out. Please respond to this thread with your thoughts on the Texera proposal. Regards, PJ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
