[jira] [Commented] (COMDEV-451) Apache APISIX: Java Plugin Runner Improvement
[
https://issues.apache.org/jira/browse/COMDEV-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499906#comment-17499906
]
Bobur Umurzokov commented on COMDEV-451:
[~solomax] Could we add this project to the list, please?
> Apache APISIX: Java Plugin Runner Improvement
> -
>
> Key: COMDEV-451
> URL: https://issues.apache.org/jira/browse/COMDEV-451
> Project: Community Development
> Issue Type: New Feature
> Components: GSoC/Mentoring ideas
>Reporter: Bobur Umurzokov
>Priority: Major
> Labels: APISIX, full-time, gsoc2022
>
> *Background:*
>
> At the moment, the Java runner plugin requires you to use an existing
> template project and change it according to one’s needs.
> *Task:*
> Improve developer experience on the existing Java plugin runner so that we
> can attract and increase the number of users from the Java community.
> *Limitations:*
> * The architecture doesn’t manage multiple plugins. All need to be set in
> the same project
> * The standard Java unit of deployment is the JAR.
> * The plugin doesn’t allow for other widespread JVM-based languages
> ({_}e.g.{_}, Scala, Kotlin, Clojure, Groovy). Though it would be technically
> feasible, we would need to change the template’s language
> *Requirements:*
> The new plugin runner:
> * MUST use the JAR as the unit of deployment
> * MUST not require the usage of a project template
> * MAY require the plugin to follow a certain class hierarchy ({_}i.e.{_},
> extends JavaPlugin)
> * MAY use a more specific format to enforce a structure
> * MUST allow multiple plugins to be deployed
> * MUST use isolated classloader for each plugin
> * MUST allow any JVM-compatible bytecode to run, whatever the language it
> was generated from
> * MAY allow hot reloading of Java plugins
> * MAY require a single JAR per plugin (to ease the classpath management of
> shared libraries)
> * MUST define a minimum JVM version
>
> *Difficulty:* Normal
> *Project size:* ~350 hours.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
Re: Thoughts on alternative communication channels for our communities
On 2022-03-01 at 14:58:03 UTC-0500 (Tue, 1 Mar 2022 14:58:03 -0500) Rich Bowen is rumored to have said: On 2/28/22 17:00, Tomasz Urbaszek wrote: This is just idea but Github is common to every project. It's something we all have, so why not start there? Nope. Github is *not* common to every project. And moreover, requiring a Github account to participate (fully participate) in an Apache project is *not* something that I feel comfortable endorsing. +1 I would actively oppose anything at the foundation level that requires contributors to have *any* account with *any* specific 3rd party for full participation. It's not just about GitHub/Microsoft, it's about the concept of dependency. -- Bill Cole - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Thoughts on alternative communication channels for our communities
Le mar. 1 mars 2022 à 20:12, Mark Thomas a écrit : > ...Why re-invert the wheel? > > https://matrix.org/ ... Would we need to run our own Matrix servers if we want to make it an alternative for our projects? Using https://matrix.org/docs/projects/server/synapse ? (which is written in Python - good thing for us as that's ASF infra's default language) -Bertrand - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Thoughts on alternative communication channels for our communities
On 2/28/22 17:00, Tomasz Urbaszek wrote: This is just idea but Github is common to every project. It's something we all have, so why not start there? Nope. Github is *not* common to every project. And moreover, requiring a Github account to participate (fully participate) in an Apache project is *not* something that I feel comfortable endorsing. - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Thoughts on alternative communication channels for our communities
On 01/03/2022 19:02, Dave Fisher wrote: I want to go back to here with an idea. On Feb 18, 2022, at 5:38 AM, Bertrand Delacretaz wrote: -Project channels must be public, async, archived on ASF-owned services and searchable -Project channels must be usable with open source clients (hmmm..Slack?) -All decisions and votes must be documented on the project's mailing list, with links to the original discussion. Pony Mail is a convenient way to review any mailing list. What if we require that any alternative like Slack or anything be able to produce either an email or an mbox and become a “pseudo mailing list"? If this is so then I think that given a Slack api it would possible to make use of some combination of Apache products to create the connector. - Apache Pulsar could stream and has connectors. - Apache POI has MBox capability. - Apache James has mail capability. I wonder if this is work that could be done in the Pony Mail podling. Why re-invert the wheel? https://matrix.org/ Mark - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Thoughts on alternative communication channels for our communities
I want to go back to here with an idea. > On Feb 18, 2022, at 5:38 AM, Bertrand Delacretaz > wrote: > > -Project channels must be public, async, archived on ASF-owned > services and searchable > -Project channels must be usable with open source clients (hmmm..Slack?) > -All decisions and votes must be documented on the project's mailing > list, with links to the original discussion. Pony Mail is a convenient way to review any mailing list. What if we require that any alternative like Slack or anything be able to produce either an email or an mbox and become a “pseudo mailing list"? If this is so then I think that given a Slack api it would possible to make use of some combination of Apache products to create the connector. - Apache Pulsar could stream and has connectors. - Apache POI has MBox capability. - Apache James has mail capability. I wonder if this is work that could be done in the Pony Mail podling. All the Best, Dave
Re: Thoughts on alternative communication channels for our communities
Le lun. 28 févr. 2022 à 23:01, Tomasz Urbaszek a écrit : > > I'm reading this discussion from the beginning (thanks to ML). I can be > mistaken but there are two issues: > > 1. A community communication channel. A place where users can interact, > discuss and seek help. This should be a place for users and the community > should use whatever serves best. > 2. Decision making channel. In this case we seek for an ability to archive > and search (dev@ mailing list) but we also seek engagement from wider > community (not offered by dev@ list). So IIUC, we already have everything (because I don't agree with the "not offered by list" statement). :-} People can chat informally (towards achieving any set task) anywhere. But decisions must be put to discussion and made on the appropriate mailing list (which can then be mirrored to other channels), if only to assume "lazy" consensus. > > In case of 1 we have poor chance to unify things (for example Slack vs > WeChat). And that might be why the "old" ML is still there. New tools come... and go. > In case of 2 we can take advantage of the fact that every project > now is on Github. For example what Apache Superset is doing looks > impressive: https://github.com/apache/superset/projects/7 They still do the > voting on mailing list > https://lists.apache.org/thread/t2yc69rm60o7mlrp114r9rmdm96k7cwg but we may > consider using some bots for handling this integration (possibly in both > directions). > > Issues and discussions can be deleted. In this case we can consider using > pull requests that support the same (or at least similar) threading > functionality as issues/discussions. We have nice tool for tracking > changes, reviewing and suggesting. This is more similar to what Kubernetes > is doing for theirs "enchantment proposals": > https://github.com/kubernetes/enhancements/pull/1353. I'm not sure what that conversation is meant to illustrate; IMHO it's full of visual noise without any significant advantage over a discussion thread on a ML (that can contain URLs). [Of course it's fine for GH users to use GH tools in order to work on GH repositories (as per your point 1 above).] > > This is just idea but Github is common to every project. It's something we > all have, so why not start there? Because, IMO, a GH account should not be a requirement in order to work on an ASF project. Until the ASF decides that it stops supporting non-GH contributors, a certain confusion is entertained by assuming that everyone is, or should be, there. > In fact maybe we can take some lessons from "newer" communities like CNCF > projects that are no longer ML centric? I see that they still use them: https://lists.cncf.io/g/main/subgroups [I didn't dig further to check whether the various communication channels are integrated. Again: If integration (with the MLs) would work at the ASF, I'd be fine: My issue is with shutting ML-people out.] Best regards, Gilles >>> [...] - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
[jira] [Created] (COMDEV-453) [SkyWalking] Log outlier detection
Zhenxu Ke created COMDEV-453: Summary: [SkyWalking] Log outlier detection Key: COMDEV-453 URL: https://issues.apache.org/jira/browse/COMDEV-453 Project: Community Development Issue Type: Task Components: GSoC/Mentoring ideas Reporter: Zhenxu Ke Currently Apache SkyWalking can collect logs from various sources like user agents and Envoy access logs, it also provides a log analysis language to analyze the logs and produce some metrics, with those metrics, users can configure rules to trigger alerts and react to those abnormal/exceptional logs. But in reality, production environment exceptional logs are not known in advance and users can't enumerate all possible exceptional logs. This task aims to add an algorithm that can identify outlier log(s) from the massive logs, and draw the users attention to see whether there is error in the system. The algorithm should be able to learn from bot the history logs and streaming logs, and adjust itself to increase the accuracy. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Effective ways of getting individuals funded to work on ASF projects
On Tue, Mar 1, 2022 at 9:42 AM Bertrand Delacretaz wrote: > I think for (3) we're good, the ASF will intervene if projects are not ok. > > But for (1) and (2) I think the ASF *wants* our projects to be good > citizens, and we work towards that and support them, but entities such > as Tidelift or others could add value by measuring and reporting what > actually happens. > Feel free. All the data is available for ASF. Everything we do is public. > > But I think having external entities provide factual data on how well > our projects are doing can be useful, and for customers of Tidelift > and the like that certainly has value. > Sure. Please. Do. Measure. Publish. By all means. No problem with that. > Whatever mechanism our contributors use to finance themselves, having > information on which projects are most worthy of trust can help end > users select and finance the right projects and people. > Of course. Feel Free to provide objective data on it. Publishing information about how well projects are doing is great way to incentivise the committers to do better. I am 150% for it. This could be a great service to all OSS projects. But the Tidelift model is talking about "limiting" the individuals in the choices they made NOT measuring what they do. For multiple reasons those individuals in those projects might make different decisions (and be responsible for it). Imposing rules and limits by Tidelift is just against the rules of ASF. Measuring is not. If Tidelift adjusts the model to just measure, report and make the customers decide based on that - I think that is far more consistent with the way how ASF works. Don't try to make yourself a "policeman" controlling it. > > -Bertrand > > - > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
RE: Effective ways of getting individuals funded to work on ASF projects
Hi all, As I was confronted with the question of how commercial support or paid feature development and Apache would work together. I came up with this way of handling it: If I am offering any form of commercial support or feature development I say: "I will fix your problem. The fix then can become part of the open-source project, but if the project decides to decline It, I'll make it available to you in a fork that I create for you." This should work for Tidelift or any similar form of platform too. Chris -Original Message- From: Jim Jagielski Sent: Montag, 28. Februar 2022 19:24 To: dev@community.apache.org Subject: Re: Effective ways of getting individuals funded to work on ASF projects Tidelift's model, which expects that maintainers do have direct and almost unassailable control over a project, is not compatible with the Apache Way. Tidelift's model works well with projects in which developers and maintainers can "do stuff" without worrying about building a consensus around whether or not their contributions are OK or not. I'd like to see how that model and Apache could fit together, but I'm at a loss to think about how. The main benefit that those who fund the work is not just an expectation that code will be fixed, etc, but a *requirement* that it be done. They are paying for the guarantee. This requires a development model in which those paid by Tidelift can forcibly introduce code and contributions at will. This conflicts with the ASF development model. > On Feb 28, 2022, at 12:50 PM, Jarek Potiuk wrote: > >> So while I agree with everything Bertrand said I don’t think it >> resolves > the real issue. > TideLift is providing a guarantee to its customers that projects it > sponsors meet certain standards. The standards they are looking for > should really be set by the ASF, not individual projects. > > This is the part I do not understand. What Tidelift can promise to > their customers and on what basis? > According to ASF rules where only individuals in the project can make > decisions - this means that Tidelift has no mechanisms whatsoever to > fulfill their promise. > > And if ASF sets the standards - why do we need Tidelift at all ? > To be perfectly blunt - I am afraid that until Tidelift resolves any > of the real problems of individual committers we mentioned with > Bertrand (including facilitating direct relationship commiter <> > stakeholder), I do not see what's the added value of Tidelift. Seems > like unnecessary intermediary. > > J. > > > On Mon, Feb 28, 2022 at 5:10 PM Ralph Goers > > wrote: > >> First, I would like to clarify Gary’s email as I don’t think he >> characterized it quite correctly. >> The Logging PMC concluded we could not be part of an arrangement with >> TideLift and that the issues needed to be worked out at the >> foundation level. The primary issue was that TideLift had >> requirements on advertising and process details that required >> approval of the PMC in order for individuals to be able to be paid. >> We met with a Google security team in January and had similar issues >> where they required a process that isn’t aligned with the ASF’s >> requirements on how releases are to be performed. >> >> Second, from my point of view the ASF should have discussions with >> TideLift and Google to see if those issues can be resolved. The ideal >> scenario would be that TideLift and Google can simply sponsor >> individuals from any ASF project because all ASF projects must >> conform to guidelines that meet their criteria - i.e. the PMC doesn’t >> even have to be involved. But this obviously requires that the >> foundation work with these third parties to either improve our >> processes where needed or get the third party to accept our >> processes. >> >> So while I agree with everything Bertrand said I don’t think it >> resolves the real issue. >> TideLift is providing a guarantee to its customers that projects it >> sponsors meet certain standards. The standards they are looking for >> should really be set by the ASF, not individual projects. >> >> Ralph >> >> >>> On Feb 28, 2022, at 5:03 AM, Bertrand Delacretaz >>> >> wrote: >>> >>> Hi, >>> >>> Le lun. 28 févr. 2022 à 11:06, Jarek Potiuk a écrit : ...the relationships I have is direct relationship with the stakeholders. Let's deel, GitHub Sponsors, SAP Ariba are merely >> "removing bureaucratic obstacles" but they are not "between" me and my >> stakeholders. They are "on a side". They get a small cut sometimes (which I gladly >> pay) but I want to talk to the stakeholders directly without any >> intermediaries and establish a long-term relationship with them as an individual >>> >>> I think that's a key point, and listing such requirements for >>> platforms that can help our contributors get funding sounds useful. >>> >>> Here's a quick list of initial requirements that we might include: >>> -Contri
Re: Effective ways of getting individuals funded to work on ASF projects
Hi, Le lun. 28 févr. 2022 à 21:15, Jarek Potiuk a écrit : > ...Proposal: > I think we all agree that ASF meets the criteria of Tidelift already. > Why don't Tidelift (in the places where open-source projects included are > listed) explain that ASF projects meet the criteria, and any one is free > to deal directly with the committers of all ASF projects directly... I'd say we all agree that *in theory* ASF projects meet Tidelift's criteria, quoting from earlier in this thread, with my own numbering added: Le lun. 28 févr. 2022 à 19:30, Joshua Simmons a écrit : > ...*What Tidelift expects from maintainers*Maintainers provide two things to > our customers: (1) information (licensing details, context on CVEs) and > (2) continuity (comfort that the package is maintained and is highly likely to > continue to be maintained). We also expect maintainers (3) to abide by a Code > of Conduct I think for (3) we're good, the ASF will intervene if projects are not ok. But for (1) and (2) I think the ASF *wants* our projects to be good citizens, and we work towards that and support them, but entities such as Tidelift or others could add value by measuring and reporting what actually happens. Does Apache FOO actually provide good information on security issues and CVEs? Timely response? What's their average/min/max response time, how many "in-flight" CVEs? Does Apache FOO release often enough? Maybe based on project maturity categories, new, established, mostly dormant etc. We could of course measure these things ourselves, and we do have some data. But I think having external entities provide factual data on how well our projects are doing can be useful, and for customers of Tidelift and the like that certainly has value. Whatever mechanism our contributors use to finance themselves, having information on which projects are most worthy of trust can help end users select and finance the right projects and people. -Bertrand - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
