Let's ignore the last sentence I mentioned. I mentioned my suspicion
because I have concerns about the lifetime of this repo. It's
clarified privately so I'm apologizing for my conjecture about the
company. So let's focus on the topic itself.

Even without the concern about the lifetime, this repo still does not
make sense to me so it's still -1.

Thanks,
Yunze

On Mon, Aug 5, 2024 at 9:05 PM Yunze Xu <x...@apache.org> wrote:
>
> I just thought again about the "best practice" part. Why not
> contribute it to the Apache official website
> (https://github.com/apache/pulsar-site)?
>
> Thanks,
> Yunze
>
> On Mon, Aug 5, 2024 at 8:46 PM Yunze Xu <x...@apache.org> wrote:
> >
> > TL;DR, such a repository is not necessary to be contributed to Apache.
> >
> > Actually, only the "Collect user best practices" point makes sense to
> > me. The reason to have so many pluggables is exactly to avoid the core
> > repo being not so bloated.
> >
> > Yeah, OTel is a good example. But IMHO, Pulsar is far less populated
> > than OTel. In the current phase, it's more important to improve the
> > code quality of such plugins, including
> > - Metadata store. From my personal perspective, I don't suggest making
> > InMemory, Etcd, Oxia as the built-in implementations. Having ZK as
> > default and RocksDB for a lightweight standalone is enough.
> > - Load Manager. If you have the demand to implement a customized load
> > manager (like me), you will understand it. The extensible load manager
> > introduced from PIP-192 makes things better. But it's still a mess.
> > See how many `isLoadManagerExtensionEnabled` calls in the repo.
> > - Schema Registry. It's not pluggable yet. But I've heard many users
> > want a more powerful implementation.
> >
> > These three typical plugins above are really not pluggable enough.
> > Before adding them to such a repository, it's more worth taking some
> > time to revisit the implementation and make them better. Just like the
> > producer and consumer interceptors, if some implementations are
> > general enough, we should accept them in the core repo or create
> > another repo for them.
> >
> > Besides, these pluggables provide a way for companies to implement its
> > own private plugins as the sell points. For example, I really don't
> > think my employer will be glad to contribute ideas of our internal
> > plugins to this repo.
> >
> > So. It's -1 for me. But I think it's good to incubate this repo for
> > some time and see if there are many people willing to contribute,
> > rather than the XHS team itself.
> >
> > BTW, I'm also curious about the position of Pulsar in XHS since I see
> > your company is adopting AutoMQ recently. I'm suspicious that
> > contributing such a repo into Apache is a KPI in the internal
> > competition.
> >
> > Thanks,
> > Yunze
> >
> > On Sat, Aug 3, 2024 at 5:37 PM xiangying meng <xiangy...@apache.org> wrote:
> > >
> > > Dear all,
> > >
> > > I would like to express my appreciation to all of you who have shown
> > > support for my recent proposal. Your feedback and encouragement are
> > > greatly appreciated and have been instrumental in moving the
> > > discussion forward.
> > >
> > > I am pleased to announce that I have initiated a vote on this
> > > proposal. You can find the details and participate in the voting
> > > through the following link:
> > >
> > > https://lists.apache.org/thread/td0j8l1c3l93nny0m5smnsdmb91j1n2y
> > >
> > > Your active participation is crucial for the success of this
> > > initiative, and I look forward to a positive outcome.
> > >
> > > Once again, thank you for your valuable input and support.
> > >
> > > Best regards,
> > > Xiangying
> > >
> > > On Sat, Aug 3, 2024 at 3:38 AM Dave Fisher <w...@apache.org> wrote:
> > > >
> > > > Hi - I renamed the PIP PR to include the PIP number - PIP-367. - 
> > > > https://github.com/apache/pulsar/pull/23061
> > > >
> > > > I think that you have covered concerns and it is time to start a 
> > > > separate VOTE thread.
> > > >
> > > > Assuming that the PIP passes then we can create the new repository by 
> > > > following your example and adjust the files to best fit policies.
> > > >
> > > > Best Regards,
> > > > Dave
> > > >
> > > > > On Jul 29, 2024, at 7:45 PM, xiangying meng <xiangy...@apache.org> 
> > > > > wrote:
> > > > >
> > > > > Dear Dave and Enrico,
> > > > >
> > > > > Thank you for your reply and valuable comments. I think the point that
> > > > > needs to be clarified now is whether this repository needs to be
> > > > > released. In the original idea, the functions in this repository are
> > > > > not stable. It will be used to collect various experimental functions
> > > > > and extended plug-in implementations.
> > > > > The risk is mentioned in the first version of the proposal. However,
> > > > > due to lack of experience, I failed to clarify the importance of
> > > > > release, so there is no clear release description. Thanks to Dave for
> > > > > helping to further clarify this matter.
> > > > >
> > > > > - For experimental functions and customized functions that require
> > > > > modifying the Pulsar source code, I think they must not be released.
> > > > > - For the plug-in implementation of Pulsar extension, it cannot be
> > > > > promised to users that it is stable, so it cannot be released, too.
> > > > >
> > > > > Therefore, we further clarify the positioning of this repository.
> > > > >
> > > > > - Collect user needs and their various customized plug-in 
> > > > > implementations
> > > > > - Collect and organize various experimental functions and customized 
> > > > > functions
> > > > > - Collect user best practices
> > > > >
> > > > > The admission standard of the warehouse is that this function can work
> > > > > normally and meet the needs, but it is not necessarily stable, so it
> > > > > will not be released.
> > > > >
> > > > > With the continuous feedback from users, this feature may become
> > > > > stable, and eventually someone (new contributor or original
> > > > > contributor) may move this feature to a stable releaseable place. That
> > > > > is, move it to the `appropriate Pulsar repository and component` you
> > > > > mentioned.
> > > > >
> > > > > In addition, regarding the SECURITY.md file, I have added it to the
> > > > > repository. [0]
> > > > >
> > > > > Best Regards
> > > > >
> > > > > xiangying
> > > > >
> > > > > [0] - 
> > > > > https://github.com/StevenLuMT/pulsar-java-contrib/blob/stable/SECURITY.md
> > > > >
> > > > > On Mon, Jul 29, 2024 at 10:50 PM Dave Fisher <w...@apache.org> wrote:
> > > > >>
> > > > >>
> > > > >>
> > > > >>> On Jul 29, 2024, at 6:37 AM, Enrico Olivelli <eolive...@gmail.com> 
> > > > >>> wrote:
> > > > >>>
> > > > >>> Il giorno lun 29 lug 2024 alle ore 11:55 steven lu 
> > > > >>> <lushiji2...@gmail.com>
> > > > >>> ha scritto:
> > > > >>>
> > > > >>>> Different from pulsar-adapters, we added some instructions and 
> > > > >>>> examples
> > > > >>>> here https://github.com/StevenLuMT/pulsar-java-contrib
> > > > >>>
> > > > >>>
> > > > >>> This example is clear, thanks !
> > > > >>
> > > > >> From your README in the repository.
> > > > >>
> > > > >>> Pulsar java contrib is to provide a non-core code maintenance 
> > > > >>> repository to collect plugin implementations, personalized 
> > > > >>> features, experimental features, and best practices from users.
> > > > >>
> > > > >> These are examples which anyone can use at their own risk and the 
> > > > >> PMC does not intend to make RELEASES. Is this correct? If so then 
> > > > >> that should be very clear.
> > > > >>
> > > > >> Anything the community decides to support for the future in a 
> > > > >> release should be moved into the appropriate Pulsar repository and 
> > > > >> component.
> > > > >>
> > > > >> If this were made clear then I would be a +1.
> > > > >>
> > > > >> Security vulnerabilities found would still require care and 
> > > > >> attention from the PMC due to the private nature of this reporting. 
> > > > >> You will need a SECURITY.md file.
> > > > >>
> > > > >> Best,
> > > > >> Dave
> > > > >>
> > > > >>>
> > > > >>> Let's put it this way: +0
> > > > >>> I am not against this proposal, but I would support it if we see 
> > > > >>> that the
> > > > >>> Community and in particular the PMC
> > > > >>> is willing to maintain it.
> > > > >>>
> > > > >>> If the community is not willing to maintain it (and we already have
> > > > >>> problems with pulsar-adapters for instance) then
> > > > >>> it is only like adding another dead repository plus the 
> > > > >>> responsibility to
> > > > >>> fix security issues and keep the examples up to date with the best
> > > > >>> practices as long as Pulsar evolves
> > > > >>>
> > > > >>> If I were you I would start a well curated github repository and 
> > > > >>> encourage
> > > > >>> people to contribute their code snippets to it.
> > > > >>>
> > > > >>> That said, I won't VOTE against the proposal
> > > > >>>
> > > > >>> Thanks
> > > > >>>
> > > > >>> Enrico
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>>
> > > > >>>>
> > > > >>>> Enrico Olivelli <eolive...@gmail.com> 于2024年7月23日周二 17:45写道:
> > > > >>>>
> > > > >>>>> Probably this repository is already what you want to do:
> > > > >>>>> https://github.com/apache/pulsar-adapters
> > > > >>>>>
> > > > >>>>> It contains a lot of different stuff that we don't keep in the 
> > > > >>>>> main
> > > > >>>> pulsar
> > > > >>>>> repository.
> > > > >>>>>
> > > > >>>>> Enrico
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> Il giorno mar 23 lug 2024 alle ore 09:51 Jia Zhai 
> > > > >>>>> <zhai...@apache.org>
> > > > >>>> ha
> > > > >>>>> scritto:
> > > > >>>>>
> > > > >>>>>> Thanks for the proposal. It is a good idea. It is also not a bad 
> > > > >>>>>> idea
> > > > >>>> to
> > > > >>>>>> incubate it outside of Pulsar official repository at first.
> > > > >>>>>>
> > > > >>>>>> On Tue, Jul 23, 2024 at 2:59 PM Aurora Twinkle <
> > > > >>>> foreverlove...@gmail.com
> > > > >>>>>>
> > > > >>>>>> wrote:
> > > > >>>>>>
> > > > >>>>>>> Hi:
> > > > >>>>>>> I think this is a very good idea.
> > > > >>>>>>>
> > > > >>>>>>> In the native pulsar warehouse, there are some interfaces that 
> > > > >>>>>>> have
> > > > >>>> no
> > > > >>>>>>> default implementation classes, such as ConsumerInterceptor,
> > > > >>>>>>> ProducerInterceptor. Users must implement the interface 
> > > > >>>>>>> themselves,
> > > > >>>>>>> which increases the cost of use. If there is a plug-in library
> > > > >>>>>>> mentioned in this PIP, we can provide some common interface
> > > > >>>>>>> implementations in the plug-in library, such as mertics 
> > > > >>>>>>> collection
> > > > >>>>>>> interceptor for producer and consumer.
> > > > >>>>>>>
> > > > >>>>>>> Best Regards,
> > > > >>>>>>> AuroraTwinkle
> > > > >>>>>>>
> > > > >>>>>>> xiangying meng <xiangyingme...@gmail.com> 于2024年7月23日周二 11:25写道:
> > > > >>>>>>>>
> > > > >>>>>>>> Hello Wen Zhi,
> > > > >>>>>>>>
> > > > >>>>>>>> This project is a new repository similar to a connector, and it
> > > > >>>> will
> > > > >>>>>>>> not make any modifications to Pulsar itself. [0]
> > > > >>>>>>>>
> > > > >>>>>>>> Its code part is simply a plugin library, based on Pulsar's
> > > > >>>> external
> > > > >>>>>>>> interfaces, providing a rich set of implementations. It only
> > > > >>>> retains
> > > > >>>>> a
> > > > >>>>>>>> "curated list", which is a series of pointers to personalized
> > > > >>>>> features
> > > > >>>>>>>> and experimental features in personal repositories for 
> > > > >>>>>>>> reference
> > > > >>>> and
> > > > >>>>>>>> inspiration. If these experimental features are recognized by 
> > > > >>>>>>>> other
> > > > >>>>>>>> users, they can also be gradually merged into the Pulsar main
> > > > >>>>>>>> repository. However, it will not fork the content of the Pulsar
> > > > >>>>>>>> repository for modification in the new repository.
> > > > >>>>>>>> This is the improvement we made after discussion in the last
> > > > >>>> email. I
> > > > >>>>>>>> will synchronize it to the proposal later.
> > > > >>>>>>>> Finally, thank you for your valuable suggestions, and we look
> > > > >>>> forward
> > > > >>>>>>>> to your continued participation.
> > > > >>>>>>>>
> > > > >>>>>>>> [0] - https://github.com/apache/pulsar-connectors
> > > > >>>>>>>>
> > > > >>>>>>>> Best Regards,
> > > > >>>>>>>> Xiangying
> > > > >>>>>>>>
> > > > >>>>>>>> On Tue, Jul 23, 2024 at 10:36 AM WenZhi Feng <
> > > > >>>> thetumb...@apache.org>
> > > > >>>>>>> wrote:
> > > > >>>>>>>>>
> > > > >>>>>>>>> Hi, xiangying,
> > > > >>>>>>>>> First of all, thanks for driving the proposal.
> > > > >>>>>>>>> I have some questions.
> > > > >>>>>>>>> 1. Will this repository maintained by committers/pmc? If the
> > > > >>>>> answer
> > > > >>>>>>> is yes, there will be too many new modules introduced into 
> > > > >>>>>>> pulsar and
> > > > >>>>>> hard
> > > > >>>>>>> to maintain. If the answer is no, i think we have better not to
> > > > >>>> include
> > > > >>>>>> it
> > > > >>>>>>> into pulsar official repository.
> > > > >>>>>>>>> 2. For those plugin-in feature, we may create a new repository
> > > > >>>>> like
> > > > >>>>>>> various connectors for pulsar. But for those core code change on
> > > > >>>>> pulsar,
> > > > >>>>>>> how can we seperate it with pulsar repository?
> > > > >>>>>>>>> It is thrilling that users contribute various new features to
> > > > >>>>>> apache
> > > > >>>>>>> community, enriching the ecosystem. I think we should find out 
> > > > >>>>>>> a good
> > > > >>>>> way
> > > > >>>>>>> to realize it.
> > > > >>>>>>>>>
> > > > >>>>>>>>> Thanks,
> > > > >>>>>>>>> Wenzhi Feng.
> > > > >>>>>>>>>
> > > > >>>>>>>>> On 2024/07/22 17:40:24 xiangying meng wrote:
> > > > >>>>>>>>>> Thank you for your feedback, let's further clarify this 
> > > > >>>>>>>>>> matter.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> The original design of this proposal is a new contributor
> > > > >>>>>> repository,
> > > > >>>>>>>>>> and provides two ways to contribute.
> > > > >>>>>>>>>> The first one:
> > > > >>>>>>>>>> Contributors contribute through PR and accept code review, 
> > > > >>>>>>>>>> and
> > > > >>>>> can
> > > > >>>>>>>>>> only be merged into the main branch after reviewed. The code
> > > > >>>>> merged
> > > > >>>>>>> in
> > > > >>>>>>>>>> this way is various plug-ins based on Pulsar's external
> > > > >>>>> interface.
> > > > >>>>>> It
> > > > >>>>>>>>>> does not contain any pulsar code, only Pulsar's dependencies.
> > > > >>>>>>>>>> The second one:
> > > > >>>>>>>>>> Features that require modifications to the Pulsar main
> > > > >>>> repository
> > > > >>>>>>> code
> > > > >>>>>>>>>> and may conflict with later versions. My initial idea was for
> > > > >>>>>>>>>> contributors to create branches and then write the commit id
> > > > >>>> and
> > > > >>>>>>>>>> features description into the document after the PR is
> > > > >>>> reviewed.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> However, after the discussion just now, I agree that the 
> > > > >>>>>>>>>> second
> > > > >>>>> one
> > > > >>>>>>>>>> may not be maintained in the branch of the new repository, 
> > > > >>>>>>>>>> but
> > > > >>>> in
> > > > >>>>>> the
> > > > >>>>>>>>>> contributor's personal repository.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Based on the above content, let's continue to look at the
> > > > >>>>> question
> > > > >>>>>>> you raised.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> - How can the Pulsar community maintain  a fork of Pulsar
> > > > >>>> itself
> > > > >>>>>> ?
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> If it is just  plug-in library and a feature list document of
> > > > >>>> the
> > > > >>>>>>>>>> features in  personal repository, then there is no need to 
> > > > >>>>>>>>>> fork
> > > > >>>>>>> Pulsar
> > > > >>>>>>>>>> itself.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> -  Do you want to "cut releases" out of this fork ? Who is
> > > > >>>> going
> > > > >>>>>> to
> > > > >>>>>>> validate them ? Who is responsible for security bugs?
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> We will only need to maintain a documents of feature and
> > > > >>>> plugins
> > > > >>>>>> list
> > > > >>>>>>>>>> that have been reviewed by PR. We will not make changes to 
> > > > >>>>>>>>>> the
> > > > >>>>>> Pulsar
> > > > >>>>>>>>>> code itself. There is no fork of Pulsar. It will have its own
> > > > >>>>>> version
> > > > >>>>>>>>>> release process, just like Pulsar.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> -> Who is going to use this code ?
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> IMO, providing various implementation plugins based on 
> > > > >>>>>>>>>> Pulsar's
> > > > >>>>>>>>>> external interface is meaningful in itself. While introducing
> > > > >>>>>>> Pulsar's
> > > > >>>>>>>>>> own dependencies, introducing plugin libraries to use various
> > > > >>>>>> already
> > > > >>>>>>>>>> implemented plugins can reduce development costs. I think 
> > > > >>>>>>>>>> some
> > > > >>>>>> people
> > > > >>>>>>>>>> will be happy to use them.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> As for the other functions in the document, maintained in
> > > > >>>>> personal
> > > > >>>>>>>>>> repositories, they can be used as a reference and provided to
> > > > >>>>>>>>>> companies that are capable of solving security issues and 
> > > > >>>>>>>>>> bugs.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Best regards,
> > > > >>>>>>>>>> Xiangying
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> On Tue, Jul 23, 2024 at 12:03 AM Enrico Olivelli <
> > > > >>>>>>> eolive...@gmail.com> wrote:
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Il giorno lun 22 lug 2024 alle ore 17:34 xiangying meng <
> > > > >>>>>>>>>>> xiangyingme...@gmail.com> ha scritto:
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>>> thanks for your proposal, we need more and more energy in
> > > > >>>>> the
> > > > >>>>>>> project.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Yes, it requires a lot of participation, but sometimes we
> > > > >>>>> also
> > > > >>>>>>> need a
> > > > >>>>>>>>>>>> start.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Also we allow only "committers" to commit patches to the
> > > > >>>>>>> repositories
> > > > >>>>>>>>>>>> that are under the responsibility of the Apache Pulsar
> > > > >>>> PMC, I
> > > > >>>>>>> don't know
> > > > >>>>>>>>>>>> how we can make this work with a "official fork"
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>> An alternative is to have a "curated list" of links to
> > > > >>>>>> personal
> > > > >>>>>>> projects,
> > > > >>>>>>>>>>>> but we keep the responsibility over the code on the code
> > > > >>>>> owners
> > > > >>>>>>> and
> > > > >>>>>>>>>>>> not on the Pulsar PMC
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Yes, this is a "curated list" link, but it points to the
> > > > >>>>> branch
> > > > >>>>>>> and
> > > > >>>>>>>>>>>> commit ID created by the contributor himself. In addition,
> > > > >>>>> for
> > > > >>>>>>> some
> > > > >>>>>>>>>>>> interface implementation classes, they can be placed in the
> > > > >>>>>> main
> > > > >>>>>>>>>>>> branch of the new contributor's repository and then added
> > > > >>>> to
> > > > >>>>>> the
> > > > >>>>>>>>>>>> "curated list". Only committors or maintainers can add
> > > > >>>>> content
> > > > >>>>>>> to the
> > > > >>>>>>>>>>>> "curated list". I have detailed these in the proposal.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> But no matter which method, each function will be marked in
> > > > >>>>> the
> > > > >>>>>>>>>>>> document, that is, in the "Featured List" who contributed
> > > > >>>>> it. I
> > > > >>>>>>>>>>>> understand that this feature is more of a reference
> > > > >>>> feature.
> > > > >>>>>>> Allow
> > > > >>>>>>>>>>>> users to choose these customized and risky features to
> > > > >>>>>> customize
> > > > >>>>>>> their
> > > > >>>>>>>>>>>> own versions. This is very useful for some large companies
> > > > >>>>> with
> > > > >>>>>>>>>>>> development capabilities. At the same time, its
> > > > >>>>> responsibility
> > > > >>>>>>> should
> > > > >>>>>>>>>>>> belong to the user, although we will also point out who is
> > > > >>>>> the
> > > > >>>>>>>>>>>> contributor of each feature he chooses. But when using
> > > > >>>>>>> innovative or
> > > > >>>>>>>>>>>> customized features, users should also be clear about the
> > > > >>>>>> risks.
> > > > >>>>>>> I
> > > > >>>>>>>>>>>> also wrote about the risks of contributor repositories in
> > > > >>>> the
> > > > >>>>>>>>>>>> proposal.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> The main point is that we cannot grant "write" permissions 
> > > > >>>>>>>>>>> to
> > > > >>>>>>> repositories
> > > > >>>>>>>>>>> owned by the Pulsar project (the PMC)
> > > > >>>>>>>>>>> to people who are not "committers". This is a legal thing, 
> > > > >>>>>>>>>>> no
> > > > >>>>>>> exceptions.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> So any contribution must be in the form of a PR, like for 
> > > > >>>>>>>>>>> any
> > > > >>>>>>> other patches
> > > > >>>>>>>>>>> contributes to one of the github repositories owned by the
> > > > >>>>> Pulsar
> > > > >>>>>>> project
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> A couple of questions:
> > > > >>>>>>>>>>> - How can the Pulsar community maintain  a fork of Pulsar
> > > > >>>>>> itself  ?
> > > > >>>>>>>>>>> - Do you want to "cut releases" out of this fork ? Who is
> > > > >>>> going
> > > > >>>>>> to
> > > > >>>>>>> validate
> > > > >>>>>>>>>>> them ? Who is responsible for security bugs ?
> > > > >>>>>>>>>>> - Who is going to use this code  ?
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> I think that when you want to contribute a feature, you can
> > > > >>>> do
> > > > >>>>> it
> > > > >>>>>>> with a PR
> > > > >>>>>>>>>>> or with the PIP process (if it is bigger), and it is fine to
> > > > >>>>> mark
> > > > >>>>>>> it as
> > > > >>>>>>>>>>> "experimental".
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Then the community decides whether to support it or not.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> When a patch is committed to our repository then it is the
> > > > >>>>>>> responsibility
> > > > >>>>>>>>>>> of all of us (the PMC and the committers) to maintain it
> > > > >>>> almost
> > > > >>>>>>> forever,
> > > > >>>>>>>>>>> unless we decide to delete it.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> This is a legal thing, we cannot accumulate code without
> > > > >>>> being
> > > > >>>>>>> responsible
> > > > >>>>>>>>>>> for that.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> I am happy to clarify more if needed, and I hope that other
> > > > >>>> in
> > > > >>>>>> the
> > > > >>>>>>>>>>> community can help in understanding if this is doable of not
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Enrico
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> In addition, thank you for your valuable feedback.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Best regards
> > > > >>>>>>>>>>>> Xiangying
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> On Mon, Jul 22, 2024 at 10:55 PM Enrico Olivelli <
> > > > >>>>>>> eolive...@gmail.com>
> > > > >>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Hello,
> > > > >>>>>>>>>>>>> thanks for your proposal, we need more and more energy in
> > > > >>>>> the
> > > > >>>>>>> project.
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> I don't think that this is a good idea.
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> The main reason is that as an ASF project we must
> > > > >>>> guarantee
> > > > >>>>>>> the quality
> > > > >>>>>>>>>>>> and
> > > > >>>>>>>>>>>>> especially the security of what we provide to the public.
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Such kinds of repositories tend to become full of stale
> > > > >>>>> code
> > > > >>>>>>> that can
> > > > >>>>>>>>>>>>> become a source of security issues.
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Also we allow only "committers" to commit patches to the
> > > > >>>>>>> repositories
> > > > >>>>>>>>>>>> that
> > > > >>>>>>>>>>>>> are under the responsibility of the Apache Pulsar PMC, I
> > > > >>>>>> don't
> > > > >>>>>>> know how
> > > > >>>>>>>>>>>> we
> > > > >>>>>>>>>>>>> can make this work with a "official fork"
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Maybe I misunderstood the goal ?
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> An alternative is to have a "curated list" of links to
> > > > >>>>>>> personal projects,
> > > > >>>>>>>>>>>>> but we keep the responsibility over the code on the code
> > > > >>>>>>> owners and not
> > > > >>>>>>>>>>>> on
> > > > >>>>>>>>>>>>> the Pulsar PMC
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Best regards
> > > > >>>>>>>>>>>>> Enrico Olivelli
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Il giorno lun 22 lug 2024 alle ore 15:15 steven lu <
> > > > >>>>>>>>>>>> lushiji2...@gmail.com>
> > > > >>>>>>>>>>>>> ha scritto:
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> We think this is a very good solution,
> > > > >>>>>>>>>>>>>> Our XHS team(@liangyepianzhou <
> > > > >>>>>>> https://github.com/liangyepianzhou>
> > > > >>>>>>>>>>>>>> @AuroraTwinkle <https://github.com/AuroraTwinkle>
> > > > >>>>>>> @StevenLuMT
> > > > >>>>>>>>>>>>>> <https://github.com/StevenLuMT> @cai152 <
> > > > >>>>>>> https://github.com/cai152>)
> > > > >>>>>>>>>>>> will
> > > > >>>>>>>>>>>>>> submit a few to pulsar-java-contrib
> > > > >>>>>>>>>>>>>> <https://github.com/StevenLuMT/pulsar-java-contrib>(
> > > > >>>>>>>>>>>>>> https://github.com/StevenLuMT/pulsar-java-contrib) as
> > > > >>>> a
> > > > >>>>>>> primer to let
> > > > >>>>>>>>>>>>>> everyone know the role of this library
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> xiangying meng <xiangyingme...@gmail.com>
> > > > >>>> 于2024年7月22日周一
> > > > >>>>>>> 16:33写道:
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> Hello Pulsar Community,
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> I hope this message finds you well. I'm reaching out
> > > > >>>> to
> > > > >>>>>>> propose the
> > > > >>>>>>>>>>>>>>> establishment of a Pulsar Contributor Repository.
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> This new initiative is designed to provide a
> > > > >>>> dedicated
> > > > >>>>>>> space for
> > > > >>>>>>>>>>>>>>> experimental and community-driven features that
> > > > >>>>>> complement
> > > > >>>>>>> our core
> > > > >>>>>>>>>>>>>>> offerings.  This repository would serve as a space
> > > > >>>> for
> > > > >>>>>>> non-core
> > > > >>>>>>>>>>>>>>> features and customizations, allowing for greater
> > > > >>>>>>> flexibility and
> > > > >>>>>>>>>>>>>>> community involvement.
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> The proposal can be viewed at this GitHub link:
> > > > >>>>>>>>>>>>>>> https://github.com/apache/pulsar/pull/23061/files
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> I'm looking forward to your thoughts and feedback.
> > > > >>>>> Please
> > > > >>>>>>> feel free
> > > > >>>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>> share them on the Pulsar Developer Mailing List.
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> Thank you in advance for your time and consideration.
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> Best,
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> Xiangying
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>
> > > >

Reply via email to